...
| Table of Contents | ||
|---|---|---|
|
Mission & Purpose
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.
Scope
This policy applies only to NCSA-specific services and accounts, and not those of other University systems or our partners.
...
Policy
User Enrollment
Terms of Service
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.
User ID Assignment
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.
...
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.
Identity Vetting
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 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.
Authentication
Passwords
NCSA passwords are case-sensitive with the following properties for passwords between 8 and 15 characters:
...
- contain at least one uppercase and one lowercase letter
- NOT contain 4 sequential characters of your logon ID
- be different than the previous password
Multi-factor
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.
Account Lockouts
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.
Authorization & Groups
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).
Deprovisioning
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.
Auditing & Logging
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.
Privacy
Information Collected
NCSA minimally collects the following information when creating an account:
...
Projects may not collect information disallowed by NCSA or University policy elsewhere.
Sharing of Information
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.
Accessing External Services
Amazon Web Services
Access to Amazon Web Services (AWS) is available through the University of Illinois (see: https://aws.illinois.edu).
AWS Instances
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.
AWS Console
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:
...
- For campus identities, map Active Directory group memberships to AWS Roles. An Admin group/role is set up as part of University of Illinois AWS account setup.
- For NCSA identities, map LDAP group memberships to AWS Roles (requires custom setup: contact help+idp@ncsa.illinois.edu for assistance).
- Access to the AWS User account, for emergencies during illinois.edu outages, is managed via a LastPass Enterprise shared folder, shared only with specific personnel who are responsible for emergency operations.
Policy for Accepting Federated IdPs
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.
Exporting NCSA Identities
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.
...
Exceptions Process
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.
Updates
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.
References
...