Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

At Yale a single Netid can be used with all the major authentication systems (Kerberos, AD) and it is a key that can be used to fetch data about individuals from the Human Resources database, Banner student system, and all LDAP directories. However, it should not be assumed that all universities will have a common central identification database, and even at Yale there are members of the community (such as alumni) that may not have Netids.

In a less centrally planned campus, there may be several different administration systems each authoritative for a different community or aspect of campus life. They may have different naming systems. Thus DOE123 in the administrative system may represent a student employee who is 543678 in the Student system. Not all students are part time employees, and not all employees are students, so there is no particular reason to expect a common central naming system.

A single authentication namespace becomes impossible once you add the possiblity of authenticating remote users through Shibboleth. When two campuses are close together, there may be some exchange of students and faculty. A person may have both home credentials at one institution and guest credentials at the other.

It is therefore proposed that the CAS 3 Authentication (eventually chained off the TGT) contain a collection of Subject Entries. Each Entry has:

A timestamp when this Subject was most recently (re)authenticated.

A value String.

A type URI String (of fairly arbitrary content) uniquely identifying a space of Subject Name values meaningful to the institution. A person may have many different identifications of different types ("Yale Netid" type has value "gilbet", "Mail" type has value "Howard.Gilbert@yale.edu", "AD UPN" type is also "Howard.Gilbert@yale.edu", "K5" type value is "gilbert@NET.YALE.EDU"). However, if an AuthHandler indicates a different value than an already existing value for the same type, then we are really screwed up and some form of recovery is required. Thus if an individual has already been identified as type "Yale Netid" value "gilbert" (say from a Certificate) and a later AuthHandler gets type "Yale Netid" value "susan" (say from the Userid/Password form) then there is a conflict and we have to either fail or resolve it.

A method of authentication URI String (another fairly arbitrary content). SAML already identifies some reasonable URIs for Certificate over SSL, Password over Encrypted Transport, IPSEC, etc. Others can be added.

As we build up the Authentication, the following rules apply:

You can have more than one Entry with the same type-value pair but different methods. For example, Netid-gilbert by Certificate and Netid-gilbert by Password can both be in the same Authentication and they provide extra confirmation.

You may not have two entries with the same type but different values.

If you are about to add a type-value-method to the collection and there is already an Entry with the same type-value-method, then the two entries are "merged" to leave the lastest timestamp of the two.

The most common search of the collection is by type. If all you are interested in is value, then you get back one value for the type. If you want all the entries for the type, then all entries have the same value but different methods and timestamps.

An AuthHandler typically returns an Authentication containing one or more Subject Entries, but Shibboleth may return an Authentication with only Principal Attributes. If an AuthHandler returns two or more Subject Entries then it may be because the Credentials contained multiple subject names (as a Certificate can have alternateSubjectNames) or it may be because the AuthHandler could generate a different type of Subject value by extracting substrings or by database lookup.

An AuthHandler is not obligated to generate a Subject Entry of its "native" format if the institution has absolutely no plausible use for it in any subsequent decisions. For example, the K5 principal identifier is "gilbert@NET.YALE.EDU" but Yale only has one authoritative Kerberos realm so this string is not particularly useful. Remove the realm part and you get the Netid "gilbert". In another university the realm part might be important.

  • No labels