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

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 '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.