The Duke NetID is a userid and password assigned to all employees at Duke shortly after they are hired, as well as many other people affiliated with the University and Health System.
The NetID authentication system allows the owners of applications to authenticate users of the system, without having to create another id and password. NetID authentication is implemented in MIT's Kerberos, but has a number of "hooks" for systems which do not handle native Kerberos (methods for authenticating to Kerberos are described below).
Note that the NetID authentication system only provides authentication. If your application needs to limit access to a subset of the Duke Community (e.g., staff, students, etc.), then you will need to make use of an additional access control mechanism.
The flexibility of the NetID authentication system allows for a number of technical implementations. To help sort out the pros and cons of each mechanism, the programmer or project manager should contact the IT Security Office at security@duke.edu.
After discussing the different options, you will need to make a technical request for access to the system as described below. Several of these systems make standard, public attributes about users available to services. These attributes include: NetID and affiliation with Duke. Questions about additional attributes should be referred to the Electronic Access Services (EAS) program, oit-eas@duke.edu
Kerberos applications authenticate by validating a user's Kerberos ticket. There are two ways that an application can make use of Kerberos. The first is to natively recognize and validate a ticket that a user already has. This is currently used for the SAP GUI, but is difficult for web applications to use. An alternative is to collect a NetID and its password from the user, then obtain and validate a Kerberos ticket for that user. The second method is discouraged because it gives the application access to the password and reduces the security of the Kerberos model.
Webauth is an extension of Kerberos over HTTP. Webauth will allow any Apache webserver running on a Unix operating system (including Mac OS X) to authenticate against the NetID and to, optionally, receive information about the person from the LDAP. For more information about Webauth, please see the URL: https://webauth.duke.edu/. To use Webauth, you will need to register the application and receive a Kerberos keytab (this will require a PGP/GPG key), by emailing webauth-request@oit.duke.edu
Note: There are no longer any Webauth developers and the status of Webauth is under consideration; however, the Webauth service will continue to be provided for the indefinite future
Shibboleth is an Internet2 standard for handling authentication and the secure passing of attribute information in a privacy protecting manner. Shibboleth is available on a number of different platforms, including Apache on Windows, Unix and Mac OS X, and IIS on Windows. Information about installing and using Shibboleth at Duke is available here.
Please also be certain to sign up for the Shibboleth mailing lists: shib-announce and shib-discussion.
An LDAP can be used to authenticate a user in two different ways. First, the LDAP can be used as a password store, similar to the /etc/password file in Unix or the SAM file in Windows. Second, the ability to bind to the LDAP as a user can be taken as proof of authentication. Duke's LDAP does not support the first method of authentication.
To authenticate by binding to the LDAP, a service needs to collect the NetID and password of the user (for this reason, the service provider must contact security@duke.edu to discuss the security of the application). Binding to the LDAP as a user is a two step process. First, the service binds to the LDAP anonymously and queries the LDAP for the NetID. This will return the distinguished name (DN). The service then disconnects and re-binds using the DN as the LDAP user name and the user's password. If the bind succeeds, then the user successfully authenticated.