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.

Authentication Methods

NOT in order of "trustworthiness"

• LDAP username+passwordSend code to email (e.g. for password reset)
  • 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