Ok, with the caveat that the browser itself certainly does see the credentials... But I take your point that the application doesn't see them. Thanks!
________________________________ From: Scott Battaglia [mailto:[email protected]] Sent: Tuesday, 16 March 2010 2:38 p.m. To: [email protected] Subject: Re: [cas-user] Does CAS offer SSO between web applications AND a .NET fat client deployed with click once ? One of the main points of CAS is that the applications don't see the credentials. Using the RESTful API to authenticate the user's credentials violates this. Cheers, Scott On Mon, Mar 15, 2010 at 9:35 PM, Dale Ogilvie <[email protected]> wrote: What is the problem with using the RESTful api to authN the user? You are never going to get SSO between web and thick clients. However, you are just exchanging the browser data-entry application for a .NET one to receive the credentials from the user. The pipe to the CAS server is still the same, i.e. https secured, but from .NET app to CAS instead of firefox/IE/Opera to CAS. When the TGT comes back to the client, instead of going into the browser cookie "vault" it is going into the custom client memory/persistent store. This is more "obscure" than the browser cookie store, with as much security as you choose to implement in your fat client. Once you have the TGT in the .NET/java/etc client you can then grab ST's using the TGT, in the same way as a browser does automagically by presenting the TGT back to the CAS server. I agree with you as soon as you start sending the sso creds over the network, but if we are just talking a different client application replacing the browser on the user's workstation, I don't see the problem. Please explain. Thanks Dale ________________________________ From: Scott Battaglia [mailto:[email protected]] Sent: Tuesday, 16 March 2010 5:48 a.m. To: [email protected] Subject: Re: [cas-user] Does CAS offer SSO between web applications AND a .NET fat client deployed with click once ? The RESTful API is NOT designed for that type of behavior, nor is it supposed to be used for that. The goal of the RESTful API is to allow for service-to-service non-human interaction without handing passwords over to other services (one could use certificates to do a similar thing). At Rutgers, our APIs (we actually have SOAP and not REST at the moment) are configured such that you can't even send the username/password for a user via that programmable API. Cheers, Scott On Mon, Mar 15, 2010 at 12:45 PM, William G. Thompson, Jr. <[email protected]> wrote: On Mon, Mar 15, 2010 at 12:14 PM, Scott M. Holodak <[email protected]> wrote: >> Sure you could. In the local install (start menu) launch, the app >> could just request the user's credentials and authN directly against >> CAS. > > The only problem with authenticating in the client app is that the > client app can't [easily] initiate an SSO session and pass proxy tickets > back to web browsers. True, but I was assuming that in the local launch, SSO was out of the question. The .NET Client could just use the CAS Server REST API to authN the user and not worry about Tickets at all. http://www.ja-sig.org/wiki/display/CASUM/RESTful+API Bill -- 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
