Overview

This is a description of how Cru might want to use Levels of Assurance in our identity management system (which uses CAS as its primary component).

Some notes to help understand our needs:

• In our environment, the terms "students" and "alumni" mean slightly different things than they would mean to those in the higher education field.  For us, "students" mean the subset of students from around the country who participate in our programs and clubs.  The term "alumni" refers to those who have participated in our programs and clubs while attending university but have since moved on to another phase of life.
• As a non-profit, the majority of our employees and volunteers participate in at least some form of fund raising and donor relationship management.

Background

Authentication Methods

NOT in order of "trustworthiness"

• 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 and Server Config

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" / Policy 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.

*Our "Trusted Partner" is running a CAS server and we'll be using a CAS client to provide a form of federation, similar to "connect using facebook".

Interactions for Authentication Handlers

Each handler has an interaction that is used to gather credentials for that handler.

Other Possible Requirements

We are also considering other requirements.

• For some services, if the request not coming from an IP within the user's home country, require Google Authenticator or SMS code in addition to LDAP.
• For some services, require user to register device/browser (like the way Facebook works).  Maybe require extra authentication (like email code or secret Q&A) if registering a new machine.  This might replace the "on the company LAN" LOA constraint.
• Add the ability for users to generate a temporary-use token that can be given out (e.g. to allow tech-support staff to temporarily login as the user).  This type of credential would have an LOA equal to the authentication method that was used to generate the token... up to a maximum probably equivalent to a medium-strenth password.  Some services (such as password reset) would need to be able to opt-out of supporting this feature.  If the LOA subsystem is flexible enough, it could easily support this kind of feature.

LOA logic that should be handled by interrupt screens and triggered by the user's role

• If user is an employee, require at least medium password policy  (otherwise, only require the weak password policy)
• If user is given mega-admin access to HR or Financials, require strong password policy
• If user is given normal departmental access to HR or Financials, require registration of SMS cell number or Google Authenticator
• If user is placed in the "executives" group, require strong password policy
• If user is an employee, recommend (or maybe require) registration of SMS cell number or Google Authenticator

Scenarios and Implementation

An HR employee outside the LAN accesses event registration to register for an event, then accesses the social networking site, then accesses employee portal, then accesses PeopleSoft HR.

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.  It chooses "basic login" because it has the highest precedence.  When showing the login page as part of the interaction, the system injects the list of alternative interactions
   6. The CAS server shows the basic login JSP page (as defined by the interaction). The JSP page includes a fragment that lists the alternative interactions with links and images (e.g. "Connect with Facebook" showing the Facebook logo).
   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 alternate interactions.
   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 alternate interactions.
   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. 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"
   2. This LOA requirement is sufficient, so the CAS server generates the service ticket, which is accepted by the servlet filter.
   3. PeopleSoft looks up the user's role and determines that they have the ability to manage employees, so they must conform to "Policy B."
   4. 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.)
   5. The server looks up in the LOA policy and finds the rows that will satisfy this requirement.
   6. 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.
   7. 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.)
   8. The CAS server is left with two possible rows in the policy table: "ldap_medium_google" and "ldap_medium_sms"
   9. The CAS server determines that the user has already fulfilled the "ldap" requirement for these rows.
   10. The CAS server looks at the first unfulfilled authentication handler for each row.  It finds: "sms" and "google".
   11. The server finds the two interactions for these two authentication handlers and chooses the one with highest precedence, which in this case is the "google authenticator" screen.  Again, the JSP page includes a snippet of code that shows the list of alternative interactions, which in this case is just a link for the SMS Code interaction.
   12. Because the user does not have a smartphone, she clicks the link to use the SMS Code 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).
   13. The user receives the message and types the code into the screen. It is validated.
   14. 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.
   15. 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).  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 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 based on the lists of authentication handlers for each row.  Remove all already-authenticated handlers from the chains.  Remove any empty 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 all alternate interactions, and put that list into the HttpServletResponse.  Every interaction's JSP should include a standard snippet of code that displays these options, allowing the user can pick one of these alternatives if desired.
      9. Probably:  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 that 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.
      10. Display the interaction's JSP page
          1. Note that some interactions, even user-interactive ones, might not need to show a JSP page by default.  For example, an OAuth interaction could immediately redirect the user to the OAuth server's login page.  However, this would present a problem if there are any alternate interactions, because the user would not have been given the chance to choose one of the alternates.  In this case, a JSP probably should to be displayed to give the user the choice.
   4. Follow the interaction's code.
   5. 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.)
   6. 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.