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
