Implement authentication flow mapping for authentication context clas… #24365
Conversation
…s reference (ACR) values. This implements an alternative mapping for the existing ACR feature where administrators can map requested ACR values to authentication flows, in addition to the existing level of authentication (LoA) mapping. It also implements a protocol mapper for populating the ACR claim in the resulting OIDC tokens. This implementation adds an ACR to auth flow mapping configuration at the client and realm level. When a client authenticates a user, and they request a particular ACR value, Keycloak will check for a mapped authentication flow in the client or realm configuration. If one is found, Keycloak will executed the corresponding authentication flow. If none match, then the existing LoA behavior will take place. Upon successful completion of an authentication flow, Keycloak tracks the flow ID in a user session note. The protocol mapper takes this completed authentication flow ID from the user session note and finds the associated ACR value from the realm or client configuration and sets it in the tokens. Closes keycloak#24297 Signed-off-by: Ben Cresitello-Dittmar <[email protected]>
There was a problem hiding this comment.
@ben95cd Thanks for your PR and very sorry for the late review! Your PR is great functionality and hopefully we can have it available in Keycloak. I have few considerations:
-
Do we really need ability to configure this per-client level? Isn't the realm-level sufficient? Having per client level adds some additional complexity, so if it is possible to avoid it, it can be nice.
-
What happens if there is acr-flow mapping configured per realm-level and at the same time, the client has "Authentication flow binding override" configured? Will the realm-level acr-flow map have precedence over the flow configured for the client in "Authentication flow binding override" ? If possible, it can be nice to document this and maybe also have automated test. WDYT?
-
Can we avoid introducing another protocol mapper
AcrFlowProtocolMapper, but instead have all the functionality available just in theAcrProtocolMapper? This will simplify the configuration and the migration as theAcrFlowProtocolMapperis not available in any client scope by default, so it would be another needed step for people to add it (and it is not documented in your PR BTW). Also changing the providerId of existing protocol mapper does not work IMO due the migration (pointed also in the inline comment). Perhaps something like this pseudo-code can be possible inAcrProtocolMapper:
protected String getAcr(AuthenticatedClientSessionModel clientSession) {
if (flowMappingWasUsed) {
getAcrFromFlow();
} else {
getAcrFromLoa(); // same functionality as implemented currently in the AcrProtocolMapper
}
What do you think?
Besides this, it can be also needed to rebase your PR.
| } | ||
|
|
||
| public static final String PROVIDER_ID = "oidc-acr-mapper"; | ||
| public static final String PROVIDER_ID = "oidc-acr-loa-mapper"; |
There was a problem hiding this comment.
I don't think we can change this as AFAIK this will break backwards compatibility for the people migrating from the previous version as they already have oidc-acr-mapper in their DB.
| import org.keycloak.testsuite.util.FlowUtil; | ||
| import org.keycloak.testsuite.util.UserBuilder; | ||
|
|
||
| import java.util.*; |
There was a problem hiding this comment.
Minor: Is it possible to avoid star imports and import individual classes instead? We are trying to avoid them in the Keycloak codebase.
|
@ben95cd Closing as there is no reply for the long time. It will be welcome to open new PR if you have a chance and possibly address the remaining points and fix the conflicts, which were introduced in the meantime in the related classes. |
Implement authentication flow mapping for authentication context class reference (ACR) values.
This implements an alternative mapping for the existing ACR feature where administrators can map requested ACR values to authentication flows, in addition to the existing level of authentication (LoA) mapping. It also implements a protocol mapper for populating the ACR claim in the resulting OIDC tokens.
This implementation adds an ACR to auth flow mapping configuration at the client and realm level. When a client authenticates a user, and they request a particular ACR value, Keycloak will check for a mapped authentication flow in the client or realm configuration. If one is found, Keycloak will executed the corresponding authentication flow. If none match, then the existing LoA behavior will take place. Upon successful completion of an authentication flow, Keycloak tracks the flow ID in a user session note.
The protocol mapper takes this completed authentication flow ID from the user session note and finds the associated ACR value from the realm or client configuration and sets it in the tokens.
Closes #24297