There's a bunch of different use-cases, but step-up authentication is
indeed one of them. In addition to email/uname + pwd, sms otp or TOTP we
need to support means of authentication with higher levels of assurance.
Like Norwegian BankID, Swedish BankID, Danish NemID, Finnish Tupas,
Estonian ESTEeID, etc. This is something that we could probably accomplish
with cunning use of query parameters and prompt=login, and it would
resemble the standard way to do it, but it would still be somewhat hackish.
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.
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.
On Thu, 16 Feb 2017 at 09:21 Stian Thorgersen <sthorger(a)redhat.com> wrote:
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 <
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?
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
keycloak-dev mailing list