Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Panel
borderColor#ccc
bgColor#FFFFCE
titleBGColor#F7D6C1
titleCAS 3 Implementation
borderStyledashed

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:
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

Cal Poly.

...