You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Authentication can have multiple modules participating on the authentication process. Those modules are handled by FallbackAuthContext, which goes through every module one by one until a successful authentication is established.
The main thing here is that authentication modules are free to modify internal state of message context and client subject. And modules need to do that in order to let the caller know, who is the authenticated principal.
The issue
IDM registers authentication modules wrapped inside IDMAuthModuleWrapper. This wrapper calls the original module and on top of successful authentication can call augment script. When this script fails, the authentication is considered as unsuccessful.
The issue here is that Subject instance might be (and is) already initialized with principal from the wrapped module. When FallbackAuthContext moves to the next module, the principal is incorrectly resolved to the principal from the failed module. Augment script gets incorrect input and the final authentication is later represented with incorrect principal name (e.g. in audit).
I am not sure this has easy solution... obviously JASPIC was not designed with auth module wrappers in mind.
The text was updated successfully, but these errors were encountered:
Context
Authentication can have multiple modules participating on the authentication process. Those modules are handled by FallbackAuthContext, which goes through every module one by one until a successful authentication is established.
The main thing here is that authentication modules are free to modify internal state of message context and client subject. And modules need to do that in order to let the caller know, who is the authenticated principal.
The issue
IDM registers authentication modules wrapped inside
IDMAuthModuleWrapper
. This wrapper calls the original module and on top of successful authentication can call augment script. When this script fails, the authentication is considered as unsuccessful.The issue here is that Subject instance might be (and is) already initialized with principal from the wrapped module. When FallbackAuthContext moves to the next module, the principal is incorrectly resolved to the principal from the failed module. Augment script gets incorrect input and the final authentication is later represented with incorrect principal name (e.g. in audit).
I am not sure this has easy solution... obviously JASPIC was not designed with auth module wrappers in mind.
The text was updated successfully, but these errors were encountered: