[keycloak-dev] per-client authentication flows

[Marek Posolda]

On 19/01/18 16:39, Bill Burke wrote:
> On Fri, Jan 19, 2018 at 9:25 AM, Marek Posolda <mposolda at 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?
Yeah, sure. I was just thinking if it's possible to address 2 usecases 
by implementing 1 single feature :) But not sure if it's best approach 
anyway... Feel free to do whatever you think is best.
>
>>> 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.
>
>
>
Yes, that should work. The most of the related code is in 
AuthenticationSessionManager. Maybe we can add more separate providers 
(cookie, query) and allow somehow to configure which one will be used?


Marek