Hi all,
there is an upcoming standard on Levels of Assurance at NIST
https://pages.nist.gov/800-63-3/.
Justin Richer blogged about it here
https://medium.com/@justinsecurity/vectors-of-trust-ed52a57fe025#.c9eo8ihmx
Maybe that's interesting in this context.
Best regards,
Sebastian
-----Ursprüngliche Nachricht-----
Von: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org] Im
Auftrag von Stian Thorgersen
Gesendet: Donnerstag, 16. Februar 2017 09:21
An: Martin Hardselius <martin.hardselius(a)gmail.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Betreff: Re: [keycloak-dev] acr and acr_values
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
wrote:
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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev