Perhaps in an ideal CAS environment, only the page served by the CAS server application receives the creds. Creds are still typed by the user into a browser application, the important bit is an HTTP post to the CAS server. This browser could be IE/Firefox/Opera.. You get the picture. Alternatively, it could be a chunk of script posting form data at the CAS server URL, kind of like the REST API.
With a non-browser client, CAS is still the sole *receiver* of the creds, the only difference is that the user is entering them into a .NET/java etc app, and the endpoint exposes a different protocol. I think the RESTful api exposes a useful "central authentication service" endpoint for non-browser applications. -----Original Message----- From: William G. Thompson, Jr. [mailto:[email protected]] Sent: Wednesday, 17 March 2010 3:44 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 ? On Mon, Mar 15, 2010 at 10:19 PM, Dale Ogilvie <[email protected]> wrote: > 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. More to the point I think is that in an ideal CAS environment, only the CAS Server (and primary authN mechanism of course) handle the credentials. In this scenario, there is a higher confidence level that the credentials are not being mishandled. Opening up the REST API for primary authN for users short circuits this protection, as does ClearPass to a some extent. Another consideration is that you might want to train your users to only provide their credentials to CAS in an effort to minimize phishing attempts. Of course the technical and social environments we find ourselves are not always conducive to idealized deployments. :) Cheers, Bill > > 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 -- 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
