a Monday. Met 9:30 am to 10:30 am.
Present: Andy, Andrew, Susan.
- Agenda item: implementing ACAS using CAS3: tabled until Wednesday as Drew not present and Drew among us best has is brain around ACAS.
- Agenda item: Andrew reported on speculative design and implementation of non-interactive user login.
Explanation of whiteboard
Attached is screenshot of whiteboard.
LoginController and LoginFormController
The object called LoginController in the CAS3 HEAD is an implementation of LoginController that is about being a form controller. It works well for things that look like username password forms. Let's let it be good at what it's good at and not shoehorn onto it support for credentials other than those expressed by forms (i.e., as request parameters that can be easily bound to an expected Object).
So, before reading the rest of this page, mv LoginController LoginFormController in your conception of the CAS3 head. Now, this thing that we're going to talk about here, it is the NonInteractiveLoginController. I'll be calling it LoginController for short here.
The End Game
Before we embark, let's review where we're going. Where we're going is that as a result of interacting with the LoginController, we're going to issue a TicketGrantingTicket that maps back to some information. Specifically, the information we're going to have is one or more AuthenticationEntry instances along with a Principal.
AuthenticationEntries are about what and how authentication happened. They have a type, a value, and a method. In the case of authenticating using username and password where I typed it this request, for me this would be a type of "NetID", a value of "awp9", and a method of "username/password", and "happened this request". If I then come back through via Single Sign On, this would be "via SSO cookie" rather than "happened this request".
We might also issue X.509 certificates to authenticate NetIDs. Thus I might have an X.509 cert issued by Yale which authenticates the "NetID" "awp9". If I present this, I'd have an authentication entry of "NetID", "awp9", "X.509 certificate". We might be remembering this via SSO or we might have actually examined the certificate on this request.
One might also implement that dopey "send a PIN to your email address" approach of authenticating a person's email address. After having completed this, we'd also have an authentication entry of "microcline@gmail.com", "email", "PIN to email". We might be remembering this via SSO or we might have actually had the user type in her PIN this request.
In addition to how the user was authenticated, we also have a Principal. Whereas the AuthenticationEntries were individual assertions about the way in what and how authentication happened, a Principal is about who it is that we've authenticated. The Principal contains a primary identifier (round here at Yale it might be a NetID) as well as zero or more name,value pairs representing user attributes, things like alumni status, email aliases, etc.
We bundle the Principal and the AuthenticationEntries into an Authentication. The end game is that given a TicketGrantingTicket and a desired Service, we can retrieve stored Authentication information and use it to produce a ServiceTicket which will reveal a view on that Authentication to the service that eventually validates it.