User Tools

Site Tools



ED-ID is a directory designed to allow applications easy programmatic access to data needed for authentication, authorization, application personalization and customization, and programmatic business decision evaluation.

The components of ED-ID

ED-ID Services The ED-ID specific account that allows access to ED-ID.
ED-ID Groups The ability to represent an arbitrary collection of people for use by any ED-ID Service. (Currently Under Development)

General Documentation

ED-ID Schema The directory schema used by ED-ID. This schema includes all a person information that will be included in the directory as well as all as the ability to represents groups.
Proposed ED-ID Schema Any updates to the schema that are under consideration will be found here. This document may be identical to the previous link, if there are no proposed changes pending.
ED-ID Usage Instructions This document describes the procedure to connect to the ED-ID system. As ED-ID may contain sensitive information on a person, applications are required to use TLS with client certificates in order to connect. This document will explain how to do this. Developers who wish to use the ED-ID directory are highly encouraged to read this.


ED LDAP Library A Java library used to make LDAP based queries against ED-ID. This library requires knowledge of the LDAP query language.
OpenLDAP C Library A C library from the OpenLDAP project for accessing LDAP directories.
NET::LDAP Perl module A Perl library accessing an LDAP directory.
python-ldap A Python library for accessing LDAP directories.


Q: What is ED-ID?

A: ED-ID is an LDAP directory designed to allow applications easy programmatic access to data needed for authentication, authorization, application personalization and customization, and programmatic business decision evaluation.

Q: What data is contained in ED-ID?

A: See the ED-ID schema. ED-ID contains all the attributes in ED-Lite and ED-Auth, plus additional authorization and personal data.

Q: What types of things should ED-ID be used for?

A: ED-ID exists primarily as an authorization directory used by applications to look up such things as a person's virginiaTechID, bannerPIDM, department, major, etc. ED-ID can also be used for PID/pass authentication in the same way as ED-Auth. Basically, if you need to get to user data, ED-ID is the one-stop shop for you. ED-ID services have the ability to look up information about a person, even if that person has been marked as confidential.

Q: How do I see data in ED-ID?

A: Connecting to ED-ID requires the use of TLS client certificate authentication, meaning you must have a signed certificate from the Virgina Tech Middleware CA in order to connect. Users that have performed a SASL EXTERNAL bind can only see those attributes they have been approved to see (for all users), and only if the corresponding service is ACTIVE.

Q: What is a client certificate?

A: A client certificate is an X.509 certificate that is used for authentication during TLS negotiation. A client certificate signed by the VT Middleware CA is required to connect to ED-ID.

Q: What is SASL?

A: SASL stand for Simple Authentication and Security Layer, a framework for providing protocols (SMTP, IMAP, LDAP) a means to authenticate.


A: SASL EXTERNAL, the SASL mechanism ED-ID uses, authenticates based on lower level network services, which in this case is TLS client certificate authentication. This means a client certificate is used to authenticate to ED-ID and is used to determine the username, or ED-ID service name.

Q: What is a SASL bind?

A: A SASL bind simply uses SASL to authenticate to an LDAP server. For ED-ID, a SASL EXTERNAL bind is performed.

Q: What is an ED-ID service?

A: An ED-ID service is a privileged user of ED-ID that has been approved to see certain user attributes. Typically, an application binds to ED-ID as its service to obtain authorization information about a particular user.

Q: What is the VT Middleware CA?

A: The VT Middleware CA is a subordinate CA of the VT Root CA that signs ED-ID service certificates. To connect to ED-ID you need a client certificate signed by this Certification Authority.

Q: What attributes can a service see?

A: A service can see only those attributes they have been approved to view, which correspond to the “viewablePersonAttribute” in a service's ED-ID entry. A service can view its viewablePersonAttribute (s) by searching on the ED-ID branch “ou=services,dc=vt,dc=edu”. Attributes a service can see are chosen during the ED-ID registration process. Narrowing down the viewable attributes allows us to give snapshots of entries, and assures that we do not expose any more data than is needed by any given application.

Q: What is the difference between authentication and authorization?

A: Authentication is confirming the identity of a user, while authorization is determining if a user has the proper rights or permissions to access a resource.

Q: How fast is ED-ID?

A: A typical ED-ID query can be broken down as follows:

  • connect, TLS client certificate auth, SASL BIND: 0.072 seconds
  • search on exact uupid, return entry: 0.002 seconds

The most time consuming part of interfacing with ED-ID is the TLS client certificate authentication, but after this connection overhead, search times are blazingly fast. Indexing of attributes has also been used extensively in ED-ID to ensure fast searching.

Q: Why should I use persistent connections to ED-ID?

A: Due to the connection overhead of using TLS client certificate authentication, persistent connections are recommended when interfacing with ED-ID. Applications that use persistent connections do not have to renegotiate TLS, so access to data in ED-ID is that much faster.

Q: If I lose or expose my service's key (client key), could someone get access to ED-ID?

A: Your client key is meant to be kept ABSOLUTELY PRIVATE. Safeguards should be put in place such that no one other than you can have access to your client key. If your client key were to get in the hands of another person, they would be able to connect to ED-ID as your service. If we know of the exposure, we can turn off the ED-ID service account that corresponds to the certificate. This will effectively shut off access for this certificate. If your client key is lost or compromised, it is your responsibility to notify us as soon as possible to prevent possible exposure of data.

Q: Where do I get my certificate for ED-ID?

A: Signed certificates are available for download from the VT Middleware CA.

Q: How long is my certificate valid?

A: Your certificate is valid for one year. It is your responsibility to renew your certificate after this time. Failure to renew your certificate will result in the inability to connect to ED-ID.

Q: Can I view confidential data with ED-ID?

A: Yes. If your service has been approved to see confidential data, ED-ID will allow you to view those attributes.

Q: Is ED-ID's data up-to-date?

A: Replication from the Registry takes place in near real time. The data in ED-ID is current.

Q: Can my service update data in ED-ID?

A: Currently, no. Middleware may provide the ability to update certain data in ED-ID in the future, but this access will most likely be extremely limited.

Q: Data that I want is not contained in ED-ID. What should I do?

A: If the data makes sense in an ED-ID world and is useful, there is the chance the ED-ID schema can be extended. Contact Middleware and IRM to begin discussion. Future enhancements may include better degree/major information and current class information for students. ED-ID has been designed to be extensible for these sorts of enhancements.

Q: Can I request a service that can only see people in a certain department?

A: Currently, no. Middleware is developing a feature in ED-ID that will allow you to specify which affiliation, campus, major, and department you wish to view, and the overall relationship between these attributes (intersection or union). When that is in production, this sort of thing will be possible.

Q: What about users with tenuous affiliation with VT?

A: These issues are currently being worked out by our busy policy makers. New affiliations are on the horizon to accommodate these sorts of things.

Q: I only need to use PID/pass authentication. Should I use ED-ID?

A: No, ED-Auth is better suited for PID/pass authentication. If you only need this, ED-Auth is recommended.

Q: What programming languages can you use to connect to ED-ID?

A: Any language that has the capability to do LDAPv3 things, namely TLS client certificate authentication and SASL binding, can connect to ED-ID. Middleware provides examples for Java, C/C++ (including WinLDAP), Python, PHP, and Perl.

Q: Can I do PID/pass authentication with ED-ID?

A: Absolutely, but if this is all you need ED-ID for, we highly recommend using ED-Auth.

Q: What should my ED-ID service name be?

A: Your ED-ID service name should be something descriptive, preferably in the form “department-application”. For instance, suppose the Library would like to use ED-ID for their proxy needs. A suitable ED-ID service name would be: “library-proxy”.

middleware/ed/edid.txt · Last modified: 2015/06/01 12:02 (external edit)