Hi, I'll be happy to collaborate with you on this. I thought we could have a basic solution for LOA (using renew), but the more I think about it and the more I try to see it from a global perspective, the more I come to a major solution (updating CAS protocol). Prototyping is good, however for this issue, I myself really need to define (almost) all use cases and impacts in CAS clients and in CAS server before coding anything. If you agree, I'd like to : - write a spec on this : https://wiki.jasig.org/display/CAS4UM/Level+Of+Authentication+specification - number all my questions in this post to facilitate your answers.
* SLO : You're right about SLO, we all want to avoid using it but I don't see any solution without it for renew=true. Let's take an example : weak LOA : remember-me, strong LOA : authentication by login/password. - I access app1 and app2 as remember-me (round-trips on /login) - I access a more secured area (requiring login/password authentication) in app2 -> I'm redirected to CAS server with renew=true, I need to re-authenticate, I fill my password and I'm redirected to app2 -> I get access as I'm now authenticated (not remembered) - I access a more secured area (requiring login/password authentication) in app1 : what happens ? I'm still remembered in this one (if you didn't trigger any SLO before), so I'm redirected back to CAS server (renew=true) to re-authenticate : login page is displayed even if, in fact, I have now the right LOA to access (authenticated). 1.a) Do we agree on this problem : SSO is no more working after renew=true for already accessed applications and if we don't trigger a SLO ? 1.b) Do you have a solution for it avoiding SLO ? My point of view is that we can't achieve LOA with renew=true without SLO, so I would keep renew behaviour "as is" for backward compatibility. 2) Do we agree on not changing the renew behaviour ? --------------------------------------------------------- * LOA : There is a need to define ordered LOAs in CAS server. For example, from strongest to weakest : - authenticated (login/password and internal CAS authentication handler) - oauth_authenticated (login/password at OAuth provider) - ip_authenticated (right IP pattern when accessing CAS server) - remembered - anonymous. 3) Is this the kind of definition of LOA you have in mind ? Then, I would attach LOA to authentication handler : each authentication handler would say what LOA it will grant. To try the right authentication accoding to the requested LOA (see loa parameter). As we store the authentication handler used for the authentication, each authentication would also have a LOA associated with it. The LOA would certainly be pushed to CAS clients with SAML validation. 4.a) Do you agree on defining the granted LOA at authentication handler ? 4.b) Do you agree on attaching LOA to authentication ? 4.c) Do you agree on pushing LOA in SAML validation ? Finally, I would change the CAS protocol to add a new loa parameter (on /login), which is the required LOA expected from client. With two cases happening : - the loa requested is equals or weaker than the current one in SSO session (the client requests remember-me and I am authenticated), the CAS server redirected the user back to the service with a service ticket - the loa requested is strictly stronger than the current LOA (of the authentication), a login page is displayed to the user for authentication (login page = strongest level of authentication). 5) Do you agree on this loa parameter and its meaning (requiring a certain LOA from CAS server) ? I assume here that the strongest LOA is login/password and therefore the mean to achieve it is displaying a login page. It's some kind of restriction but I don't think it's a problem. 6) Are you ok with this restriction ? Let's take my first example using the loa parameter : - I access app1 and app2 as remember-me (round-trips on /login) - I access a more secured area (requiring login/password authentication) in app2 -> I'm redirected to CAS server with loa=authenticated, I need to re-authenticate, I fill my password and I'm redirected to app2 -> I get access as I'm now authenticated (not remembered) - I access a more secured area (requiring login/password authentication) in app1 : what happens ? I'm still remembered in this one, so I'm redirected back to CAS server with loa=authenticated and as I'm now authenticated in SSO session with the right LOA, I'm redirected back to application with a valid service ticket. Now it works. Looking forward to your reply. Cheers, Jérôme -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
