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.
|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.|
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.
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.
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.
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.
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.
A: A SASL bind simply uses SASL to authenticate to an LDAP server. For ED-ID, a SASL EXTERNAL bind is performed.
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.
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.
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.
A: A typical ED-ID query can be broken down as follows:
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.
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.
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.
A: Signed certificates are available for download from the VT Middleware CA.
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.
A: Yes. If your service has been approved to see confidential data, ED-ID will allow you to view those attributes.
A: Replication from the Registry takes place in near real time. The data in ED-ID is current.
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.
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.
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.
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.
A: No, ED-Auth is better suited for PID/pass authentication. If you only need this, ED-Auth is recommended.
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.
A: Absolutely, but if this is all you need ED-ID for, we highly recommend using ED-Auth.
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”.