Can you elaborate on your use-case? We have some plans to introduce a step-up-authentication mechanism. The main idea is to have the concept of authentication levels. In the authentication flows there would be additional metadata that would set the authentication level. This means the authentication level can be set independently to authenticators and authenticators doesn't even have to be aware of it. In summary a login flow would look something like: * Username/password form * Set authentication level = 1 * OTP form * Set authentication level = 2 Behind the covers the authentication processor would know at which point in the flow it's possible to exit the flow depending on the level requested. The level requested would be base on: * Realm default * Client default * Client requested It would also support the client being able to initially request for level 1 then later ask for level 2. The authentication processor would it that case be able to skip the parts of the flow that was previously executed. We also had an idea about allowing alternative flows depending on what level you are going from and to. This could be relevant if authenticators allow collecting more than one thing on a single form. For example there could be alternative authenticators for username-only, username+password, username+password+otp. This would be done by having conditions on which flow to select. On 15 February 2017 at 14:46, Martin Hardselius <martin.hardselius(a)gmail.com

On 16 February 2017 at 10:08, Martin Hardselius <martin.hardselius(a)gmail.com I think that would work just fine. Authentication levels (level of assurance is more accurate term) could range from 0 to 100, they could also have aliases associated with them. By introducing a level 4 that is associated with things like BankID a client can request that level of assurance simply by passing acr_values query param. If the user is already authenticated with level 3 the user would be asked to input BankID (or another means). We've been planning to introduce ability for admins to select what two factor mechanisms are supported for a realm and allow users to have one or more two factor mechanisms. We'd probably need to extend on that idea to also allow flexible primary means of authentication. I guess the admin should be able to configure what credential types are available for a realm. The various credential types would be associated somehow with authenticators and authenticator/assurance levels. Then the users can pick and choose which mechanisms they want to enable in their account. They can also have multiple alternative types (for example OTP or SMS, and BankID vs something else with the same level of assurance). We'd also support pluggable credential types that would allow adding additional screens to account management console and/or admin console for configuration. > > Since this is also telco related, we're looking at Mobile Connect down the > road, and acr and acr_values are required by the Mobile Connect profile. > > https://developer.mobileconnect.io/mobile-connect-profile-v1-2 > > The ideas you listed all look super relevant. One thing that I would find > useful is support for a "method portal" of sorts. The End-User would be > able to select her method of authentication. This is relevant when you have > several options on a single assurance level. Like in Norway, where we have > both BankID and Buypass. > > I hope this made sense. > > Martin > > On Thu, 16 Feb 2017 at 09:21 Stian Thorgersen <sthorger(a)redhat.com> >> Can you elaborate on your use-case? >> >> We have some plans to introduce a step-up-authentication mechanism. The >> main idea is to have the concept of authentication levels. In the >> authentication flows there would be additional metadata that would set the >> authentication level. This means the authentication level can be set >> independently to authenticators and authenticators doesn't even have to be >> aware of it. >> >> In summary a login flow would look something like: >> >> * Username/password form >> * Set authentication level = 1 >> * OTP form >> * Set authentication level = 2 >> >> Behind the covers the authentication processor would know at which point >> in the flow it's possible to exit the flow depending on the level >> requested. The level requested would be base on: >> >> * Realm default >> * Client default >> * Client requested >> >> It would also support the client being able to initially request for >> level 1 then later ask for level 2. The authentication processor would it >> that case be able to skip the parts of the flow that was previously >> executed. >> >> We also had an idea about allowing alternative flows depending on what >> level you are going from and to. This could be relevant if authenticators >> allow collecting more than one thing on a single form. For example there >> could be alternative authenticators for username-only, username+password, >> username+password+otp. This would be done by having conditions on which >> flow to select. >> >> >> On 15 February 2017 at 14:46, Martin Hardselius < >> martin.hardselius(a)gmail.com>> >> We're in the process of adding support for different levels of assurance >> in >> our custom installation, which means that proper support for acr and >> acr_values is becoming more of a priority. What's the status on this? Can >> we assist with a PR? >> >> https://issues.jboss.org/browse/KEYCLOAK-3314 >> >> This might fit better into keycloak-user, but if you already have plans >> for >> acr-stuff, or planned refactorings that would affect how this is >> implemented, I'd be happy for some advice on how to proceed with a >> temporary solution. >> >> Regards, >> Martin >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >>

We'll just be attacking authentication vector of trust. On 2/16/17 4:31 AM, Schuster Sebastian (INST/ESY1) wrote: