Topic on Talk:Requests for comment/AuthManager

I do believe that this new approach provides a number of benefits. I would like to describe our use case to make sure that is can be effectively handled by this approach.

We have a centralized identity manager that handles authentication requests for our enterprise. However, not every authenticated user is actually authorized to use every resource. The authentication decision is centralized, but the authorization decision is local to the wiki. I intentionally named Extension:PluggableAuth that instead of PluggableAuthentication or PluggableAuthorization, since both the authentication and authorization pieces are pluggable. Authenication and authorizatoin are handled a bit differently. Further, different wikis, despite sharing the centralized authentication service, will have different sets of authorized users and may, in fact, use different authorization models.

For example, I have written an authorization plugin that we use with PluggableAuth that uses a database table to maintain a list of email addresses of users authorized to use the wiki. There is a special page used by a sysop to populate that table. This works because 1) the centralized identity management system guarantees that email addresses are persistent and uniquely identify users and 2) the number of users on the wikis in question are small enough not to overburden the sysop with authorization management requests. We are considering future authorization extensions that are more robust and can more easily handle larger numbers of users. For example, I could imagine an authorization extension that would provide a rule engine and the ability to authorize or de-authorize users on a domain level rather than an individual user level.

Perhaps, following the model of the RFC, this can be handled with a REDIRECT response by the AuthenticationProvider that communicates with the central identity manager to another chained AuthenticationProvider that handles the local authorization decision. Is that consistent with the intent of REDIRECT? (In this case, I would sort of prefer that they be called AuthProviders, since sometimes the decision is whether the user can be authenticated and sometimes whether an authenticated user is authorized - but I can probably live slightly unhappily with this.)

The part I do not like about my current approach that I would love to improve is that the authorization piece requires a user object to already be constructed. Therefore, we end up with our user table littered with users who attempted to access the wiki and were authenticated but were not authorized. (I could probably, with a little bit of work, restructure the PluggableAuth code around this.) It sounds like the RFC would handle this better, since the user would not be created in the database (if I understand it correctly) until after all of the AuthenticationProviders have had their say.

However, here's the key part: the second AuthenticationProvider (the one handling authorization) needs user identifying information provided by the first AuthenticationProvider. That is, in our case, we do not know the system-wide unique identifier of the user until after the centralized identity provider has been contacted. Would the RFC be able to accommodate user identifying information being passed between AuthenticationProviders? I realize that this creates a perhaps uncomfortable dependency between AuthenticationProviders, since the second AuthenticationProvider would not be able to give a positive result in the absence of this information, but it is necessary in order for this approach to work.

Thank you for your work on this RFC.

We are very deliberately ignoring authz at this point in order to focus on authn. The end result of an interaction with the AuthManager (which we debated calling AuthenticationManager and still may in implementation) is only an authenticated session with a pointer to the correct local User.

We agree that the authz components of the existing system need to be cleaned up as well, but as was pointed out in previous discussions of the prior iterations of this RfC, changing all the things at once is very ambitious and likely to end up prolonging the implementation or even stalling the project all together.

Once we can get this RfC's implementation underway I'm very interested in continuing by helping draft an authorization proposal that would work along similar lines to handle the authz side of the problem.

OK, understood. However, it would be good to be sure that nothing in the proposed approach precludes handling the use case described above.

Your use of "authentication" and "authorization" is confusing, as often happens when thinking about authn and authz. You can often break down "authn" into further "authn+authz" pieces to the point of craziness like "authn says 'This user is Anomie' and authz says 'This user is allowed to be Anomie, based on the password they supplied'". It sounds to me like you may have broken things down to that point. From MediaWiki's perspective both authenticating the user against the central identity manager and checking if that centrally-authenticated user is authorized to access this wiki are part of authn, so why not just do both steps inside a single AuthenticationProvider? But if you didn't want to do it that way, you could have your first step be the PrimaryAuthenticationProvider and your second step be a SecondaryAuthenticationProvider to fit into the model of this RFC.

You might still need an authz component to your extension if the central identity provider also has functionality like CentralAuth's global groups, but that's outside the scope of the current RFC.

Authentication: proving that the user is who they say they are. Authorization: proving that a particular user is allowed to access a particular resource. In the use case I described above, "not every authenticated user is actually authorized to use every resource. The authentication decision is centralized, but the authorization decision is local to the wiki." That is, our wikis exist within our corporate enterprise. Authentication, proving that the user is who they say they are, is handled by a centralized corporate resource that is able to verify the identity of all users. This enables single sign-on within the enterprise. The authorization decision, however - determining which users are allowed to use which wikis - cannot be handled centrally. We have a large number of topic-based wikis, each potentially with its own list of authorized users or rules for how to determine if a user is authorized. I gave one example above of using a list of email addresses. Another example is accessing the corporate LDAP directory to only admit users who belong to a particular department. This is not the password situation you describe above.

If using a PrimaryAuthenticationProvider for authentication with the centralized authority and using a SecondaryAuthenticationProvider (despite the name) for the local authorization decision fits within the model of the RFC, that is helpful. However, I specified two items above that it was unclear to me would be supported by this model: 1) the user account should not be created in the database until after both authentication and authorization are decided in the affirmative and 2) it is possible to pass enough information to uniquely identify the user from the PrimaryAuthenicationProvider to the SecondaryAuthenticationProvider.

I was asked to provide feedback on whether the RFC would work for our use case. I have described our use case and my questions regarding whether it will be supported. If our use case is outside the scope of the current RFC, then we will still need to use other means to satisfy it.

@Cindy.cicalese: said:

1) the user account should not be created in the database until after both authentication and authorization are decided in the affirmative and 2) it is possible to pass enough information to uniquely identify the user from the PrimaryAuthenicationProvider to the SecondaryAuthenticationProvider

I think @Anomie:'s suggestion of looking at this slightly differently in your particular use case is a good one. If you think of authentication from the point of view of a particular wiki with rules that say that only a subset of all users who exist in the external user pool are valid, then to authenticate to the wiki the user must have a valid username and password combo as validated by the external source and the user must also match additional constrains such as being associated with a white list of allowable users (email address in list and/or LDAP group membership in your example above).

In the scenario that you describe, the proper fit in the AuthManager framework with highest reuse would likely be to consider the whitelist behavior to be similar to a 2-factor auth scenario which would be implemented as a SecondaryAuthenticationProvider. Currently we have only imagined the secondary providers receiving the AuthenticationRequest object and not some stub User object created by an AuthenticationProvider. This would likely mean that you would need to be able to lookup whitelist membership starting with only the username provided in the request rather than passing additional data from provider to provider. It would also be possible to combine the two activities into a single AuthenticationProvider.

As someone who is helping a corporation use MediaWiki, I think Cindy's take on this should be viewed as representative of those who use MediaWiki in large organizations.

The argument is often made here (on MW.o) that if you want more control over authorization than MW gives you, then you should use a CMS. This argument ignores a sizable number of users who have decided on and use MW because of the workflows and culture that it enables that a CMS is not designed for.

Cindy works on a large corporate wiki farm and has the ability to implement a lot of what she wants. It would be good to ensure that her insights are addressed here.

She may be conflating Authz and Authn in ways that the WMF doesn't need to worry about for Wikipedia, but for those of us without a sizable userbase to do the work that WMF relies on community for, it makes sense to be sure that the design of the code can accommodate our needs at these early stages.