Enterprise Directory

8/6/2019 Enterprise Directory

http://slidepdf.com/reader/full/enterprise-directory 1/15

Advanced Technology Project Report

Enterprise Directory Project

Universally, higher education is becoming increasingly aware of the need for a more costeffective and efficient manner for delivering services to faculty, staff, students andaffiliates. This need is forcing universities to implement enterprise-computing models onmany higher education campuses. Information technology is a driving force forimprovement of this service delivery. Universities are increasing the use of Intranet, Weband other technologies to distribute services to their communities.

Fundamental infrastructure requirements for delivering services through these informationtechnology structures include directories, registries, and authentication processes. Theseinformation technology structures form a class referred to as middleware. Middleware is“the intersection of the stuff that network engineers don’t want to do with the stuff that

applications developers don’t want to do.”(Klingenstein, 1999) Middleware is an essentialelement of any enterprise-computing model. The layer sets atop the network layer,between it and the applications, and provides the centralized service for integratingapplications and providing interoperability through the computer network.

The University of California at Davis embarked on programs to increase the availability ofservices provided through the computer network. MyUCDavis is a project focused ondeveloping a student and faculty portal. The Davis campus along with other University ofCalifornia campuses is examining the requirements for the New Business Architecture(“UC 2010: A New Business Architecture for the University of California”). The NewBusiness Architecture spells out a plan of action for all UC campuses to develop a“business portal” to provide users with a flexible method of finding useful information,

allowing for greater productivity and fewer transaction errors. Each of these programsrequires the development of an enterprise-computing model to support the delivery ofinformation services through the campus network.

Implementation of the enterprise-computing model requires Enterprise DirectoryServices. Enterprise Directory Services offers the advantages of:

• Single sign-on to all systems at once,

• A common authentication process,

• Reduced duplication of information in systems,

• A more complete and correct record about people, organizations, and othercampus entities.

• Overall control of access to systems from a single point,

• A common look and feel to all applications,

• Reduced error during the entry of information, and

PAGE 1 OF 16



• More up-to-date information about people.

Enterprise Directory Services include the Enterprise Directory and the Registry. Toachieve the advantages of Enterprise Directory Services, the legacy campus systemsmust be enabled to use Enterprise Directory Services through a standard interface,LDAP, and to test the uniqueness of an entry through the registry.

Charge

Recognizing the need for the middleware to support the foundation for the campusenterprise-computing model, Vice Provost for Information and Educational Technology,John Bruno initiated an advanced technology project to study enterprise directories andthe requirements for establishing enterprise directory services for the campus. A smalladvanced technology project team (ATP team) of information technology professionalswas assembled to carry out this investigation and assessment of the applicability of anenterprise directory services for the UC Davis campus. Members representing theTechnology Infrastructure Forum supported the team. Team members and supporting

TIF members are:

Affiliation Team MembersInformation andEducationalTechnology

TIF/Data AdministrationTIF/UC Davis LibraryTIF/University ExtensionTIF/Information andEducational Technology

Chris Lambertus, Deborah Lorraine, Morna Mellor,Randy Moory, and Dan Watson

Hebert Diaz-FloresChengxian Gao, Gail YokoteThomas WileyTim Leamy

The charge for the ATP team encompassed a broad review of enterprise directories. Theexamination had several individual objectives. These objectives were:

� Working with campus units through the Technology Infrastructure Forum, identify therequirements for a campuswide directory. This identification should address the levelof content detail required for the directory and estimate the number of directoryentries.

� Evaluate the processes used by the existing campus, account management systemthat builds the database of active computer account holders and determine the effort

necessary to transfer these processes to enterprise directory services.

� Examine the opportunities for integrating the Kerberos authentication processes withthe enterprise directory.

� Investigate and evaluate the integration of authorization processes into the enterprisedirectory sufficient to support campus business and academic initiatives.

PAGE 2 OF 16



� Examine the opportunities to use commercial and non-commercial, directory serversoftware to establish the enterprise directory for the campus.

� Establish and test the directory architecture to determine its capability to supportcampus IT functions.

The ATP team completed its investigation of enterprise directories. It publishes itsfindings in this report. The following sections address each objective separately.

Reasons to Build an Enterprise Direct ory

Development of an integrated enterprise directory has enormous potential for costsavings, minimizing constituent frustration, and maximizing efficiency. A properlydesigned and deployed enterprise directory, supported by data which is readily availableand always correct, will eliminate duplication of effort, facilitate application development,enhance productivity for users, and enable authentication and security.

Currently at UC Davis, there are dozens of overlapping sources of directory informationwith varying levels of data currency, completeness, quality, integrity, and security. Someof the principle sources of information about people come from the Account ManagementSystem, the payroll personnel system, and the student information system. Additionalsystems such as the library, alumni information system, University Extension, HRsystems, campus billing systems, data warehouse, telephone directory, and many othershave their own directory information. Now that the University is aggressively investigatingan enterprise portal solution to provide services through the Web, the creation of anenterprise directory service will facilitate the ability to integrate business, faculty, andstudent systems.

An enterprise directory service will also facilitate the elimination of the current "online PH

server directory," the "telephone directory master" and the many existent e-maildirectories, and the processes that build them. The enterprise directory will be the singlesource of person information. Initially directory enabled applications will interact with theenterprise directory for information about people. Eventually this will extend to allapplications. Applications that currently extract or create their own separate persondatabases will no longer be required. The application will easily query the enterprisedirectory and present it to a user as is done now with the PH server and telephonedirectory. The campus may choose to support separate directories for purpose ofreducing load on the enterprise directory service or for providing more security to theenterprise directory. Examples might be creating a directory of email addresses for eachemail server so that email address queries do not need to go against the enterprisedirectory and the creation of a border directory for information requests from outside the

campus.

Current Directory Services Model

The current directory model for the University is the use of individual, independentdirectories to support each application. Student Information System, PPS, DaFIS, phonedirectory, data warehouse, and other applications have directories and processes tocontrol access and in some cases provide authentication. In addition, the campussupports a unified namespace that provides a single, unique Login ID for each individual

PAGE 3 OF 16



who uses computing resources at UC Davis. The unified namespace purpose is toprovide the development of campuswide security systems for network-based applications(so that an individual is uniquely identifiable across distributed systems). The accountmanagement system contains a partial demographic profile for each student, facultymember, staff employee, and campus affiliate that uses campus-computing resources.This data combined with Communication Resources phonebook data populates the Ebira

database. The database currently functions as the campus directory to support otherdirectories such as the LDAP server, web phonebook, whois server, ph server, and othercampus services. The image below displays the current structures and functions of theaccount management system and database.

Future Role for the Unified Name Space and Account Management System

In an enterprise-computing model, the enterprise directory service will replace many of

the functions currently performed by the unified name space described above. Theprocesses that support this name space extracts data directly from multiple sourcedatabases and applies business rules and logic to resolve conflicting data from multipleauthoritative sources. The application of business rules and logic to unclean data is animperfect process and propagates errors into the database. In an enterprise-computingmodel, the enterprise directory will be the source of clean useable data untied frombusiness rules and logic to establish an authoritative source for information. In theinterim, while the campus migrates it legacy systems to directory enabled applications;there will remain the need to establish an authoritative source for data in the directory.

PAGE 4 OF 16



This extraction, transformation, and loading may be accomplished more effectively withnew processes built on commercial off-the-shelf software (COTS). The UC Davis campuscurrently uses "Genio" extraction, transformation and loading (ETL) software fromHummingbird Ltd. for the campus data warehouse project. The Data Warehouse projectteam uses this software. The ETL proved useful and powerful and the campus shouldconsider it as a replacement for the custom ETL processes used by the current system.

Even with the enterprise directory in place, there will continue to be the need for anaccount management system. This system will assign computer account information forusers of the campus computing resources. The account management system willcontinue to operate, however the enterprise directory will provide the person data used bythe system.

Enterprise Direct ory Service Models

Industry trends in the marketplace and the current state of technology initiatives provide aframework for examining the enterprise-computing model. Organizations are rapidly

adopting the enterprise-computing model to support technologies such as portals, Webservices, and other online services. Industry trends support our findings that we addressenterprise directory services in terms of a component in a general-purpose model ofservices distributed throughout the network. Services include File, Print, Directory,Security, Web, and Object Services. All of these services are accessed via standardprotocols over the network. While this vision of the enterprise computing model portraysa centralized computing model infrastructure, the reality is the UC Davis enterprisecomputing model is heterogeneous. Unification, interoperability, and integration of theservices provided by these systems will only occur through the application of standards.Achievement of interoperability will only occur with the building of a general-purposeinfrastructure.

In this heterogeneous environment, the campus should strive for the directory model thatbest supports services and interoperability. The driving force for enterprise directoryservices is the need to provide a centralized repository for commonly and widely usedinformation. The enterprise directory service is built as a general-purpose infrastructurefor many applications. It thus relies on open access protocols and the most useful ofthese are LDAP or X.500. The ATP team recommends the adoption of enterprisedirectory services based upon LDAP protocols. LDAP is the most widely supported opensystems architecture today and is far less complicated to implement than X.500directories. Examination of implementations of enterprise directory services at otherhigher education institutions finds LDAP to be the most widely implemented solution.

The enterprise directory service is a crucial component for the enterprise-computing

model, as it becomes the rendezvous point for service delivery on the network. While thecampus will likely continue to require special purpose directories for special purposeapplications, the number of these should gradually reduce in an enterprise-computingmodel as application vendors and software developers enable their application softwareto take advantage of LDAP. In general, the campus should adopt a three-tier directoryservice approach to serve the campus units internally and to provide services to thoseexternal to the campus. The diagram below illustrates the proposed three-tier approachto implementing enterprise directory services. In this approach, information provided tooutside organizations use border directories (Tier 1). This information is often a limited

PAGE 5 OF 16



subset of all the information in the enterprise directory. The enterprise directory (Tier 2)provides information to all directory-enabled applications and supports most services onthe campus. Email, Active Directory, application directories (Tier 3) that require their owninternal directory represent special situations that obtain replicated directory informationfrom the enterprise directory.

Enterprise Directory Services

Active Directory Email Directories Applciation Directories

Border Directory

Directory EnableApplications

External / Public Directories

Internal / Private Directories

The Three Tier Directory Architecture Model

Border Directory Border Directory Border DirectoryTIER 1

TIER 2

TIER 3

Person Regist ry

One priority for enterprise directory services is providing correct and reliable data. Aperson registry is a directory or database whose primary functions are identitymanagement, reconciliation ("Is this person the same as that person?"), and cross-

indexing ("Given this person's ID on system X, find their ID on system Y.") The personregistry can also serve as a reference identifier for other systems. Other types ofregistries, such as organization registries or group registries, can and probably will exist inthe future.

The person registry plays a different role from the directory. The registry containsinformation about all persons that have or had a relationship with the campus and theirinformation entered into a campus system. In contrast, the directory only containsinformation about entities that have active relationship and in the case of people haveaccounts to access campus computer systems. The directory is similar to what theunified name space and account management system supply the campus with today.

The campus cannot feasibly deploy enterprise directory services without aregistry. The registry ensures uniqueness of the entries in the directory. Without aregistry, enterprise directory projects rely on business rules and programming logic to findduplicates and invalid information from source data records. These processes eventuallyfail and the information contained in the directory becomes useless.

Person registries come in two varieties: thick and thin. Thick person registries containmany details on each individual; thin person registries contain only the system-identifierpairs needed to enable you to find the details elsewhere. As reconciling identities

PAGE 6 OF 16



involves not only gathering up identifier strings, but also rationalizing the expression of theinteresting relationships (e.g. faculty/staff/students/alumni/affiliates), registries tend to startthin and end up thick.

The person registry has two stages in its process: Determination if a new person enteringthe registry is really a unique instance or already exists in the system. This is usually

done by comparing key elements such as name, date of birth, city of birth, SSN andmother's maiden name. If the new person is unique, assign them an identifier and enterthem into the registry. If the new entrant is an existing person, the registry can notifysource system and provide the existing person's registry identifier. Where there isuncertainty, the registry system operator must arbitrate to insure that new entrant isunique. This involves notifying the source system and initiating the arbitration process.

The registry will play an important role on the campus. It will insure that entries in thedirectory are unique. The process will involve campus applications validating a new entrywith the registry before writing it to the database or enterprise directory. For example, acampus department is entering a new employee into PPS. The application will need tovalidate this entry with the registry before writing it into a data system. The registry will

determine whether the record is new, existing, or ambiguous. If the record is new orexisting, the registry provides the unique identifier for that person. The record can thenbe written to a database or the enterprise directory along with its unique identifier. If therecord is ambiguous, the system cannot write the record until the ambiguity is resolved.

This process is substantially different from what occurs in the account managementsystem. The account management system only assigns an ID to active users ofcomputer and network resources on campus. The account management systemreceives its updates from the source systems after the data is written into the sourcesystem. Thus, the account management system is continually attempting to resolveambiguity by applying business rules and logic to establish the authoritative source.

A third mode of operation for the registry is to update information held within the registry,such as a name change. Since the person registry holds very little volatile information,this is an infrequent and straightforward activity.

The campus has many decisions to make regarding the registry implementation. Thecampus must decide whether it wishes to have a thick or thin registry. The campus mustconsider where the person registry should be operated. Many campuses use theircentral IT organization. Others use another campus unit such as the Registrar or HumanResources. Whatever the campus choice, this unit will handle the arbitration process.There is a real cost in labor to arbitration, however there are major institutional efficienciesto having this focused approach. The cost of arbitration may also become dependent onthe type of registry structure chosen by the campus.

Proposed Models for the Campus Enterprise Directory Services

The campus does not currently have directory (LDAP) enabled application services. Thecampus must therefore build a directory structure that uses a database for applyingbusiness rules to the source data before populating the LDAP directory from the sourcedata repositories. This is similar to the approach used by the campus data warehouse.The initial stage proposed for this directory architecture is illustrated below. It does not

PAGE 7 OF 16



represent an optimal directory solution, but provides the campus with the means tosupport the growing use of enterprise portals and other online services.

The illustration below shows the role of person registry and processes to extract,transform, and load the LDAP directory. In this model, the person registry would act asthe arbitrator of identity. A new record from a campus business system would be

evaluated against the records in the person registry. A new record would receive aunique identifier. A record that already existed in the person registry would obtain theunique identifier of the existing record. An ambiguous record is sent for manualprocessing with the arbitrator. Neither the Extraction, Transformation, and Loadingprocesses or the LDAP directory attempts to resolve ambiguous records. This resolutionof ambiguous records occurs in the person registry and the associated processes.

PPS SIS DaFIS

LIbrarySystem

UCDMC

AIS

LDAPDirectory

ServerLDAP

Directory

ServerLDAP

Directory

Services

MothraAMS

Web Server

Web Clients

LDAP

Enabled Clients

LDAPEnabled Clients

Web Clients

External

Internal

CampusBusinessSystems

PartnerDirectory

Proposed Enterprise Directory Services Architecture

OtherCampus

Directory

User

WebInterface

Campus ETL(Business Rules)

Campus

PersonRegistry

After the person registry processes that establish a unique identity for the record, thebusiness system sends the record to the ETL process to store in the directory. The

campus currently has many systems that can provide the same information about aperson (e.g. SIS and the Library system have address information about a student’s localaddress). The ETL process must apply business rules to choose the authoritative sourcebefore the record is written in the directory. This is process is similar to the processingthat occurs in the account management system today.

Processes that use of business rules and logic are not the best solution for buildingenterprise directory services. Application of business rules and programming logic todetermine the most authoritative source for data records introduces error. Errors result



from the incorrect application of a rule, ambiguity of the data, different data definitions ineach data source, and data errors themselves.

The completion of the enterprise directory services project will eventually involve noapplication of business rules and programming logic to determine the authoritative a datasource. In the second stage of development of the enterprise directory services, the

campus develops or obtains directory-enabled applications. The processes shown in theprevious illustration become substantially different. The person registry processes remainas shown but its role becomes more critical in resolving ambiguity. In the architecture,the application of business rules to determine the authoritative source of a recorddisappears. In a directory enabled application model, applications either have or do nothave authority to write specific attributes in the directory. In this model, the last entrywritten in the attribute represents the most recent and presumed accurate information forthat record.

PPS SIS DaFIS

LIbrary

SystemUCDMC

AIS

LDAPDirectoryServer

LDAPDirectoryServer

LDAPDirectoryServices

MothraAMS

Web Server

Web Clients

LDAPEnabled Clients

LDAPEnabled Clients

Web Clients

External

Internal

CampusBusinessSystems

Partner

Directory

Proposed Enterprise Directory Services ArchitectureFor Directory Enabled Applications

OtherCampusDirectory

UserWeb

Interface

CampusPersonRegistry

Authent icat ion and Authorization

Enterprise Directory Services do not authenticate. Authentication is a separate processthat uses information presented by a user to determine whether the user is who they saythey represent. Several methods of authentication include password and user id,challenge response, Kerberos, and public key infrastructure (PKI). All of theseauthentication methods have common processes. Each has a validation process thatfirst establishes the authentication and next provides a user credential that permits users

We illustrate this model in the following figure.



to obtain services. In password protected systems, they combine the validation andcredential processes and occur every time the user attempts to access the system anduse the service. With Kerberos, the user receives the credential when they log into thenetwork. The user presents the credential to each system that uses the Kerberoscredential for authentication. With PKI, the user receives a digital certificate that canauthenticate them for long periods. The user presents the digital certificate to systems for

authentication.

Enterprise Directory Services provide the means for single sign-on by storing in thedirectory the public credential obtained during authentication. Enterprise DirectoryServices will become the focal point and storage medium for all forms of authentication:passwords, PINS, secret keys, smart cards, and biometrics device keys. The directoryentries will also integrate traditional authorization: ACLs (Access Control Lists), policies,and coordinated administration. The success of these efforts will create a general-purpose infrastructure to support all application security needs and will be a major vehiclefor the success of single sign-on.

The use of authentication and authorization in the Directory will also enable new

mechanisms: protecting and extending the campus Web services to support enterpriseportals. Protecting the enterprise portal can be enabled using password and sessionencryption, secure messaging, and the coordinated use of firewalls and virus protection.Extending the campus intranet can be accomplished with coordinated remote accessauthentication, virtual private networks (VPN), integrated public/private key systems, andelectronic commerce systems. These functions are already quickly becoming and willcontinue to become Directory centric.

Authorization

Authorization can be a principal service of enterprise directory services. It obviouslybegins with authentication and the identity of the use. Typically, authorization involves

identification and authentication before permitting action in a network system or with acomputer resource. The simplest form of authorization is an access control list. Accesscontrol lists use a set of variables from the directory or other source to give users accessto specific applications or particular rights in a database or file system.

The Internet2 Middleware initiative addresses the complications and the challenges ofauthorization processes. These are:

• Storing the authorization attributes.

• Transporting attributes to applications.

•Ensuring a consistent meaning and validity to values associated with thoseattributes.

• Effective expression of the sophisticated and diverse characteristics ofpolicies in a processable list of attributes.1

1Internet2, Middleware Initiative http://middleware.internet2.edu/core/authorization.shtml

PAGE 10 OF 16

http://middleware.internet2.edu/core/authorization.shtml

http://middleware.internet2.edu/core/authorization.shtml



Access control lists partially conquer many of these challenges. Most LDAP productsprovide tools for creation and management of access control lists. However, as directorystores access control lists for each application, the number of directory reads increases.Each time an access to the directory occurs the ACLs are examined. This can be a largeperformance issue over time. If the campus chose an approach that stores authorizationinformation in the directory, messaging test performance as addressed in the next section

becomes important.

Directory Enabled Authentication and Authorization

The diagram below illustrates the general security functions supported within EnterpriseDirectory Services that enable authentication and authorization. This diagram shows therelationship between the enterprise directory, the security servers, and the enterpriseapplications. The security servers (Kerberos, Certificate Server, and Policy Server) storethe user’s public credentials in the directory and information about the revocation ofcertificates. Directory administration includes the creation of users, groups, and accesscontrol lists. Enterprise applications use this information to validate a user attempting toaccess a system and then providing access to specific services based upon group

identity or other access control information obtained from directory server. This securitymodel makes the enterprise portal work. In the enterprise portal model, the user whoauthenticates once to the system, presents their credentials to the portal application. Theportal application then consults the directory to determine if the credential is valid, checksthe users group affiliation and access limitations, and then dynamically creates a view forthe user that provides access to the services for which the user is authorized.

Authentication and Authorizationin the Enterprise Directory

Secure Messaging

Remote Access

SIS, DaFIS, Web,Other applications,

etc

Firewalls

Kerberos TicketHash Function

Result

Public Key

Policies

CertificateRevocation

Lists

Kerberos Server

Certificate Server

Policy Server

Directory AdminApplication

Security Services

Users

Groups

AccessControl

Lists

Security-RelatedDirectory-Enabled

Directory Services Applications

PAGE 11 OF 16



Comm ercial and Non-com merc ial Enterprise Directory Service Product s

The ATP team evaluated commercial and open-source directory service products. Thisevaluation focused on what other campuses were using and information about theperformance and features of the products available from published sources. Thedirectory service products include LDAP directory servers (iPlanet, Open LDAP, andInnosoft), a general-purpose directory (Novell), a X.500 directory (Critical Path, ComputerAssociates, and Siemens), Microsoft’s Active Directory, and a database directory product(Oracle). The performance of each of these directory products is presented in Table 1.The performance numbers come from benchmark testing done byNetworkFusionReviews in May of 20002. Each software package was installed on similarhardware. No optimization of the software occurred during installation. Performancenumbers in Table 1 reflect the differences in the way the software configures wheninstalled with all default configurations. The iPlanet Directory Server product was the

performance leader in the directory test documented in Table 1. The review also

identifies OpenLDAP as a good choice to perform pilot developments.

The performance testing simulated real functions for directories. The bulk load testmeasured how the directory software would perform loading a large number of entriesfrom an existing database. The modify test measured performance during updating oradding single entries. The messaging test measures how the directory performs underconditions similar to an email or e-commerce application that would have direct hits on anindexed field.

Proposed Schema for UC Davis Campus Enterprise Direct ory

The proposed schema for campus person directory, “white pages”, is documented in

Appendix A. The schema represents the work of the ATP team with other campus unitsand TIF member review. Development of the proposed schema involved the TIF and theATP team and conference with campus system owners. Appendix A provides anoverview of the thought processes used to develop the schema.

The Next Steps

This report presents the results of an investigation of the applicability of enterprisedirectory services for the campus. The purpose of this work is to determine if enterprisedirectory services are feasible for the UC Davis campus and whether the campus shouldengage in a project to implement enterprise directory services. For the campus to

implement an enterprise directory service, the campus must expand upon the work donein this advanced technology project. The ATP team recommends the formation of anenterprise directory project that takes the following actions.

• The ATP team recommends an LDAP solution for enterprise directoryservices. This is the most widely adopted model by other Universities.

2Snyder, Joel, “Sizing Up LDAP Servers”, NetWorldFusion Review

(http://www.nwfusion.com/reviews/2000/0515rev2.html?nf#skinny ) , May 15, 2000

PAGE 12 OF 16

http://www.nwfusion.com/reviews/2000/0515rev2.html?nf#skinny








Product Bulk Load

T ime

Messaging

Test with 1

Client

Messaging

Test with 10

cl ients

Addressing

(wildcard);

tes t w i th 1

client

Addressing

(wildcard);

test with 10

cl ients

Search rat e

tes t w i th 1

client

(record/sec) (Operation/sec) (Operation/sec) (Operation/sec) (Operation/sec) (Operation/sec)

Novell NDSeDirectory for NT

0.8 321.7 333 86.7 93 318

I planet

Directory Server

413.2 1,323 3,175 108.9 166 1,350

Innosoft

IDDS

416.7 426 115.1 11.7 1.8 461

Critical Path

Global DirectoryServer

47.6 373 670 5.1 3.8 370

ComputerAssociates

eTrust Directory

5.2 94.3 101 3.6 3 162

Siemens

DirX

3.1 4.3 30.1 4.9 12.3 5.1

Oracle

Internet Directory

139 64 228 17 41 64

Microsoft

Active Directory

33.3 915 1,536 2.6 11.6 999

Open LDAP 23.5 4.6 47.7 5.9 48.6 4.5

Table 1: Performance Statistics for Commercial and Non-commercial Directory Products (Source: Netwo2000)

PAGE 15 OF 16



Documents

Enterprise Directory