Subject Entries

Owned by Howard Gilbert
Last updated: Apr 05, 2005Version comment
3 min read

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.

In CAS 3.0, a user is represented by a Principal that has a simple Id value. This works well for the typical userid/password validation. It should be preserved in future releases for the 80% of the cases that don't need anything more.

In CAS 3.1, the Princpal interface is extended by the ComplexPrincpal interface. It inherits the requirement to prsent a simple Id string (for example, to present a Netid response to a CAS 1 or CAS 2 legacy client), but it also supports a collection of secondary Subject entries for new clients that choose to support them. Each Subject 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 starting set of types is defined in the ComplexPrincipal interface based on SAML URIs, but any naming authority can extend this list if there is some new technology.
  • 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 ComplexPrincipal, the following rules apply:

You can have more than one Subject with the same type-value pair but different methods. For example, (Type:Netid, Value:gilbert, Method:password) can coexist with (Type:Netid, Value:gilbert, Method:certificate). The extra method provides an additional confirmation of identity.

Only one Subject in a Principal can have a specific set of type, value, method strings. If a second Subject is generated with the same three strings, it is redundant and the Principal keeps the latest timestamp of the two.

A Principal may not have two Subjects with the same type but different values, because that indicates two different people.

In CAS 3.0, the authentication process generates only a SimplePrincipal containing an Id. Since there is no provision for more than one Id, the processing stops as soon as one is generated.

In CAS 3.1, each Resolver can generate either a SimplePrincipal or a ComplexPrincipal. A SimplePrincipal is logically regarded as equivalent to a ComplexPrincipal with one Subject in which the type is Userid and the method of authentication is Password-over-SSL (the right values for the CAS logon HTML Form).

The AuthenticationManager supports multiple credentials. Each credential is first passed to the set of AuthenticationHandlers and is retained if one Authentication Handler validates it. Valid credentials are then passed to all Resolvers.

If any Resolver generates a ComplexPrincipal then it is merged with any previously generated ComplexPrincipals (or a SimplePrincipal regarded as Complex with default type/method). The process of the merger is implied by the rules given above. The value of the highert priority Subject type becomes the simple Principal Id string. By default, the Userid/Password is highest priority and after that there will be a way to prioritize types.

This logic preserves any coding done for CAS 3.0, produces a result that is fully compatible with prior code, and yet allows for more complex situtations to be supported by new clients.