On 8/2/12 9:33 AM, "Marvin Addison" <marvin.addi...@gmail.com> wrote: >I think it's a reasonable simplifying assumption that for every LOA >there would be a distinct UI, so you could model the LOA to >corresponding view using a map. I'm fairly certain we'll use this >general approach in our solution. On the other hand, I can imagine >that some institutions would have various sets of user/pass >credentials that have distinct LOA values all served by a single user >interface. Those sorts of details make a generalized solution >difficult.
I'd like to propose that the "LOA" concept be more than just a numeric value, but more policy based. At the start, policy concepts will need to be limited to the use cases that we can think of (i.e. Don't try to be too generic and thus become overcomplicated), but I think we'll want the system to be more flexible than just a numeric identifier. Certainly there should be a mapping to/from a numeric value. I'll describe the scenario from my perspective: So, in our environment, we'll probably start with the following authentication methods: * LDAP username/password (level: 2-4 depending on password strength) * Facebook (level: 2) * Google (level: 2) * Twitter (level: 2) * Google Authenticator (level: 4) Other built-in authentication methods: * TGT session cookie (level is equal to backing authentication) We would also define combinations: * Any level 2 + Google Authenticator (level: 4) * Any level 3 or 4 + Google Authenticator (level: 5) (obviously Google Authenticator+Google Authenticator doesn't count) LDAP, Facebook, Google, and Twitter would all be mapped to the same UI screen. This would be a login page with "Connect using ____" links at the bottom. The Google Authenticator method would be mapped to a different UI. The default authentication mechanism would be set as "LDAP username/password". Each authentication method would be mapped to a different Java authentication handler class (or set of classes). Scenario 1: A user attempts to access our employee portal. The portal redirects the user to the CAS server with some metadata indicating which authentication methods are allowed. The metadata states that it accepts: "LDAP username/password with a password strength of 8 or more, Google Authenticator, or a TGT session cookie that was established using one of the other accepted methods and used within the past four hours." The CAS server displays the standard login page. Ideally, the system would recognize the allowed authentication methods and hide the "Connect using ____" links (though that isn't totally necessary). The page might include a link to the Google Authenticator screen. The user enters their username and password. When the service ticket is validated, the XML contains information indicating that "LDAP username/password" was the authentication method used, along with other metadata such as timestamp. The employee portal accepts this because it conforms to the policy. The user then tries to access our PeopleSoft HR system, also protected by CAS. The portal redirects the user to the CAS server with metadata stating that it accepts: "COMBINATION of LDAP username/password with a password strength of 8 or more AND Google Authenticator, or a TGT session cookie that was established using that combination and used within the past two hours." Ideally, the server detects that the current authentication is insufficient and starts the user on a web flow that will meet the requirements. Because the user already presented their username and password within the past two hours, only the Google Authenticator is needed. Therefore, the UI for the Google Authenticator is looked up and displayed, along with a message generated describing the reason for the additional authentication. For example, it might say: "For your protection, this website requires that you use [Google Authenticator] in addition to [your username and password]." Scenario 2: A student attempts to to access a public-facing event registration website. The website redirects the user to the CAS server with metadata stating that it accepts: "any mechanism with an LOA of 2 or more". The default login UI is displayed, and it includes the "Connect using ____" links. The user clicks the Twitter link and logs in. The student attempts to access another similarly-protected website. The method of authentication in this case is technically "TGT session cookie (last used 12 minutes ago) backed by Twitter login (timestamp 45 minutes ago)". Because the server's policy has been defined to set the numeric level of the TGT equal to that of the authentication method it is backed by, this will have an LOA of "2" and will therefore will pass the website's policy requirements. The server recognizes this and does not ask the user for any new authentication, and the client accepts the validated service ticket. Examples of service access LOA policies: * allow (user/pass) or (TGT backed by user/pass) * allow (user/pass with certain password strength) or (TGT backed by any other allowed method) * allow (user/pass) or (Facebook) or (TGT backed by any other allowed method) * allow (user/pass) - this simulates "renew=true" since it does not include the TGT cookie * allow (user/pass) or (TGT backed by user/pass used within the last 5 minutes) - this like "renew=true" but gives the user a "free pass" within 5 minutes * allow (user/passwith certain password strength AND google authenticator) or (TGT backed by that allowed method used within the last 30 minutes) ...and so on... >> So far, we talked about client initiated flows (asking for increasing >>LOA). But I think we can also have LOA definition in CAS service (no use >>of renew parameter). >> Does it make sense to you ? If so, I will add a second example in spec >>with LOA defined in CAS service. > >It absolutely makes sense and sounds like a valuable feature. > Agreed. -Nathan -- 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
