Enterprise Directory Services

Binding with a service account exposes the broadest view of the Enterprise Directory; this view is historically called ED-ID. While ED-ID provides the same basic functionality as ED-Auth (the view when bound with a person account), namely authentication and authorization, ED-ID exists mainly to give privileged access to person data that is otherwise inaccesible. These privileged service accounts, called ED Services, are primarily used to look up person data and authorize people on this data. See the person schema for a complete list of available data elements.

ED Services are given access to person data with permissions that correspond to person attributes. These permissions allow each ED Service to have a unique set of viewable user data. For example, it is possible to have one ED Service that is only capable of seeing email information, while another ED Service could see only information about peoples’ names. Additionally, an ED Service with enough permission will be able to see confidential and suppressed information.

ED Services can view:

ED-Auth vs. ED-ID

Middleware provides two authenticated views of the Enterprise Directory for authentication and authorization purposes, ED-ID and ED-Auth. The choice of view depends primarily on technology platform and business requirements.

Use ED-Auth if:

Use ED-ID if:

Some applications may even be able to support the usage of both directories. If this is the case, it is strongly recommended that you use ED-Auth for authentication and use ED-ID for the lookup of data pertaining to a person. This guarantees fast response times on authentication requests and allows access to all the information about a person that has been collected for placement in the directory.

Primary Affiliations vs. Standard Affiliations

Primary Affiliations

The eduPersonPrimaryAffiliation attribute is an attribute used to communicate, to other institutions, the most basic affiliation a person has with Virginia Tech. This attribute is used in conjunction with systems like Shibboleth* to allow other universities to make authorization decisions about this person. This attribute should NEVER be used by internal Virginia Tech systems for purposes of authorization, it is strictly meant as an external, to VT, facing attribute.

Standard Affiliations

The eduPersonAffiliation attribute gives all the affiliations a person associated with Virginia Tech has with the university. This attribute is meant to be used by internal applications, and will often be used in authorization logic. It is vitally important to realize that this attribute can, and almost always will, have more than one value, which is a change from the current affiliation tracking systems.

A Bit About SASL

Unlike the other LDAP directories (ED-Auth and ED-Lite), ED-ID credentials are not passwords but instead are digital certificates. SASL EXTERNAL, the SASL mechanism used with ED-ID, allows ED-ID to derive a service’s DN from the certificate as well as authenticate the service given the certificate. Thus, you will see that DNs are not required on bind by the service, nor is any special credential presented. This makes it appear as if the service is doing an anonymous bind when in fact it is not. The use of SASL EXTERNAL in conjunction with TLS client certificate authentication gives us an extremely strong form of authentication to ED-ID. See the ED-ID usage examples for platform-specific examples.