An IT Architecture for Emory University
Adopted by CIRT
Directory Service Domain Architecture
February 20, 2002
ITA Version 2.4.6
© 2000 Emory University
Page 3-4
Security. In addition to decisions about contents and updates, decisions would also need to be
made about the security classification of everything in the directory, and access controls would
need to be implemented accordingly. For example, some data, such as userids and passwords
would need to be tightly secured with restricted access. Other data might be available only to
people or IT systems at Emory. To implement sharing of resources (such as databases) with
other schools, authenticated access to some entries by specific systems at other schools might
be allowed. Finally, some of the information (such as faculty names, their departments and a
link to their Vitas) might be open for lookup by anyone, including the public. The directory
service would thus need to allow and control access coming from many different types of
systems. To do this it would likely need to be partitioned to allow placing data in the zone of
trust appropriate for their classification.
3.2
The directory service architecture
Purpose. The Emory directory service architecture defines the infrastructure to create an
Emory-wide directory service that meets the requirements outlined above, and that can grow
and change quickly enough to continue to meet Emory’s needs while keeping down complexity
and support costs.
Standards. To accomplish this goal, the architecture specifies use of Internet standards for
read and write access to the directory service as well as for authenticating to it and securely
communicating with it. The architecture also specifies a standard format for feeds to load and
update data plus utilities to convert common export formats to that standard. This approach only
requires the directory product to support one standard format for feeds, yet accommodates
other common formats.
Replication. In addition to the Internet standard for reading and searching the directory, the
architecture envisions receiving data from the directory service via replication. Using this
approach, an up-to-date copy of the directory or a portion of it is maintained elsewhere (in
another directory) for use by another service. For example, Emory-wide userids and passwords,
could be replicated to a directory in a password synchronization service.
Replication can also used within the Emory-wide directory service itself to allow the directory
information to be duplicated across multiple platforms in multiple locations. The replicas are
accessed through multiple instances of load balancing equipment to provide:
·
Reliability: In case one copy of the directory goes down, requests will be directed only to
those that are up;
·
Availability: Replicas can be located on different parts of the network to provide service even
if part of the network is down;
·
Scalable Performance: An increase in volume of queries can be handled by adding
additional replicas.
·
Security: Directory entries can be located on different systems in different zones of trust
according to the security classifications of the entries.
The initial architecture envisions single master replication, which requires that all updates be
referred to a single master that then sends the changes to replicas. Multimaster replication (to
be supported later) would allow having multiple masters that could accept updates and send
changes to keep all the copies synchronized.
 |
 |
 |