Date: Fri, 29 Mar 2024 07:54:38 +0000 (UTC) Message-ID: <632336014.7657.1711698878860@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7656_1598692357.1711698878859" ------=_Part_7656_1598692357.1711698878859 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
What this is: The OSIdM4HE work has identified "Authentica= tion" 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 invi= te further discussion and participation, and eventual formation of a subtea= m and workstream.
Higher Education environments are rarely able to rely on a single authen= tication service or technology to meet all needs. Different business proces= ses often have differing requirements for the overall strength of authentic= ation. For example, campus authentication processes for user access to high= ly 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 authen= tication assumptions made by application designers. It is still too often t= he case that the choice of authentication technology is effectively made by= the application provider. A likely focus for the CIFER authentication effo= rt 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 authent= ication services.
The key work for this effort will be to gain consensus on a a set of fea= ture requirements for authentication services. Once this feature list is co= mplete, we can move forward in a parallel process to:
A fundamental underpinning for user authentication its reliance on the m= apping between the physical individual and the identifier used to represent= that individual in the electronic world, e.g., the user=E2=80=99s login-id= . The Identity Proofing process used to perform this mapping and the docume= ntation checked during the proofing process are some of the key factors tha= t determine the Level of Assurance (LoA), i.e., the overall strength of the= authentication process. Other important factors include the credential iss= uing process and credential maintenance services (e.g., password changes an= d reset).
An early part of the CIFER authentication work should focus on campus us= e cases to understand what set or sets of LoAs meet the needs of most campu= ses. 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 = =E2=80=9CGold=E2=80=9D, 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 ca= mpus requirements to InCommon LoAs to determine, for example, if the Bronze= LoA will meet the needs of the vast majority of campus applications and be= come the standard assurance level. The use case mapping process will also d= etermine the extent of campus requirements for higher LoAs such as InCommon= Silver and the potential need for a strong =E2=80=9CGold=E2=80=9D Level of= Assurance.
The CIFER campus use case process should also be designed to inventory t= he set of authentication technologies presently in use by campus applicatio= ns. This list will be used to ensure that the back-end infrastructure is ab= le to support the needed forms authentication services. The use case proces= s 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 ap= plication requirements and (hopefully) common expectations for tolerance of= risk for these application types. This information could be used to tune t= he 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 g= ateway
account linking: Tools and patterns for applications to= deal with users with many accounts/logins.
eduroam: eduroam is a world-wide federation supporting wirel= ess network access using RADIUS, EAP, and 802.1x technology. eduroam-US is the= US participant.
non-web federated authentication: Moonshot, SAML-ECP, e= tc
MIT Kerberos, Heimdal
CAS, Shibboleth, simpleSAMLphp
LDAP directory (OpenLDAP, etc etc)
FreeRADIUS
(Active Directory)
(anything in PKI? InCommon cert service?)
C= AS-PM for password management