[keycloak-dev] UserSession changes required for SAML

Bill Burke bburke at redhat.com
Tue Sep 23 16:23:08 EDT 2014


Ugh, this is getting hairy, but doable.  I'm changing things around.


The Login page will create a ClientSession that is not yet attached to a 
UserSession.  A reference to this ClientSession will be passed around 
via a query parameter (like you currently do for AccessCode) between 
user actions (registration, social login, reset password, login totp, 
etc.).  Only when Keycloak is ready to redirect back to the client will 
a UserSession be created and the ClientSession attached to it.

On 9/22/2014 4:08 PM, Bill Burke wrote:
> There's a few problems with UserSession and AccessCode and screen flows
>
> * UserSession and AccessCode is hard wired to oauth protocol
> * userSession is not created until credentials have been entered
> * SAML has state that needs to hang around until final redirect back to
> client
> * Final redirect needs to know the protocol that started the login.
> * Screen flows assume various query parameters are set (client_id, etc.)
>
> So here's the changes:
> * UserSessions will be created when the login page is first visited if
> the user hasn't already logged in.
> * ClientSession will also be created when login page is visited.
> setAuthMethod for the ClientSession will be set so that later on, when
> the final redirect happens, the auth server will know which protocol to use
> * ClientSession will have a generic string hashmap
> (ClientSession.getNotes()) where you can store arbitrary state.  (i.e.
> like HttpSession, but specific to the client).
> * ClientSession.getState() will be removed and put in
> ClientSession.getNotes()
> * AccessCode needs to expose the ClientSession instead of hiding and
> delegating to it.
> * Screen flows will access the ClientSession for all information required.
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the keycloak-dev mailing list