Authentication and authorization ensure that the right people have the right access to the right services.
- Verify their identity (authentication)
- Ensure that they are eligible for and allowed to use those services (authorization)
Foundational to authentication and authorization at U-M is the identity information in systems of record (such as those for employee and student records). In the MCommunity Directory, identity information from multiple systems of record across the university is pulled together. Unit faculty and staff can request administrative access to MCommunity for identity verification, authorization and other work-related purposes (see LDAP Access to the MCommunity Directory). Units should use these enterprise directory services and avoid creating local versions.
Authentication services and processes are used to verify that people, devices, and processes really are who and what they claim to be—to verify identity. Authentication services include passwords (something you know), biometrics (something you are), and two-factor authentication (something you have). They verify that the person using an account is indeed the actual account holder. Strong authentication protocols help protect personal and U-M information and prevent misuse of university resources.
Authorization services deal with permissions—who is allowed access and what they are permitted to do (for example, view or edit). For example:
- U-M faculty, staff, students, and sponsored affiliates are authorized to use the standard computing services (with some variation depending on which campus they are affiliated with).
- Units may authorize people with unit-specific roles to access unit systems and applications.
Use University Services
The university's authentication and authorization services include Active Directory, single sign-on (using Shibboleth), and Duo two-factor authentication. Social login is an option if you want to allow guest access.
Integrate university authentication and authorization services with your unit services and applications, including third-party services that your unit purchases, whenever possible. These services meet the requirements in Access, Authorization, and Authentication Management (DS-22). You are responsible for using, and integrating with, the services in ways that comply with DS-22.
Users of university services are expected to choose secure passwords and protect them. See Manage Your Passwords.
Or Build the Requirements into Your Services
If you use other authentication and authorization services for university purposes, including IT services managed for research projects, you are responsible for meeting the requirements below.
Implement Two-Factor for Unit-Managed Systems
Two-factor (Duo) authentication for all U-M systems and applications accessed through U-M Weblogin is required for all faculty, staff, student employees, and sponsored affiliates. In addition, two-factor authentication must be implemented for unit-managed systems that store or access sensitive university data classified as Restricted or High. It is recommended for systems that store or access data classified as Moderate and Low and for privileged accounts. See Implementing Duo for U-M Systems & Services.
Manage Passwords for Your Services and Apps Securely
- Mask passwords. Password masking (for example, replacing password characters with asterisks or bullets as they are typed) should be the default for all U-M login screens so that passwords are not visible.
- Set strong password complexity requirements. If you allow users to create passwords for unit-specific systems and applications, require that those passwords be strong. Use the password complexity requirements for UMICH passwords as a guide.
- Prevent password reuse. Do not allow users to choose previously used passwords when they change their password.
- Require a password for each user. Do not allow shared passwords.
- Encrypt passwords. Never allow passwords to be transmitted or stored anywhere as clear text.
- Set a password lockout. Lock users out after a predetermined number of invalid login attempts.
- Require that compromised passwords be changed. If a password has been improperly disclosed, accessed, or used by an unauthorized person, it should be changed immediately.
- Check for inadvertent password storage. Ensure that processes in your apps and services (for example, debugging processes) do not log and store passwords inadvertently.
Lock Sessions After Inactivity
Set your system to end sessions after a predetermined time limit, and require login for re-entry. Set shorter time-out periods for systems that store more sensitive data. For example, the session timeout for Weblogin generally is 120 minutes, but the session timeout for UMICH Account Management is seven minutes without activity. The session timeout for Employee Self Service in Wolverine Access is 30 minutes.