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 Policy

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.

* 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"

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

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, 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 at the first unfulfilled authentication handler for each row.  It finds: "sms" and "google".
   9. The server finds that these two authentication handlers utilize different interactions, so it presents the user with a screen for the user to choose one of these two options.
   10. Because the user does not have a smartphone, she selects the SMS option.  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).
   11. The user receives the message and types the code into the screen. It is validated.
   12. 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.
   13. 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 PeopleSoft code once again looks up the user's role and uses this when ensuring that the LOA data is acceptable.