well-known modifications
- Andrew Petro
- ScottS
Well known modifications to baseline CAS 2.x:
Services whitelist
High level discussion
An important feature of CAS is its openness. Bring up a CAS instance at your institution and you can let application developers of varying trustworthiness and ability produce applications against which your users securely authenticate. Passwords are not exposed to these potentially suspect applications. There's a lot to be said for not having to centrally manage the set of applications authorized to use your central authentication server.
However, some institutions nonetheless want to restrict the set of applications able to authenticate using CAS. This is typically implemented as a whitelist of services. Service tickets will only be vended for whitelisted services.
Feature specification
CAS administrators can specify a whitelist of services. CAS will only vend tickets for these services. It is easy to implement compelling user factors / UI for the case where the service is not authorized for ticket vending.
Implementation notes
This can be implemented under CAS 2.x as a Filter which examines the "service" parameter of the login / proxy request and forwards to an error page if the service is not authorized. A similar implementation may be very possible under CAS 3.0. That is, this feature may not require any changes or accomodations by the CAS server product itself.
Who has done this
Columbia University has done this. So has University of Delaware.
Since CAS has become a service that can authenticate via may tiers (web, web service, etc.), it is no longer appropriate to merely monitor the service parameter. In CAS 3, in order to provide the same functionality, the CAS Core is wrapped via AOP.
Any method in CentralAuthenticationService that provides access for a service (such as grantServiceTicket) is intercepted and checked against the whitelist. Additionally, one may provide a list of services that are allowed to proxy. On delegateTicket, this list is checked. If the service is not allowed access, an UnauthorizedServiceException is thrown, which can be caught by the tier that called the core.
Single Sign Out
High level discussion
Some CAS adoptors, notably the Campus Crusade for Christ, have added a Single Sign Out feature whereby CAS Server calls back client applications for which it validated tickets during the CAS session when the user explicitly logs out of CAS.
Feature specification
This feature might best be specified as a well-defined but optional extension to the CAS protocol. At ticket validation time, the CAS client can specify the URL whereat it would like to be called back with the ticket it is validating, indicating that the user has logged out of CAS. If the CAS server supports the feature, the validation response would include confirmation of the registered logout callback URL. CAS clients not supporting the feature will not specify a logout callback and so will receive an unmodified validation response. CAS clients supporting the protocol interacting with CAS servers which do not support the protocl will not receive callback confirmation in the validation response and so will not expect the logout callback. Clients will have to be prepared to deal with the callback not happening anyway since this affirmative callback might be blocked by network difficulties, etc. CAS clients supporting the protocol interacting with CAS servers supporting the protocol will receive confirmation in the validation response indicating that they can expect the server to attempt the callback. Again, the callback could fail due to network problems, the client application being out of service at the time of the callback, etc.
Who has done this
Campus Crusade for Christ distributes a CAS server modified to implement this feature.
Building on the ServicesRegistry, CAS allows the service to register a SSO callback with CAS. Using AOP we monitor the Ticket registry for the addition of Service Tickets (so we can keep track of the services for a TicketGrantingTicket and the removal of TicketGrantingTickets. On removal of a TicketGrantingTicket, we look to see if there are any entries in our map. We then match the service tickets to the service and execute its callback handler.
Audit Trail
Ryan Matteson kindly provided us with the following information on their use case:
Briefly, we use Log4J to write event logs to either flat files or to an Oracle table (in production, both).
Each log entry includes:
date / time
event type (e.g. TICKET_GRANT, TICKET_VALIDATE, AUTHN_<HANDLER>)
username (if applicable)
client IP address (if applicable)
result (SUCCESS/FAILURE)
service_url (if applicable)
service ticket (if applicable)
We use this for usage reports and capacity planning, as well as for security reviews and incident response.
A more detailed outline is as follows:
Logging
a. Log requirements from security group
i. ability to identify who was logged on based on IP address.
ii. ability to identify who was logged on based on date and time.
iii. online logs retained for at least two weeks
iv. archived logs retained for at least one quarter
b. User interactions:
i. time, WEB LOGIN SERVICE_SID, username, IP, referrer, browser, event description
ii. events logged
1. sees login screen (asked for authentication)
2. successful authentication
3. requested warnings (checkbox checked)
4. unsuccessful authentication
5. authentication warning screen presented (due to user's request)
6. inactivity timeout (session)
7. wall clock timeout (TGT)
8. bad attempt lockout (within WEB LOGIN SERVICE; WEB LOGIN SERVICE won't know about LDAP)
9. logout
c. Ticket events
i. time, granting/validating, WEB LOGIN SERVICE_SID, success/no, username,
IP (of user/of service host), browser/?, referrer, target service, ticket value
ii. (WEB LOGIN SERVICE session id = something that is given to the user at the very first
interaction-- so we can track the user's WEB LOGIN SERVICE session across all requests)
d. Error logging
i. authn store check failed (LDAP or Ecomms or ...)
1. time, username, authn store, detailed error
ii. other exceptions - code audit for ideas
e. Log format
i. Tab separated file
ii. Columns as follows
1. date/time - YYYY-MM-DD HH:MI:SS,MIL
a. HH = 24 hour with leading zero
b. MIL = Milliseconds, 3 digits
2. Event type
a. LOGIN_DISPLAY
b. AUTHN_LDAP
c. AUTHN_<....> (other AuthN handler)
d. CRED_PASS
e. TICKET_GRANT
f. TICKET_VALIDATE
g. LOGOUT
h. INACTIVITY_TIMEOUT
i. WALL_CLOCK_TIMEOUT
j. BAD_AUTHN_LOCKOUT
k. WARNINGS_REQUESTED
3. Session ID - 128 bit in hex format
4. username - email address format
5. IP address - IP source of request
6. success/fail - status of request (where appropriate: b,c,e,f)
7. Service URL (where appropriate: d,e,f)
8. Ticket ID (where appropriate: e,f)
Who has done this
Return link at logout and other Logout customization
High level discussion
When sending the user to the CAS logout page, you might want to provide a URL to CAS such that when it paints the logout page it provides users an opportunity to follow a link to someplace interesting. For instance, upon logging out of CAS from your uPortal instance, you might have the CAS logout screen provide a link back from CAS logout to the uPortal guest page. Columbia's WIND takes this further by allowing services to provide customized text to include in the logout UI.
Implementation notes
Implemented by Yale as checking for the request parameter "url" in the logout.jsp display logic, displaying a link to the provided URL if the parameter is present.
Who has done this
Yale University. Columbia University.
The default CAS 3 view does NOT automatically process anything with the url parameter. However, it would be trivial to swap out the current logout.jsp and replace it with one that checks that parameter and displays additional information.
Logout pass-through
High level discussion
Parameterize CAS logout such that a service can request that CAS redirect the user immediately back to the service, in order to provide CAS logout as part of an application experience.
Concerns about this idea
Ending a Single Sign On session with CAS is something of which a user likely needs to be informed and aware. Allowing CAS itself to paint the UI to represent to the user this having occured is the most straightforward and elegant way to accomplish this communication. We need a compelling use case to drive this feature?
Who has done this
- Columbia WIND.
Built into the Logout Controller, is logic that if it detects the service parameter is set, will attempt to redirect back to the service.
Renew evaluated client-side
CAS 2.0 offers a request parameter "renew" on service ticket validation. Setting renew=true requires that the ST was issued in the same transaction as that which issued its granting ticket – that is, the user presented primary crendentials simultaneous with specifying the target for which the ST was issued.
Columbia WIND includes this boolean in the ticket validation response. Doing so enables clients to determine client-side whether to require this of a ST.
Use case
Suppose a service wishes to allow users to opt into Single Sign On. If this attribute of STs is communicated in the validation response, then the client can examine the authenticated username and whether the ST was issued simultaneous with user presentation of primary credentials. If the user has opted into SSO, great. If the user has not opted into SSO, but the user presented primary credentials at the time the ST was issued, great. If the user has not opted into SSO but the ticket was issued via SSO, then the service can redirect back to CAS login with renew=true.
Who has done this
- Columbia University
Within the model passed to the view on a ticket validation request, is an Assertion. The assertion includes what CAS asserts about the ticket. Part of this is a boolean of isFromNewLogin. Because this is automatically passed by the Controller, one just needs to modify the successful validation view they are using to display that parameter.
Additional Attributes
Many institutions require that additional information be sent back to the CAS client. They have modified the CAS payload to hold these additional attributes.
CAS 3 provides a pluggable point where you may provide a custom Principal and CredentialsToPrincipalResolver. As long as an object inheriting the Principal interface is returned, CAS has no preference as to the underlying implementation. This principal is passed on to the view. If you implement your own custom view (replacing the default success response, you may read any attributes that the principal has attached to it and return them.