Document Name: NCSA Identity & Access Management Policy |
NCSA maintains its own user database, authentication systems, and authorization framework distinct from the University. This policy sets the requirements for these systems and their associated processes, such as, provisioning, deprovisioning, account lockouts, etc.
This policy applies only to NCSA-specific services and accounts, and not those of other University systems or our partners.
Users will be presented an NCSA Terms of Service when their accounts are created and whenever there are significant changes. Group owners may add additional terms for their projects as part of the group enrollment process, however, these must not conflict with University or NCSA policy elsewhere.
When an NCSA user account is created, it is automatically assigned a unique identifier, which is a primary key in the NCSA user database. All NCSA logon IDs map to a single such identifier. This allows the database implementation to enforce uniqueness of user account login IDs.
This login ID can usually be selected by the user at the time of account creation, assuming it is available. Certain character restrictions apply, and names cannot ever be reassigned even if associated accounts are inactive. NCSA also reserves the right to reject any logon ID deemed inappropriate.
This login ID is consistent across all NCSA authentication systems. Therefore, NCSA staff can use system access logs to consistently identify actions across any NCSA system to a unique person.
Usernames are between 3 and 20 characters such that they
Service accounts may contain the special characters "-" or "_". These accounts are required for use by multiple persons as user account passwords cannot be shared. Service account requests must be approved by the Security Office and audited annually.
The processes to issue new credentials and reset passphrases are designed to be secure in the sense that the original party who started the process is the same person that receives the credential and can later reset it. However, the common process does not by itself validate more than an email address.
NCSA and other University staff are additionally vetted as part of the human resource processes of the UIUC campus when they fill out tax forms, set up direct deposits, and receive their iCard with a photo ID and unique identifier. This same University identifier is tied to their NCSA identity and linked to their campus network ID when their NCSA staff account is created. Therefore, NCSA relies upon the University to vet workforce members to their real names.
NCSA supports many user communities both inside and outside the University with additional vetting requirements. Such verification processes must be determined by group managers and can be tied to group enrollment and approval processes. HIPAA Business Associates are responsible for vetting their own workforce and managing which of them has access to the associate's data at NCSA.
NCSA passwords are case-sensitive with the following properties for passwords between 8 and 15 characters:
Passwords greater than 15 characters need only:
NCSA requires multi-factor authentication for system administration, accessing resources with high-risk data, and on shared-user systems providing command line access.
Because these systems have extra per user costs, they are not made available to all projects. An NCSA project or partner must pay for NCSA multi-factor tokens/licenses for non-staff.
Multiple failed login attempts may lockout access based on the IP address of the client system. Accounts may also be suspended globally by the Security Office.
Newly created accounts have no authorizations to access resources until they are specifically added to a group.
NCSA operates a centralized authorization service for systems in the High Performance Data Center zone (See NCSA Network Security Policy). Local password files and other authentication/authorization services can only be used if a formal exception is approved by the NCSA Information Infrastructure Board (IIB).
Staff are removed from the NCSA staff group during the NCSA exit process as stated in the NCSA Information Security Policy. Group owners are responsible for promptly removing users from other groups as roles and access needs change.
Group owners must audit their membership in their groups at least annually. This does not apply to system generated groups driven by processes like HR transactions.
The security team must have a method to perform real-time queries against authorization and authentication logs, for both failed and successful attempts. These logs must contain information on authentication or authorization events to determine time, target system, account used, and source host. Other information may be required to support the non-security, business needs of the Center.
NCSA minimally collects the following information when creating an account:
NCSA may collect the following information and some projects/activities may require:
Projects may not collect information disallowed by NCSA or University policy elsewhere.
As an identity provider, NCSA may share full names, account names, email addresses, and provided user type attributes of authenticated users as part of the InCommon Research and Scholarship program. No additional information are shared publicly.
NCSA does not sell any user information to third parties.
Access to Amazon Web Services (AWS) is available through the University of Illinois (see: https://aws.illinois.edu).
Whether an NCSA managed asset is hosted in the cloud or on site, all NCSA security policies still apply to the individual hosts including this IAM policy. NCSA IAM services, such as, Kerberos, LDAP, shibboleth, and Duo are available and should be used the same as they would for a local host.
Amazon also provides the ability to use other IAM systems for the management console besides local Amazon accounts. The following methods are acceptable for authenticating to the AWS Management Console:
The following methods are acceptable for managing authorization to the AWS Management Console:
Identities from external providers may be used for access to applications with baseline authentication needs, i.e., without requirements for higher level of assurance such as multi-factor authentication or face-to-face identity vetting. Only one account per IdP can be bound to a user's NCSA identity. NCSA resources may choose from the following valid supported identity providers; the default for a resource is to only access NCSA identities and approval is needed from the CISO to allow the use of linked identities:
Support for higher level of assurance from external identity providers requires custom configuration. Contact help+idp@ncsa.illinois.edu for assistance with higher level of assurance use cases. Changes in the list of acceptable federated IdPs is approved by the CISO.
NCSA supports Shibboleth and OpenID Connect/OAuth services to allow other organizations to securely use NCSA identities. New interfaces to NCSA IdM services must be approved by the IIB before being added.
There are exceptions and special cases to any policy. Requests for exceptions should be made to the NCSA Security Office and may be approved by either that office or the NCSA Director's Office.
This policy is reviewed annually by the Security Office. Feedback is solicited from the Information Infrastructure Board for any recommended changes. New versions are approved by the NCSA Director's Office.