For whatever it's worth: Yes, it is possible to do credential replay through the CAS login form [1], and no, I wouldn't recommend that.
Rather, offhand, I'd recommend giving your central login application another path into the CAS login flow that allows it to securely assert the user's identity. CAS doesn't need you to post the username and password, it needs the central login application's assurance that the logged in user is whoever the logged in user is. So, get the browser to post a cryptographically signed identity assertion to CAS, or have your central login application generate the equivalent of a CAS service ticket and have CAS call back with that ticket to the central login application to find out who the user is, or something along those lines. Anything like that would be healthier than replaying the credentials through the browser as a form post. CAS has good support for multiple kinds of credentials, multiple ways to validate them. Once you've got a central login application asserting identity, there are better ways to do that than by credential replay. Hope this helps, Andrew [1]: For a potentially painful and arduous meaning of "possible", since for one thing you'll have to contend with the login ticket, which is designed to make every CAS login form unique and more difficult to automatedly replay. :) On Feb 24, 2012, at 5:34 PM, Krzewinski, Kevin R wrote: > Thanks for the response. > > Some of our users have multiple logins to our applications. Our current login > application takes the credentials, authenticates, looks up in the system if > there are multiple userids and presents it to the user to select one. They > select, it is logged and that ID and password is then posted to the > application which usually authenticates by an LDAP lookup. It is not > currently an integrated SSO, but we want to work towards that without a big > bang cutover. > > Right now we have an application that needs CAS. We want to integrate CAS > into the current environment. We would like the user to enter the userid and > password in the central logn application and then have that application also > create a CAS ticket and the CAS cookie for a SSO experience for other > applications that would use CAS. > > Since we can't set the cookie, is it possible to post the userid and password > to the CAS login page, have it create the ticket, set the cookie and return > to the application without the user having to take an action? > > -----Original Message----- > From: Andrew Petro [mailto:[email protected]] > Sent: Friday, February 24, 2012 2:20 PM > To: [email protected] > Subject: Re: [cas-user] Setting the Ticket Granting Cookie > > Hi Kevin, > > I sure hope it's not possible for applications other than CAS to set (and > read) the ticket granting cookie. That would be a problem, since anything in > possession of the end user's ticket granting ticket can log in as the user to > CAS-using relying parties. > > So, yes, you can get a TGT via the restful API. And no, you can't set that > TGT as a cookie that will then afford single sign-on through the CAS login > screen. Unless, I suppose, you're writing a powerful enough plugin to a web > browser or the like. > > If you want the user to experience single sign-on through the CAS login > screen, that is, to have a single sign-on session with CAS, then you'll need > CAS to set that ticket granting ticket into the ticket granting cookie. > > > (A more typical use of the restful API might be for non-human principals to > obtain CAS tickets to access services as themselves, or for human principals > to interact with CAS by means of a fat client application that wanted to > validate credentials against the CAS server or to access CAS-using relying > parties as the user.) > > (For instance, I was involved in a proof of concept once upon a time of > making Sakai validate credentials against CAS, such that when Sakai is > accessed in a web browser, it's simply CASified, but when a user accesses a > non-web-based modality of accessing Sakai, such as via WebDAV mount of the > file shares associated with Sakai worksites, the enterprise username and > password would work, with Sakai validating it against CAS. This had some > interesting tradeoffs vs Sakai validating it directly against, say, LDAP, in > that it benefited from whatever abstractions CAS was providing, perhaps > validating passwords across multiple backing stores.) > > > > Maybe this would be an interesting conversation: what are you trying to do > with the restful API? > > Kind regards, > > Andrew > > > > > > > > On Feb 24, 2012, at 4:27 PM, Krzewinski, Kevin R wrote: > >> Hi, >> >> I've read the documentation on using the restful API to get a TGT. But is it >> possible to set the ticket granting cookie without going to the login page? >> Can someone point me to some documentation? >> -- >> You are currently subscribed to [email protected] as: >> [email protected] To unsubscribe, change settings or access archives, >> see http://www.ja-sig.org/wiki/display/JSG/cas-user > > > -- > You are currently subscribed to [email protected] as: > [email protected] To unsubscribe, change settings or access archives, > see http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
