9:39 a.m.
On Fri, Jan 19, 2018 at 9:25 AM, Marek Posolda <mposolda(a)redhat.com> wrote:
On 19/01/18 14:21, Bill Burke wrote:
>
> That's "step-up" authentication right? Or is acr something different.
> Yeah, I think per-client flow could be an alternative way to implement
> it. Don't know if its a better way, but it is an alternative.
Yes, it is about step-up authentication. I hope this can indirectly help
with per-client flows, but not 100% sure.
One possible issue with different "acr" values for different authentication
flows is the fact, that with the step-up authentication you may not want to
repeat some authenticators, which were already successful for this
userSession.
For example you have flow1 with password-only and flow2 with password+OTP.
When application is already authenticated with level1 (username+pasword),
but now wants level2, you don't want to type password again if you already
authenticated through password before. So authentication flow should ask
just for OTP in this case. But executionId of usernamePassword authenticator
will be different in both authentication flows.
However maybe this can be addressed with the "amr" claim, which can be saved
in IDToken (This is per OIDC specs
http://openid.net/specs/openid-connect-core-1_0.html#IDToken) and maybe also
userSession. It contains the String representations of used authentication
methods. Hopefully we can use this to track that username+password
authenticator was already used in this userSession in different
authentication flow and hence skip the usernamePassword authenticator when
moving from level1 to level2.
There's a few different approaches we can take that Stian and I
discussed in a F2F last year. But I think per-client flows is useful
irregardless if we use them to implement step-up auth. Right?
>
> BTW, different topic, one thing I'm worried about though is, are auth
> flows now dependent on cookies? We may have to optionally allow query
> params to specify the auth session rather than a cookie. For
> non-browser grants, we'll have logins spanning multiple requests
> (think SPNEGO/Kerberos) and they may not support cookies.
Yes, I see. Someone already asked on keycloak-user mailing list about the
alternative of using query parameter instead of the cookie. I think it was
similar usecase like Openshift. Authorization code OIDC flow was needed in
some non-browser authentication scenario.
I think I remember another value of using a query param was that you
could continue an auth session in a completely different browser.
How do you think to implement? If a cookie is set, use that value for
auth session, if not allow it to be specified as query parameter?
I'll look into this and discuss more later in separate thread.
--
Bill Burke
Red Hat