Thanks for the speedy response Andrew! Perhaps I'm misunderstanding your response to my first question but wouldn't asking the user to login to a second service when they had just accessed a different service be confusing to the user? Although now that I've re-read your response, perhaps I should clarify that in my example serviceone and servicetwo are both sensitive applications that use CAS for authentication. And in my case, the end user doesn't really know where one service ends and another begins.
On the change password functionality, I'm not sure I understand what you are suggesting. If I have 5 webapp services that all use a single CAS webapp for authentication, then it should *not* be up to each service to check the status of a users password. And since there is not necessarily another gateway for accessing the services, it would seem like the only place to check a passwords status would be in CAS. thanks, -rg On Jan 2, 2008 11:44 AM, Andrew R Feller <[EMAIL PROTECTED]> wrote: > Rg, > > > > 1) No, this is not available in CAS 3.1. If you need separate TGTs > (levels of assurance), then you can set up two different CAS > servers/clusters. This would allow for you to have sensitive applications > on a different authentication and expiration policy than non-sensitive > applications. > > 2) Given suggestion in 1), this would work as normal > > 3) No, this is not available in CAS 3.1. I always thought it was > unadvisable for services to access users' TGTs because then it would allow a > compromised service to masquerade as a user. > > 4) No, this is not available in CAS 3.1. I wonder if such a > feature should be part of CAS or not because it ventures into the realm of > identity management. Please don't misunderstand me; we force users to reset > passwords, too. The beauty of CAS is that it allows you to separate the > authentication mechanism from the identity management so users only interact > with authentication. I would probably have whatever application / portal > your users log check to see if users must update their passwords and force > them. > > > > Hope this helps, > > > > Andrew R Feller, Analyst > > University Information Systems > > 200 Fred Frey Building > > Louisiana State University > > Baton Rouge, LA, 70803 > > (225) 578-3737 (office) > ------------------------------ > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On > Behalf Of *rg > *Sent:* Wednesday, January 02, 2008 10:19 AM > *To:* [email protected] > *Subject:* functionality questions (3.0 vs 3.1) > > > > 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 > > Scenario: > > - User attempts to access serviceone and is redirected to CAS for > authentication > > - User logs into CAS and is redirected back to serviceone > > - User accesses serviceone continuously until TGT is expired (value in > grantingTicketExpirationPolicy bean in applicationContext.xml) > > - User attempts to access servicetwo, however due to the fact that their > TGT is expired, is redirected back to CAS for re-authentication. > > > > To the user, this would be confusing since they were already logged in and > were accessing serviceone. To deal with this scenario, there would need to > be some sort of call back mechanism from each service's page request to the > CAS webapp. Is there such a call back in CAS 3.1? > > > > > > 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. > > > > > > 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. > > > > > > 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? > > > > > > Thanks for your help! > > -rg > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
