3:08 p.m.
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
3:23 p.m.
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
2:40 a.m.
I was worried it would get messy :|
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 23 September, 2014 9:23:08 PM
Subject: Re: [keycloak-dev] UserSession changes required for SAML
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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3746
days inactive
3748
days old
2 comments
2 participants
participants (2)
-
Bill Burke -
Stian Thorgersen