Thread:Talk:Requests for comment/AuthManager/Feedback/reply (4)

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.