OIT Identity Management

Type of Policy: 
Administrative
Effective Date: 
January 2011
Last Revised: 
January 2011
Review Date: 
January 2014
Policy Owner: 
Info Tech- Information Security
Contact Name: 
Jimmy Lummis
Contact Title: 
Information Security Policy and Compliance Manager
Contact Email: 
jimmy.lummis@oit.gatech.edu
Reason for Policy: 

This document is in direct support of the Georgia Institute of Technology Computer and Network Usage and Security Policy (CNUSP). Georgia Tech has developed and built a mature Identity Management (IDM) infrastructure to support users and application owners/developers. The 3 goals of the program are:

  1. Eliminate the unencrypted transmission of passwords over the network.
  2. Enforce and define how users are authenticated and then authorized to view Georgia Tech data.
  3. Define how the IDM infrastructure is secured and monitored.

With this in mind, the IDM infrastructure exists to protect identities and credentials of Georgia Tech users, as well as provide a central way to communicate changes, issues, or other information to all Georgia Tech users that are in the campus IDM service.

Policy Statement: 
Georgia Tech Authentication Services

 Management of the Georgia Tech Authentication Services

OIT is responsible for managing all campus-wide authentication services.

Any authentication services not run by OIT are the responsibility of the Unit that deploys and manages the service. Any authentication repository run by another campus unit should be disclosed to OIT for documentation.

Registration to use Georgia Tech Authentication Services

The Georgia Tech authentication services may require compulsory registration, depending on which IDM service is to be used.

Any applications in Georgia Tech network space may use CAS or Active Directory to authenticate users without registering the application with OIT. However, if the application exists outside of Georgia Tech (e.g. a 3rd party service or within a non-gatech.edu domain), then the IDM team will need to be consulted to register the service to use one of the authentication services. Services using Kerberos or LDAP require registration with the IDM team.

For more information, refer to the matrix in the following section.

Using Georgia Tech Authentication Services Securely

Applications that use a central authentication service must communicate over a secure channel.

If an application asks for user credentials, the request and reply must be over secure communications (i.e. SSL). If OIT discovers that the communications are not secure (e.g. non-encrypted traffic over port 80/tcp), then all users of the application may need to be notified that their account passwords will need to be changed as a precaution. Furthermore, the service will be further restricted from using central authentication.

Collecting User Information

Applications that use a Georgia Tech authentication service may not collect or harvest user information from the service.

 Collecting and storing user information from the authentication services is strictly prohibited. Authentication must occur as a “pass through” or “hand off” mechanism, where the application asks the central authentication service to authenticate a user.

User Authorization

The Georgia Tech authentication services are only responsible for authenticating users. Authorization of a user must come from the application.

Authentication and Authorization is a two-step process. Central authentication service simply verifies a user is who they say they are based on a known token.

The application is responsible for allowing the user access to the information they are authorized to view/use/modify. Approval to authorize users to view Institute data must be approved by the appropriate data steward Data Access

Authorization must be based on the username/person requesting access, not on a network location (e.g. on campus vs. off campus).

Security & Auditing

OIT will validate services that use CAS and scan these services for any security issues.

OIT will generate regular reports of services using the central authentications services. In addition, the following security checks will be performed on applications:

  • Applications will be scanned for security vulnerabilities on a weekly basis.
  • Application communications channel will be validated (e.g. ensure that the application is authenticating over a secure connection).
  • Authorization levels will be verified via connection attempts.

      

Registration to use Central Authentication Services
ServiceRegistration Required?Registration Information
CAS/ login.gatech.eduNo, if address is on campus (.gatech.edu) Yes, if address is not gatech.edu

Fill out the form at iam.gatech.edu/gted/data_steward_request.html

Specify if SAML data is desired or not.
Specify CAS is the authentication method desired.

A Remedy request will be created. The IAM team will broker the data stewardship request in the background where possible.

KerberosNoNA
AD  
LDAPYes

Fill out the form at https://www.iam.gatech.edu/gted/new_request_form.html to request a GTED LDAP access account and data stewardship approval. Specify what data is desired, the business purpose, and other data as fully as possible. Incomplete forms may delay the process. Specify LDAP is the authentication method desired.

A Remedy request will be created. The IAM team will broker the data stewardship request in the background where possible.

  

Recommended Authorization Strategies for Application Owners
ServiceAuthorization Recommendation
CAS/ login.gatech.edu

Authorization based on GTED attribute values or role membership. Contact the Identity & Access Management team for assistance in determining what these would be for your application.

An example of how this would be implemented would be to use SAML (with your CAS library) or LDAP queries including Apache LDAP authorization.

Kerberos

Authorization based on GTED attribute values or role membership. Contact the Identity & Access Management team for assistance in determining what these would be for your application.

An example of how this would be implemented would be to use LDAP queries including Apache LDAP authorization or application-specific LDAP code.

AD

Authorization based on GTED attribute values or AD role membership. Contact the Identity & Access Management team for assistance in determining what these would be for your application.

An example of how this would be implemented would be to use AD group membership or LDAP queries within your application.

LDAP Authorization based on GTED attribute values or role membership. Contact the Identity & Access Management team for assistance in determining what these would be for your application. An example of how this would be implemented would be to use LDAP queries including Apache LDAP authorization or application-specific LDAP code.

       

Scope: 

This policy applies to all users and applications that utilize Georgia Tech central IDM services. The policy addresses how users are authenticated, not how users are authorized to view data. Prior to authorizing users or a group of users to view an application, the application owner should obtain permission from the appropriate data steward (Data Access Procedures)

.

Policy Terms: 

IDM
Identity management

 

AD
Georgia Tech Active Directory (GTAD) is the centralized Windows Active Directory service for the entire campus that ties into the authentication system and administrative applications. Your GT Active Directory credential (username and password) is the same as your GT Account, so any application that needs to authenticate a GT account can use this service to do so.

References:
www.oit.gatech.edu/service/gtad/windows-active-directory-gtad

Authentication
Authentication is the mechanism whereby systems may securely identify their users. Authentication systems provide answers to the questions:

  • Who is the user?
  • Is the user really who he/she represents himself to be?

CAS, Kerberos, GTED and GTAD can all do authentication.

Authorization
Authorization is the mechanism by which a system determines what level of access a particular authenticated user should have to secured resources controlled by the system.

CAS can provide authorization data via a SAML mechanism for a small number of data elements. GTED and GTAD can provide a wider amount of authorization data.

Application Owner
Technical contact responsible for operating a service or application that uses an authentication service to allow end users access to the application.

CAS
Jasig Central Authentication Service or CAS, is an authentication system originally created by Yale University to provide a trusted way for a web application to authenticate a user. This is the preferred way for a web based application to authenticate GT accounts. References: www.jasig.org/cas

GT Accounts
The GT account is the sign-on credential (name and password) that students, faculty, and staff use to access a wide range of online services at Georgia Tech.

Georgia Tech Authentication Services
CAS, Kerberos, GTED and GTAD can all do authentication. Given a central GT account name and password, they can verify the user against the central account system.

GTED (LDAP)
GTED, the Lightweight Directory Access Protocol (LDAP) based information store contains and maintains Georgia Tech's users and their associated central GT computer accounts. All GT employees and students have a GT account in this data store. GTED is commonly used to authenticate and provide authorization information for applications.

References: 
www.oit.gatech.edu/authentication

Kerberos
OIT provides a campus MIT Kerberos authentication system to provide strong authentication for client/server applications by using strong cryptography.

References:
web.mit.edu/kerberos/

Procedures: 

Procedure Modifications

This policy may be changed by directive from the responsible university officer. Any changes to the policy or procedures must be promptly communicated to the individuals and offices noted in Responsibilities section.

Communication

Upon approval, this policy shall be published on the Georgia Tech website. The following offices and individuals shall be notified via email and/or in writing upon approval of the policy and upon any subsequent revisions or amendments made to the original document:

  • IDM Customers
  • OIT
  • Georgia Tech Data Stewards
  • Georgia Tech IT Directors
  • Georgia Tech CSR Mail List
  • Internal Audit
  • Office of Legal Affairs
Responsibilities: 

OIT

OIT is responsible for:

  • Consulting with application owners on which service would be best to use.
  • Communicating changes/downtimes to the IDM mail list.
  • Manage the Georgia Tech campus IDM services.
  • Scan applications using the IDM services on a regular basis.
  • Test applications using the IDM service to ensure that authentication is occurring over an encrypted channel.

Application owners

Application owners are responsible for:

  • Consulting with OIT on which authentication mechanism to use.
  • Obtain data steward approval for authorizing users to view data.
  • Ensure that authentication occurs over a secure channel.
  • Subscribe to the IDM mail list for announcements (OIT recommends a minimum of 2 people).
  • Annually, reaffirm:
    • Which service accounts are in use.
    • What the authorization source is.
    • What the authorized population is.
Enforcement: 

Any person or application that uses a central authentication service will abide by the provisions of this procedure and agrees to comply with all of its terms and conditions, and with all applicable state and federal laws and regulations. Users have a responsibility to use these resources in an efficient, effective, ethical, and lawful manner. Violations of the procedure may result in loss of usage privileges, administrative sanctions (including termination or expulsion) as outlined in applicable Georgia Tech disciplinary procedures, as well as personal civil and/or criminal liability.

Policy History: 
Revision NumberAuthorDescription
1.0Richard BieverInitial Draft

    

Map of Georgia Tech

Compliance and Policy Management
760 Spring Street N.W. Suite 324
Phone: 404-385-0731