Support for LoA in CAS

 

 

Level Of Assurance

Developers : Marvin & Jérôme

Add the concept of LOA in CAS server : Level Of Assurance - Head document.

This feature is dependent on MFA being available and will be done in conjunction with CAS4.0 Protocol Rev.  Targeting CAS 4.1/5.0

The reason I write this Request for Change on the whislist is that some of us CAS users in Sweden has found that different application needs different assurance levels regarding the authentication handler and the user identity. For example a personalized page may just need an simple self asserted identity, a student portal need an proofed identity with a username and password login and a web page where examiner report the students results may need a onetime password (OTP) or certificate login. What we can see there is a good "industry standard" for level of assurance in the combination of OMB M-04-04 (http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf) and NIST SP800-63 (http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf). To go the technical way to say that we demand OTP for login or username/password for login due to the fact that the login technique changes via time and is a question for the CAS server not the application server. So what we want to do is to make CAS level of assurance aware. To use multiple CAS installations to accommodate this functionality is not a very good solution due to that than you need to install, configure and support multiple CAS installations. Furthermore the application deployers must think more than once when they configure which CAS server that should be used for the application.

The solution is to add an optional parameter demandLoA to the /login credential requestor to demand a lowest combined level of assurance for the authentication. The combined level of assurance in this scenario is the lowest level of assurance of the areas registration and identity proofing, credential management and tokens used for proving identity. The other two areas in NIST level of assurance must be seen in the light of CAS itself. If the optional parameter is not available in the /login URI then a predefined level of assurance should be used.

To evaluate the registration and identity proofing level of assurance CAS need to know about under what level of assurance a specific user got his electronic identity. This can be done for example via the LDAP attribute defined in FAME-PERMIS Definition of the LoA Attribute (http://www.fame-permis.org/loa.html) or predefined for all users in the configuration for CAS. There is also work in progress on an attribute (possibly eduPersonAssurance) for Level of Assurance for the LDAP object class eduPerson. What authentication handler, or handlers, that is valid for each level of assurance should be defined in the configuration of CAS.

The login page must be configured to handle multiple authentication handlers and present a choice of authentication handler where the combined level of assurance is equal or higher than the demanded level of assurance.

 Pål Axelsson, Uppsala universitet, for SWAMI* CAS Special Interest Group
*Swedish Alliance for Middleware Infrastructure, SWAMI, is the organization for middleware cooperation in the Swedish higher education community. (http://www.swami.se)