Narrative

AAL/ACR support is implemented in Keycloak as Step-Up Authentication, with the current functionality only allowing incremental authentication steps. This means that based on the `acr_values` parameter more and more authentication methods are "stacked on" the authentication. This ACR implementation for level of authentication is only suitable if the authentication methods an organization accepts are hierarchical.
So for example, level X+1 always require to authenticate with all the levels requested by level X.
In other words, we have support for the use-case like "Level 1 requires password, Level 2 requires password + OTP".

Many customers may want to start with offering several authentication methods (password, otp, smartcard, etc). But, when a higher AAL is requested, they would like to disable weaker methods (instead of stacking more on top).
So we need to enhance the step-up authentication feature to add support for the use-cases like "Level 1 requires password, Level 2 requires certificate only (and not password at all)".

Value Proposition

• Customers are looking at the NIST Special Publication 800-63B for Digital Identity Guidelines, Authentication and Lifecycle Management, which provides recommendations on types of authentication processes, including choices of authenticators, that may be used at various Authenticator Assurance Levels (AALs).
• Authentication at higher AALs can effectively reduce the risk of attacks. Customers should not be forced to go through an hierarchical stacked authentication methods in order to meet their security requirements with higher AALs.
• Better flexibility, for a better and higher security, for enabling a better UX, and in-lines with organizations' specific requirements.

Goals

• Ensure that an organization is able to route users to entirely different authentication flows based on the resources they are trying to access. For example, based on organizational policy, an user accessing resource A may be allowed to use password authentication. However, resource B strictly does not allow password authentication, and therefore, the user would need to be routed to an entirely different flow.
• For example, as an organization, we may need to start offering several authentication methods to our users (aka: password, otp, smartcard, etc). But, when a higher AAL is requested, we would like to disable the weaker methods.
  -> Application Requests AAL1: User can choose between password, securID or clientcertificate
  -> Application Requests AAL2: User can choose between password+otp, securID or clientcertificate
  -> Application Requests AAL3: User can only use clientcertificate

Implementation note

• References to existing issues/discussions: 
  -> https://github.com/keycloak/keycloak/issues/24297
  -> https://github.com/keycloak/keycloak/pull/24365
  -> https://github.com/keycloak/keycloak/discussions/24023