If that helps a discussion, we have successfully implemented a strong authentication use case with a Google Authenticator hardware token for Ryerson University. We'd be happy to share the code. In fact, the OATH TOTP code is already in cas-addons.
Cheers, Dmitriy. Sent from my iPhone On Jul 31, 2012, at 11:32, Marvin Addison <marvin.addi...@gmail.com> wrote: >> I'll be happy to collaborate with you on this. > > Outstanding. > >> 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. > > Fair enough. I was trying to sidestep a formal specification, but it > probably merits one since both the client and server are involved. My > concern with a spec is that we'll identify too many use cases to solve > and will end up abandoning the effort due to massive work/scope and > end up accomplishing nothing. I'd advise we keep to the smallest > number of required use cases in the spec. > >> 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. > > I moved the page to the CAS wiki space since that's where the Roadmap > lives and it's historically been the place where design and > development specifications are hosted: > > https://wiki.jasig.org/display/CAS/Level+Of+Authentication+Specification > >> 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). > > I don't think the flow above is any different from a non-remember-me > case other than the fact that you didn't have to authenticate > initially to access app1. As to what happens when a more secure area > of app1 is accessed, I would say that the client configuration would > need to indicate an LOA to be communicated to CAS such that the login > page is _not_ displayed if the LOA criteria has been met by a previous > authentication. That's the whole point: upgrade session via new > authentication if needed, otherwise pass through and issue a service > access token. > >> 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 ? > > I don't agree. I believe we could specify a method by which the SSO > session is "upgraded" for some fairly straightforward definition of > upgrade, namely, that there is an Authentication associated with the > TGT (session) that meets the LOA criteria demanded by the client. > That requires that all authentications performed in an SSO session are > saved in some manner and accessible for servicing LOA queries. > >> 1.b) Do you have a solution for it avoiding SLO ? > > If you agree with the definition above, then I'm hopeful I have a > potential solution. > >> 2) Do we agree on not changing the renew behaviour ? > > I'm hopeful that the changes I have in mind would be simply additive > and therefore be backward compatible. > >> 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 ? > > No. LOA is the level of confidence with which a principal is > specified by a given credential, which in some cases may also include > transport and protocol concerns. For credentials transmitted over > secure transports/protocols, the LOA is effectively determined > entirely by the credential and its underlying identity vetting > process. Perhaps there's a distinction to be made by LOIA and LOA to > emphasize that the former is dealing with identity assurance, but in > practice the two terms are synonymous. From my experience with the > InCommon Assurance program, LOA is primarily concerned with the > security and process around the credential, so I think it's fair to > say that generally LOA is concerned primarily with the credential. > Thus most of the determination is under your first numbered point > above, which is the authentication handler that processes a given > credential. The anonymous case would be included in LOA very > naturally as well since it's effectively a null authentication > handler. IP-based authentication doesn't really fit well into the > definition of LOA since there is a lot of research and legal precedent > to indicate that a human principal cannot be identified with any > confidence by network address. I sincerely think OAuth and remembered > are orthogonal to the general sense of LOA. > >> 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). > > That's exactly what I had in mind, though I would like to avoid > additional protocol parameters. There's no reason that renew couldn't > be extended to specify numeric values for LOA. > >> 4.a) Do you agree on defining the granted LOA at authentication handler ? > > Yes. > >> 4.b) Do you agree on attaching LOA to authentication ? > > Yes. > >> 4.c) Do you agree on pushing LOA in SAML validation ?\ > > Yes. That's what we do presently and it works well, but there are > some server-side workflows that need to be LOA-aware in addition to > simply spitting back the requested LOA. Displaying the particular UI > for a particular LOA is one such concrete matter. (Cannot assume all > credentials are user/password.) > >> >> 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 agree with the general semantics of the parameter, but again I'm > hopeful we could leverage renew for the same purpose. Its present > meaning is very similar to the spirit of an LOA demand, and augmenting > it to convey a particular LOA seems natural. > >> 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 ? > > No, username/password credentials do not have the highest LOA in all cases. > > * Email address/password - LOA 1 > * VT username/password - LOA 2 > * Hardware token w/certificate - LOA 3 > > One of the problems we're trying to solve is to provide a method to > allow a high-security CAS-enabled service to require authentication > with a hardware token. > > The good news is that it appears we agree on most aspects of the > discussion. As a next step, let's try to identify a small set of > required use cases on the wiki above and the expected behavior, then > we can move forward with analyzing various designs. I think the case > you wrote initially is good, though I will say again that I think we > can omit the remember-me aspect since it doesn't appear relevant to > the LOA considerations. > > Best, > M > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > dmitriy.kopyle...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- 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
