ÍÃ×ÓÏÈÉú´«Ã½ÎÄ»¯×÷Æ· Standard for Authentication
Effective Date: 6/1/2022
Abstract/Summary
This document defines the standard patterns for end-user authentication for IT services at ÍÃ×ÓÏÈÉú´«Ã½ÎÄ»¯×÷Æ·. These standards are important for the overall security of the campus and serve to improve the user experience through consistent login experiences and maximizing single-sign-on capabilities. Campus IT service providers should understand the available options and high-level features/capabilities and make vendors and external providers aware of them as appropriate.
Context
This standard applies to IT services, systems and applications performing end-user authentication at ÍÃ×ÓÏÈÉú´«Ã½ÎÄ»¯×÷Æ· where the users are students, faculty, staff, and other affiliates with an Identikey. Special purpose systems and applications with a very small number of users (fewer than twenty) are exempted, however all systems that can reasonably follow this standard should do so. Services and applications that authenticate users who don’t have an IdentiKey must use an authentication method approved by the IT Security Office.
Standard StatementÌý
Below are available authentication services managed by OIT that are to be used to authenticate end-users for IT services. Local application accounts where logins and passwords are managed and stored by the application or application provider are not acceptable. All services leverage the same user database and can authenticate all ÍÃ×ÓÏÈÉú´«Ã½ÎÄ»¯×÷Æ· Identikey accounts (employees, students, etc.).
If possible, one of the following two authentication services should be used:
- Federated Identity Services
- Technology: SAML2 or OIDC (OAuth) Identity Provider (IdP) using Shibboleth
- Features
- Single-sign-on capabilities (e.g. SSO from BuffPortal)
- Application doesn’t handle passwords
- Flexibility in providing authorization data (from LDAP, EDB, Grouper and Active Directory)
- Optional Duo multifactor authentication available
- Part of higher education InCommon federation, making integration easier for some applications/vendors
- Accessible from anywhere on the internet
- Limitations:
- Application must support SAML2 or OAuth
Ìý
- Application must support SAML2 or OAuth
- Microsoft Azure Active Directory (MS Azure cloud)
- Technology: Microsoft Azure (SAML2, OIDC(OAuth), SCIM)
- Features
- Easy integration for Microsoft Azure technologies
- Easy integration for SCIM supporting services iii. Leverage the Grouper Service or AD groups for access management
- Microsoft multifactor authentication option
- Accessible from anywhere on the internet
- Flexibility in providing authorization data (from Grouper and Active Directory)
- Application and OS Single Sign-on for Azure hosted applications (Outlook, Office, OneDrive, Teams, Web hosted)
- Limitations
- Generally non-sensitive user attributes only
- ​If neither of the above methods are possible, applications may use one of the following:
Ìý
- Microsoft Active Directory (on-premise)
- Technology: LDAPS or Kerberos
- Features
- Easy integration for Microsoft products or Microsoft-centric vendors
- Leverage the Grouper service or AD groups for access management
- Limitations
- Accessible from ÍÃ×ÓÏÈÉú´«Ã½ÎÄ»¯×÷Æ· campus network
- Generally non-sensitive user attributes only
- No multifactor authentication available
Ìý
- Enterprise Directory Service: Only to be used if none of the above options are available
- Technology: LDAPS
- Features
- Accessible from anywhere on the internet
- More flexibility for securely storing sensitive data as attributes (granular access controls)
- Limitations
- No multifactor authentication available
Multicampus authenticationÌý
For multi-campus authentication needs (end-users from all campus being able to log into the same IT service), contact University Information Services (UIS) in System Administration.
Important Implications and Considerations
Multifactor authentication requirements may also apply. See the multifactor authentication standard.