Page Comparison

...

• LDAP username+password
  • Simple password policy: 6+ characters
  • Medium password policy: 8+ characters, with special characters and numbers
  • Strong password policy: 12+ characters, with special characters and numbers, forced rotation
• Send code to SMS
• Google Authenticator
• Facebook Connect
• Twitter Login
• Registered machine/device/browser
• Trusted Partner (running another CAS server)
• Send code to email (used for password reset)
• Security questions and answers (used for password reset)

LOA

...

Policies

Here is a list of some of the applications that we are protecting (or will soon be protecting) with CAS, and the corresponding LOA policy that we are discussing for that application.  All of these are, of course, subject to change as we evaluate relative security and consider the direction of CAS's future LOA capabilities.

The main concept here is that each client can have it's own "policy" (or set of policies) that determine what it finds acceptable.

* In this example, I'm considering the possibility of using CAS+LOA to protect our "forgotten password" self-service feature.  However, this is just an idea I'm exploring as opposed to a "requirement."

Authentication "Levels" Defined on the Server

Here is one way that we might wish to define our levels of authentication in a root policy on the server.  These are subject to change based on research and evaluation by our IT security expert.

...

1. An HR employee (using a computer outside of the organization's LAN) accesses the event registration system.
   1. The event registration system redirects them to CAS, and includes "loa=10".  (Alternatively, the service might have been pre-registered with the server with an LOA attribute set to "10".)
   2. The CAS server determines that the user's current LOA (not logged in = 0) is insufficient.
   3. The CAS server looks up in the LOA policy table and discovers that all possibilities will satisfy this requirement.
   4. The CAS server looks at the first authentication handler for each LOA row (this matters for rows that specify multiple authentication handlers).  It finds: "LDAP", "Trusted Partner", "Facebook", and "Twitter".
   5. The CAS server looks up the "interaction" settings for each of these authentication handlers, and discovers that all four list "standard login page" as their interaction.  When showing the login page as part of the interaction, the system injects the list of acceptable authentication handlers.
   6. The CAS server shows the standard login page (as defined by the interaction), and this page displays the username/password form as well as links to login with Facebook, Twitter, and "Trusted Partner."
   7. The user selects "Login with Facebook", enters her Facebook info, and proceeds.
   8. Before generating the service ticket, the CAS server computes the LOA and double-checks to ensure that the user's current LOA (now 10) is sufficient for the service (either as communicated via redirect parameter or as registered in the service registry).
   9. As the CAS client is validating the service ticket, it receives metadata about the method of authentication (authproviders="facebook", namedLOAs="facebook") and the computed LOA (10). The CAS client also has the ability to verify that the authentication details (including computed LOA and specific authprovider info) is acceptable.
2. In the same session, the same user accesses the social networking site.
   1. The employee portal redirects the user to the CAS server.  The site is pre-registered with an LOA attribute of "10".
   2. The CAS server determines that the user's current LOA (10) is sufficient.
   3. The CAS server generates a service ticket and immediately sends the user back.
   4. The service ticket is validated, the site accepts the LOA metadata, and the user uses the site.
3. In the same session, the same user accesses the employee portal.
   
   1. The employee portal redirects the user to the CAS server, and includes "loa=20"
   2. The CAS server determines that the user's current LOA (10) is insufficient.
   3. The CAS server looks up in the LOA policy table and finds the list of rows that will satisfy this requirement.
   4. The CAS server looks at the first authentication handler for each LOA row (this matters for rows that specify multiple authentication handlers).  It finds: "LDAP" and "Trusted Partner"
   5. The CAS server looks up the "interaction" settings for each of these authentication handlers, and discovers that all four list "standard login page" as their interaction.  When showing the login page as part of the interaction, the system injects the list of acceptable authentication handlers.
   6. The CAS server shows the standard login page (as defined by the interaction), and this page displays the username/password form as well as a link to login with "Trusted Partner."  The "Facebook" and "Twitter" links are NOT included because they are not on the list of acceptable providers.  Also, a message might be displayed on the screen that says: "Although you already logged in using Facebook, the website you are trying to access does not accept Facebook authentication.  Please use one of the methods listed below."
   7. The user types her corporate username and password to login.
   8. Before generating the service ticket, the CAS server computes the LOA and double-checks to ensure that the user's current LOA (now 30) is sufficient for the service.
   9. As the CAS client is validating the service ticket, it receives metadata about the method of authentication (authproviders="facebook, ldap", namedLOAs="facebook, ldap_medium") and the computed LOA (30).
4. In the same session, the same user accesses PeopleSoft HR.
   1. PeopleSoft looks up the user's role and determines that they have the ability to manage employees, so they must conform to "Policy B."
   2. PeopleSoft redirects the user to the CAS server, and includes "loa=34,ldap_medium_lan".  (This means that any LOA of 34 and above, plus the special exception of ldap_medium_lan" are all acceptable.)
   3. The server looks up in the LOA policy and finds the rows that will satisfy this requirement.
   4. The CAS server determines that the user is incapable of fulfilling the requirements for "ldap_strong, ldap_strong_sms, and ldap_strong_google" because the user's current password strength is only medium, so it eliminates those possibilities.
   5. The CAS server eliminates the "ldap_medium_lan" possibility, since the "LAN" authentication handler uses an automatic system interaction and therefore would have already been accepted if possible.  (Basically, the user is once again incapable of fulfilling this requirement, so there's no point in asking them about it.)
   6. The CAS server is left with two possible rows in the policy table: "ldap_medium_google" and "ldap_medium_sms"
   7. The CAS server determines that the user has already fulfilled the "ldap" requirement for these rows.
   8. The CAS server looks In this case, PeopleSoft is protected by the CAS servlet filter.  The filter redirects the user through the CAS server for initial authentication.  The filter doesn't know who the person is yet, so it uses its lowest requirement, which is: "loa=30"
   9. This LOA requirement is sufficient, so the CAS server generates the service ticket, which is accepted by the servlet filter.
   10. PeopleSoft looks up the user's role and determines that they have the ability to manage employees, so they must conform to "Policy B."
   11. PeopleSoft redirects the user to the CAS server, and includes "loa=34,ldap_medium_lan".  (This means that any LOA of 34 and above, plus the special exception of ldap_medium_lan" are all acceptable.)
   12. The server looks up in the LOA policy and finds the rows that will satisfy this requirement.
   13. The CAS server determines that the user is incapable of fulfilling the requirements for "ldap_strong, ldap_strong_sms, and ldap_strong_google" because the user's current password strength is only medium, so it eliminates those possibilities.
   14. The CAS server eliminates the "ldap_medium_lan" possibility, since the "LAN" authentication handler uses an automatic system interaction and therefore would have already been accepted if possible.  (Basically, the user is once again incapable of fulfilling this requirement, so there's no point in asking them about it.)
   15. The CAS server is left with two possible rows in the policy table: "ldap_medium_google" and "ldap_medium_sms"
   16. The CAS server determines that the user has already fulfilled the "ldap" requirement for these rows.
   17. The CAS server looks at the first unfulfilled authentication handler for each row.  It finds: "sms" and "google".
   18. The server finds that these two authentication handlers utilize differentinteractions, so it presents the user with picks one as the default.  In this case, that is the "google authenticator" screen.  However, the screen shows an option to allow the user to select the other method instead.
       1. Alternatively, it could present the user with a screen for the user to choose one of these two options.
   19. Because the user does not have a smartphone, she selects clicks the link to use the SMS option instead of google authenticator.  The system sends the code to her pre-registered cell number and waits then displays a screen asking for the code (as part of the interaction).
   20. The user receives the message and types the code into the screen. It is validated.
   21. Before generating the service ticket, the CAS server computes the LOA and double-checks to ensure that the user's current LOA (now 34) is sufficient for the service.
   22. As the CAS client is validating the service ticket, it receives metadata about the method of authentication (authproviders="facebook,ldap, sms", namedLOAs="facebook, ldap_medium, ldap_medium_sms") and the computed LOA (34). In this case,  The CAS filter places this information in a place where the PeopleSoft code can get it (probably an HTTP header). The PeopleSoft code once again looks up the user's role and uses this when ensuring checks to ensure that the LOA data is now acceptable.

Implementation

On the CAS Server

1. A "server policy" is defined that maps names and numbers to combinations of authentication handlers
2. Each "authentication handler" has an "interaction" registered which determines how credentials are gathered.  It could be user-interactive (show a screen) or automatic (fetch a cookie).
3. There should be some kind of precedence to determine which interactions are default.
4. When a request for authentication, the following happens:
   1. The server determines the LOA policy for this service
      1. Look in the service registry to see if the service is registered and has an LOA policy defined.
      2. Look for an LOA parameter.  The LOA parameter is a comma separated list of all LOA values that are acceptable.  A numeric value means: "every LOA with this value or higher".  A named value means: "also this individual level even if it is numerically lower".  Only one number should be included in the list, but the list can have multiple named levels.
      3. If both a pre-registered LOA requirement and a parameter exist, combine them in a way that makes sense and is secure.  (that "way" is to be determined)
      4. This combination could be labeled the "client LOA policy"... it defines what levels of assurance are deemed acceptable to the client
   2. Check the user's current status (list of all handlers that have already successfully authenticated) and determine if the user already satisfies the "client policy".  If so, generate the service ticket and redirect the user back to the service immediately.
   3. Otherwise...  The server determines which interaction(s)it needs to show to the user
      1. Find all rows in the "server policy" table that will satisfy the service's LOA requirements.  Each row contains a list of authentication handlers that must be satisfied, possibly each with some attributes.
      2. For each row, determine if the user has already authenticated using any of the authentication handlers required for that row.  If the user already authenticated with this method, but the attributes aren't satisfied, remove this row from the list of possibilities and also make a note about the unsatisfied attribute(s).
      3. If no rows are found, show the user an error message.  The error message may include information regarding the unsatisfied attributes (such as "your password strength is too weak")
      4. Make a list of possible authentication handler chains base don the lists of authentication handlers for each row.  Remove all already-authenticated handlers from the chains.
      5. Look at the first authentication handler that remains in each chain. Look up the interaction that is registered for that action.
      6. Perform all automatic interactions (like fetching a cookie).
      7. If multiple user-interactions exist, choose the "default"
      8. Make a list of the first authentication handler in each chain and put that list into the HttpServletResponse.  This is important if you have a single interaction is designed to be used with multiple authentication handlers, such as a login screen that includes an optional "connect with Facebook" button.  The interaction's JSP will probably want to take this list into account when showing or hiding various options.
      9. Make a list of all other interactions, and put that list into the HttpServletResponse.  The interaction's JSP should display these options somewhere so that the user can pick one of these alternatives if necessary.
   4. Display the interaction's JSP page
   5. Follow the interaction's code.
   6. Once the interaction has been completed, go back to step "a" until either 1) LOA is fulfilled (see step "b"); or 2) no rows can be found that will satisfy the policy (see step c. iii.)
   7. The server adds all relevant LOA data to the user's session authentication object's, generates the service ticket, and later includes those LOA details in the ticket validation response.