What this is: The OSIdM4HE work has identified "Authentication" as a significant element of an IAM system. Unlike the other areas, a team to look at authentication-related requirements and gaps is still to be convened. This page collects some initial items in this area to invite further discussion and participation, and eventual formation of a subteam and workstream.
Higher Education environments are rarely able to rely on a single authentication service or technology to meet all needs. Different business processes often have differing requirements for the overall strength of authentication. For example, campus authentication processes for user access to highly sensitive data are typically quite different from those applied when the same user authenticates to read email and access files stored in personal folders. Likewise, a single technical solution is rarely viable due to the differing strength requirements and, more importantly, the differing authentication assumptions made by application designers. It is still too often the case that the choice of authentication technology is effectively made by the application provider. A likely focus for the CIFER authentication effort will be a design that provides a single back-end support infrastructure that manages the user authentication credential lifecycle and provides, or integrates with, a variety of front-end user and application facing authentication services.
The key work for this effort will be to gain consensus on a a set of feature requirements for authentication services. Once this feature list is complete, we can move forward in a parallel process to:
A fundamental underpinning for user authentication its reliance on the mapping between the physical individual and the identifier used to represent that individual in the electronic world, e.g., the user’s login-id. The Identity Proofing process used to perform this mapping and the documentation checked during the proofing process are some of the key factors that determine the Level of Assurance (LoA), i.e., the overall strength of the authentication process. Other important factors include the credential issuing process and credential maintenance services (e.g., password changes and reset).
An early part of the CIFER authentication work should focus on campus use cases to understand what set or sets of LoAs meet the needs of most campuses. This effort will likely be guided by the work done by InCommon on the Bronze and Silver LoAs. These LoAs were, in turn, initially guided by NIST 800-63. A High Assurance LoA, similar to what is anticipated for InCommon “Gold”, might also be needed to meet the business needs of the various campus business processes.
A likely first step for the CIFER authentication effort may be to map campus requirements to InCommon LoAs to determine, for example, if the Bronze LoA will meet the needs of the vast majority of campus applications and become the standard assurance level. The use case mapping process will also determine the extent of campus requirements for higher LoAs such as InCommon Silver and the potential need for a strong “Gold” Level of Assurance.
The CIFER campus use case process should also be designed to inventory the set of authentication technologies presently in use by campus applications. This list will be used to ensure that the back-end infrastructure is able to support the needed forms authentication services. The use case process will most likely determine that the back-end infrastructure will at least need to support the following types of services:
The campus authentication use case effort should yield common sets of application requirements and (hopefully) common expectations for tolerance of risk for these application types. This information could be used to tune the default CIFER settings and inform InCommon Assurance Levels (if any need for update is detected).
One likely focus for this area is to create a set of default and vetted policies but help influence the software design such that it is relatively easy for
account, subscriber
credentials, credential assignment, credential store
authentication service
authentication protocols, federated authentication
password-based authentication
strong authentication, PKI, two-factor, hard/soft tokens
web-redirect-based authentication
password management, key management
monitoring and risk-based authentication
assurance
password management: A collection of utilities dealing with password changing.
strong authentication:
risk-based authentication: methods used by large-scale consumer and commercial sites to reduce password theft and abuse.
mobile authentication: Authentication methods tailored to the needs of mobile devices
process authentication: Authentication methods tailored to the needs of processes and software clients.
social identity: social2SAML web authentication gateway
account linking: Tools and patterns for applications to deal with users with many accounts/logins.
eduroam: eduroam is a world-wide federation supporting wireless network access using RADIUS, EAP, and 802.1x technology. eduroam-US is the US participant.
non-web federated authentication: Moonshot, SAML-ECP, etc
MIT Kerberos, Heimdal
CAS, Shibboleth, simpleSAMLphp
LDAP directory (OpenLDAP, etc etc)
FreeRADIUS
(Active Directory)
(anything in PKI? InCommon cert service?)
CAS-PM for password management