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:
- Their own entry by searching on
ou=services,dc=vt,dc=eduwith the filter(objectclass=*). - All users in the
ou=people,dc=vt,dc=edutree. - Person attributes that have been explicitly entitled via viewablePersonAttribute.
- Entries in
ou=addresses,dc=vt,dc=eduif they have the viewablePersonAttribute value address. - Public groups
- Private groups for which the service has any of the following roles: viewer, manager, administrator.
- Entitlements for which the service has any of the following roles: viewer, manager
- Organizations
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:
- Your application can support LDAP over SSL, or startTLS (an LDAP version 3 function) AND
- Your application requires extremely fast authentication responses OR
- Your application only requires knowledge of a person’s basic affiliation (faculty, staff, student, etc.) for authorization decisions
Use ED-ID if:
- Your application can support SSL or TLS with client certificates AND
- Your application requires more information about a person than simply their affiliation OR
- Your application requires access to information about which groups a person is a member of OR
- Your application requires that the directory keep an explicit list of people who are authorized to use your service
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.