...
| Panel | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
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. |
...
| Panel | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
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:
| Panel |
|---|
Briefly, we use Log4J to write event logs to either flat files or to an Oracle table (in production, both). Each log entry includes: 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:
| No Format |
|---|
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
...
| Panel | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
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. |
...
| Panel | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
Built into the Logout Controller, is logic that if it detects the service parameter is set, will attempt to redirect back to the service. |
...
| Panel | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
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. |
...
| Panel | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
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. |