...
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 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 AuthenticationComplexPrincipal, the following rules apply:
You can have more than one Entry Subject 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 (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.
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, 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.