The main difference between ClearPass and the RESTful API is usually you've explicitly authorized something to use ClearPass.
Cheers, Scott On Tue, Mar 16, 2010 at 10:44 AM, William G. Thompson, Jr. <[email protected] > wrote: > 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
