Enterprise Authentication, Authorization, and Access Policy
Policy Number: IT-15
Date Drafted: 11/01/2002
Date Posted for Review: 11/01/2002
Approved Date: 04/12/2005
Approved Date: 04/09/2019
Reviewed Date: 09/27/2023
Introduction
The Enterprise Authentication, Authorization and Access policy describes a fully integrated method for verifying the identity of all persons in the university community, granting access to Institutional Data and securing physical devices allowed to access that data.
Definitions
Generic access refers to access using a service account rather than individual (e.g., HawkID) account. Audit requirements may limit the use of generic access.
Enterprise Authentication is the service defined herein.
Enterprise Service is a service, such as e-mail or calendar, supported by any campus IT provider that trusts the entire multi-domain enterprise authentication infrastructure as authentication for the service.
Enterprise Credentials are the combination of HawkID and HawkID password. These credentials may not be reused for services not using the Enterprise Authentication Service.
Local Service is a service, supported by any campus IT provider that authenticates its user base to a subset of domains in the forest, or to a local accounts database.
Enterprise Directory Service (EDS) is an authoritative source for institutional data such as IDs, e-mail, service eligibility indicators, and other derived attributes. EDS consolidates identity information for support of enterprise authentication.
Microsoft Active Directory (AD) is a directory that supports Windows services. AD is Microsoft’s implementation of an LDAP directory with a number of enhancements for Kerberos support and workstation management.
Campus Active Directory uiowa.edu Forest is the shared services forest, sponsored by a partnership of ITS and HCIS, that provides the infrastructure for campus Windows servers and workstations connected to the campus network. Active Directory is the current campus production authentication engine.
HawkID is the campus-wide standard for a unique login identifier (ID) for each person in the University of Iowa community. This HawkID, therefore, is the account ID used in the enterprise authentication service.
HawkID Password is the password associated with the HawkID in the enterprise authentication service.
Local Service ID is the service-specific login ID for a service not yet enabled to use enterprise authentication. Service providers are encouraged to use the HawkID as this local service ID.
Local Service Password is the service-specific password for a locally-authenticated service. If there are security issues in the local service, such as use of clear-text passwords, the local service password should not be synchronized with the HawkID password.
Part 1: Authentication
Introduction
Authentication is the mechanism that verifies that an individual is who they claim to be. Verification shall be based on one of more of the following (depending on security requirements):
1) knowledge (e.g. password, PIN);
2) possession (e.g. smart card, smart phone, security fob);
3) inherence (e.g. fingerprint, retinal scan).
Enterprise level directories provide the authentication infrastructure to improve the user and IT provider experience. Data in the authentication directory is fed from authoritative sources, making the data dependable and available for decisions. Central authentication makes the login process uniform for the user and allows the provider to concentrate on the specifics of their service. Enterprise authentication offers opportunities for services beyond the campus boundaries, where appropriate, for activities such as student recruiting, patient care or alumni relationship services.
Policy Statements
- The fundamental underlying premise to the Enterprise Authentication Service is that there is a single unique account ID per person in the forest. That is, a person’s HawkID will appear in one and only one domain in the forest. This guarantees the uniqueness of the enterprise HawkID and HawkID password pair. Account IDs in all domains of the Campus Forest will be maintained in sync with the Enterprise Directory HawkID assignment.
- The domain administrators of each domain in the forest are responsible for maintaining accounts for the persons for whom they have responsibility, in support of the enterprise authentication requirements identified by campus IT service providers.
Enterprise Directory Service
The Enterprise Directory Service is the authoritative source for assignment and maintenance of HawkIDs used in deployment of campus services. As a repository for key personal and application attributes from authoritative institutional sources, the directory service implements business rules that support institutional roles. Domain assignments are based on current roles.
HawkID and HawkID Password
The HawkID is the account ID used in the enterprise authentication service. The associated password is the HawkID Password.
For service environments that are not able to fully utilize the enterprise authentication service, the IT provider is encouraged to use the HawkID as the service login ID. The associated password should be referred to as a service-specific password.
Multi-factor Authentication
Multi-factor authentication is based on two or more of the verification options presented in the introduction to Part 1. Multi-factor authentication is strongly encouraged for authentication to systems or services identified as having Critical or Restricted information. In addition, multi-factor authentication may be required by law or regulatory requirements.
Resource or Service ID Authentication
- Local domain resource or service IDs, such as IDs created for applications, testing, or for departmental or generic use IDs typically assigned as web site and e-mail service IDs, may exist in Active Directory without a corresponding entry in the Enterprise Directory Service.
- Resource IDs that are used to authenticate to enterprise services must not collide with existing HawkIDs, and therefore must be registered within the Enterprise Directory Service. Domain specific test IDs with local impact only, should be created in accordance with the service ID naming conventions. (See “Enterprise Login ID Standard”.)
Campus Software Acquisitions and Development
Locally developed software should implement Enterprise Authentication whenever possible. Procurement of third party software or services must include these considerations:
- Support for secure authentication.
- Interoperability with the current Enterprise Authentication implementation
- Support for login IDs consistent with the “Enterprise Login ID Standard.”
If enterprise authentication is not possible, the service or software must be reviewed by the Information Security and Policy Office.
Local Authentication
Services that cannot use the current Enterprise Authentication service must rely on local authentication until such time as the service can use Active Directory based authentication. Plans should be developed to determine how the service will transition toward enterprise authentication in the future.
Clear-Text and Encrypted Passwords
The enterprise authentication service is intended for use by campus services that provide encrypted password streams; legacy applications using clear-text passwords are NOT allowed. All systems and applications not using the enterprise authentication service should use encrypted passwords to access/authenticate.
Users may not reuse enterprise credentials for systems not using the enterprise authentication service.
Part 2: Authorization
Authorization entails both technical and policy control of access to institutional data (see Institutional Data Policy).
For non-public data, criteria must be established by the Data Steward for account or service eligibility, creation, maintenance, data retention and expiration.
- Access to Critical or Restricted data must be individually authorized by the Data Steward, and an annual confidentiality agreement must be acknowledged or signed by all authorized users.
- Data Custodians must periodically review user privileges and modify, remove, or deactivate accounts when roles change. Data stewards will define the review period in conjunction with data custodians.
Part 3: Access
Policy Statements
Access Control
- Inactivity time-outs must be implemented for workstations that access Critical or Restricted data. The period of inactivity shall be no longer than 20 minutes in publicly accessible areas. A shorter timeout period may be required by law or regulatory requirements. An exception may be granted by the Information Security and Policy Office where necessary for business functions (e.g., to prevent timeout during patient care).
- All devices with non-public institutional data should be kept in a physically secure (locked) location when staff are not present.
- The level of physical access control for any area that contains institutional data is determined by the level of risk and exposure. Data centers and other locations where non-public data is housed must be protected at all times with physical access controls such as keys, biometrics or proximity cards.
- Physical access to data centers or any area with Critical or Restricted data must be monitored and logged through electronic logging or tracking mechanisms. Visitors and other maintenance personnel must be escorted by authorized operations staff when in a data center.
- Media (e.g., paper records, digital devices and peripherals) that contain Critical or Restricted data must be secured during transportation and disposal.
Access to Data for Automated Operations (Generic, Scheduled, or Task Initiated Access)
Generic (service account) access to information stored in databases is allowed only for non-interactive tasks. A non-interactive task is one that is scheduled to run automatically or one that is triggered by a series of events. It is automatically initiated, and the output is automatically handled by software. This includes automatic downloads and other linkages for data transfer.
- Requests for generic access to information stored in databases for automated operations are made to the Data Steward, and if approved, will be executed by the Data Custodian.
- Generic account passwords must be protected from unauthorized disclosure. Hard coded passwords that reside on a client machine or in an application must be reasonably protected (i.e. encrypted), commensurate with risk and the available platform or application security features.
- Information access via generic accounts must be limited to the specific task(s) required.
Access to Systems or Applications administered by contractors
A University-appointed Data Custodian must oversee administrative duties performed by contractors to ensure their compliance with security policies and standards. Contractor activities will be controlled and monitored as follows:
- Contractor user accounts must not allow more system or network privileges than necessary to meet contract requirements.
- Secure authentication of contractors is required.
- Logging and auditing of system accesses and activity is required.
- Contractors will be required to sign a confidentiality agreement before handling all non-public institutional data.
Related Policies, References and Attachments
This collection of University of Iowa Information Technology policies and procedures contains acceptable use, security, networking, administrative, and academic policies that have been developed to supplement and clarify University of Iowa policy.
These policies and procedures are incorporated into the University of Operations Manual (http://opsmanual.uiowa.edu) by reference, per the Policy on Acceptable Use of Information Technology Resources (http://opsmanual.uiowa.edu/community-policies/acceptable-use-information-technology-resources)
Requests for an exception to IT Policies & Standards can be submitted via the webform link here: Request a Security Exception