Technical description of GTED

Please note: The GTED project is always improving.This document is written in the present tense for anything already generally available across campus.

Summary

The Georgia Tech Enterprise Directory (GTED) is an LDAP directory storing information about Georgia Tech's computer accounts and the people who use them. GTED is the data foundation of its parent Campus-IAM project. As such, GTED is intended as a tool for campus IT departments and other application deployers, not for direct use by end-users.

At a high level, GTED can be viewed as a number of independent directories -- one per GT IT department -- but maintained consistently with a single data-maintenance system with rapid updates from several key source systems (Banner, PeopleSoft, Mage, etc). Each of the logical, departmental directories has a both a global and local view of the people served by the department. This multiple-logical-directories approach is critical to simultaneously underpinning the identity-management and application-deployments of many of GT's IT departments.

This document first describes the scope and organization of GTED's information and then describes some of GTED's relationship with other systems used at Georgia Tech.

Data Organization and Schema

Note: This section describes the centrally created and maintained GTED objects. As mentioned above, GTED is extensible by Georgia Tech's IT departments both in the attributes stored about people or accounts, but also in storing information about other entities. Of course, this document cannot predict exactly how this extensibiliy will be used.

The information stored within GTED is dividied into three categories:

Global attributes which are consistent for people across the institute
Local attributes which can be different for people in each of their roles across campus
Computer accounts issued by different departments

In order to effectively store the institute-wide information as well as afford the necessary departmentally flexibility, GTED has at least three objects for an individual with a single computer account: a Global Person, a Departmental Person and a Departmental Account. Information about multiple roles (employment or academic) across campus are stored in multiple Departmental Person objects: one in each of the affiliated departments. Therefore, if George Burdel were a Business Office staff member who is also taking a graduate Math course, he will have the following objects within GTED:

GTED Branch	Summary	Specifics
global person	Information about George that is consistent across GT Not modifyable except by GTED service	Name course enrollment GT affilliations (all of student, staff, employee, member) GTID, PIDM, emplid
GT Account people	Any information common across George's GT accounts, Writable by OIT service applications, if necessary (Not expected to be different than global person)	(inherited from Global Person) Name course enrollment GT affilliations (all of student, staff, employee, member) GTID, PIDM, emplid global person=DN(George's global person)
GT Account accounts	If George came to GT after 10/2005: one gburdell3 account If George started before 10/2005: gp15 & gth231	(inherited from Global Person) Name course enrollment GT affilliations (all of student, staff, employee, member) GTID, PIDM, emplid global person=DN(George's global person) departmentl person=DN(George's GT Account Person) uid=gburdell3, gp15 and/or gth231 uidNumber=2313, 31992, and/or 1121
business dept people	Global and business-office information about George (writable, overridable, extensible by the business office)	(inherited from Global Person) Name course enrollment GT affilliations (all of student, staff, employee, member) GTID, PIDM, emplid global person=DN(George's global person) departmental affiliations (staff, employee, member) mail=george.burdell@business.gatech.edu job title, work address, etc office location: lyman hall
business dept accounts	Assume that the business office has issued George a 'burdell' account (defined by business office account-management system)	(inherited from Global Person) Name course enrollment GT affilliations (all of student, staff, employee, member) GTID, PIDM, emplid (inherited from Deparmental Person) global person=DN(George's global person) departmental affiliations (staff, employee, member) mail=george.burdell@business.gatech.edu job title, work address, etc office location: lyman hall departmentalPerson=DN(George's busiess dept person) uid=burdell
math dept people (math,cos)	Global and math-department information about George (writable, overridable, extensible by the math department)	(inherited from Global Person) Name course enrollment GT affilliations (all of student, staff, employee, member) GTID, PIDM, emplid global person=DN(George's global person) departmental affiliations (student) mail=george@math.gatech.edu
math dept accounts	Assume that the math department has issued a 'george' account (defined by the math department account-management system)	(inherited from Global Person) Name course enrollment GT affilliations (all of student, staff, employee, member) GTID, PIDM, emplid (inherited from math departmental person) global person=DN(George's global person) departmental affiliations (student) departmentalPerson=DN(George's math dept person) uid=george

While this appears extremely complicated (and it probably is), it's critical to know that an individual application will typically only use the department's account branch (some limited applications will only use the department's people branch). When taken in isolation, a GTED account branch and it's objects looks just like any other eduPerson-compliant directory.

Schema
GTED contains a broad set of attributes about accounts and the people who use them. However, the information stored is focused on demographic and contact information as well as information used for authorizing accounts and access to services:

Name
Contact information: Published email, home & work addresses/phones
Employment: Job titles, employment departments, job classes, etc
Academics: Course enrollment, Curricula(s), Instructor assignments, etc
Campus Housing: Dorm & Greek housing
Computer accounts: usernames, unix uid numbers, authorizations, etc
GT Relationships: Insitute and departmental affiliations

The current schema definition can be found at: GTED Schema

GTED's relationships with other GT Systems:

Related
System
Relationship to GTED
Active Directory
(AD, GTAD, etc)
There is no service relationship between GTAD and GTED today.

Inthe future, GTED will be populated with groups maintained in GTAD, andGTAD will be populated with GTED data via Campus-IAM connectors. ThisGTED-to-GTAD population might introduce maintenance of additionalinformation, accounts, or groups within GTAD.

Other GTAD Domain Controllers or other AD Forests will also likely be able to build similar connections with GTED.
Banner
Banner is a data source for GTED for Student, Course, Instructor, Term and GTID information
Campus-IAM
TheCampus-IAM project is the parent project of GTED and includes theability to publish or provision GTED information into external systems.
Continuum
Door Controls
As the system maintaining BuzzCard door-control access, Continuum will be a data source and provisioning destination for GTED.
GT Data warehouse
GTEDis an alternative data source for IT systems currently reading GT'sdata warehouse. For information about computer accounts and owners,GTED is easier in three different ways: Standard-schema LDAP is ofteneasier than SQL for applications to use, GTED is updated in real time,and GTED has more complete information about computer accounts andservices.
LDAP Auth
With GTED'sbreadth of attributes, realtime updates and standards adherence, GTEDwill likely replace LDAP Auth sometime in 2007.
Mage Mage is a data source for GTED for GT Account, Email and Guest information.
PeopleSoft HRMS
PeopleSoft is a Employment-information data source for GTED.
WebAuth
No direct relationship exists today between WebAuth and GTED.

However,Web-Auth applications are likely to frequently use GTED foruser/authorization information about the accounts that wereauthenticated by WebAuth.
Whitepages/LU
Whilethey are derived from the same source systems, no direct relationshipexists between whitepages/LU and GTED: Whitepages/LU continue to bemaintained directly by Mage, and also remain the best online phone bookservices. However, applications' use of whitepages for account andauthorization information is ill advised, and GTED offers a betteralternative.

In the future, GTED and Whitepages will likelyfirst run on the same directory servers, and GTED may evolve later tomaintain the Whitepages information.

Related System	Relationship to GTED
Active Directory (AD, GTAD, etc)	There is no service relationship between GTAD and GTED today. Inthe future, GTED will be populated with groups maintained in GTAD, andGTAD will be populated with GTED data via Campus-IAM connectors. ThisGTED-to-GTAD population might introduce maintenance of additionalinformation, accounts, or groups within GTAD. Other GTAD Domain Controllers or other AD Forests will also likely be able to build similar connections with GTED.
Banner	Banner is a data source for GTED for Student, Course, Instructor, Term and GTID information
Campus-IAM	TheCampus-IAM project is the parent project of GTED and includes theability to publish or provision GTED information into external systems.
Continuum Door Controls	As the system maintaining BuzzCard door-control access, Continuum will be a data source and provisioning destination for GTED.
GT Data warehouse	GTEDis an alternative data source for IT systems currently reading GT'sdata warehouse. For information about computer accounts and owners,GTED is easier in three different ways: Standard-schema LDAP is ofteneasier than SQL for applications to use, GTED is updated in real time,and GTED has more complete information about computer accounts andservices.
LDAP Auth	With GTED'sbreadth of attributes, realtime updates and standards adherence, GTEDwill likely replace LDAP Auth sometime in 2007.
Mage	Mage is a data source for GTED for GT Account, Email and Guest information.
PeopleSoft HRMS	PeopleSoft is a Employment-information data source for GTED.
WebAuth	No direct relationship exists today between WebAuth and GTED. However,Web-Auth applications are likely to frequently use GTED foruser/authorization information about the accounts that wereauthenticated by WebAuth.
Whitepages/LU	Whilethey are derived from the same source systems, no direct relationshipexists between whitepages/LU and GTED: Whitepages/LU continue to bemaintained directly by Mage, and also remain the best online phone bookservices. However, applications' use of whitepages for account andauthorization information is ill advised, and GTED offers a betteralternative. In the future, GTED and Whitepages will likelyfirst run on the same directory servers, and GTED may evolve later tomaintain the Whitepages information.