RG, Some responses are in-line.
On Jan 2, 2008 11:18 AM, rg <[EMAIL PROTECTED]> wrote: > Happy new year everyone! I hope you all had a restful break. > > I have a few questions regarding functionality in CAS 3.1. I had > previously investigated CAS 3.0 + acegi and found certain pieces missing > that I ended up extending in my proof of concept. I was wondering with the > new CAS 3.1 release, if any of these are addressed. > > If any of these don't make sense, or are workable in a different way, > please feel free to point out my ignorance. :) > > > 1) Service dependent TGT expiration > This doesn't really make sense as the Ticket Granting Ticket session exists independent of any service (i.e. you can start an SSO session without attempting to access a service). If you have extremely sensitive applications, they can OPT OUT of single sign on. The SSO session is per User Agent and not per application though. You can also specify the length of the single sign on session (also, the number of uses). > <snip /> > > 2) Username available in the CAS webapp > For logging purposes, I'd like access to the username of a previously > authenticated user in the CAS application. So that when a user attempts to > access servicetwo with a valid TGT, i can put that username in my access > log. > CAS 3.1.2 (or CAS 3.2, whichever we label it) will include built-in support for auditing and statistics, including access to the username. We don't have a timeline for that though. > > > 3) The TGT id that was used to validate user is available in each service > Again for logging purposes, I'd like access to the TGT id, this time in > each service webapp. This way I can keep track of a users session across > webapps. > For security purposes the number of things that have access to the TGT should be minimized (a compromised service could grant access to a user's SSO session). This is why the Ticket Granting Ticket cookie is scoped specifically. > > > 4) Force change password screen > I'd like a mechanism for forcing the user to change their password. > Previously, I extended acegi User with that information, and checked that > in each service web container. This is not appropriate as the service > container shouldn't care about password expiration. What I would prefer is > to allow the user to log on and create a TGT, but not allow any service > tickets to be created. This may have been possible with CAS 3.0, but I > just didn't look into it. Is it possible? > You could write a custom authentication handler that threw a PasswordExpiredException and catch that at the web tier (and the do whatever you need to do). However, that would not create a TicketGrantingTicket. -Scott > > > Thanks for your help! > -rg > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > > -- -Scott Battaglia LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
