I wonder if it makes sense to look into supporting a protocol similar to what Flickr or Facebook use for authorizing desktop applications. It wouldn't be too hard to extend the CAS protocol to handle though I'm not sure if it makes sense to do so or just to look into supporting one of the existing protocols in CAS4.
Cheers, Scott On Mon, Jul 27, 2009 at 2:13 PM, Robert Winch <[email protected]> wrote: > We are wanting to use it for rich client (desktop) applications > authenticating to web services (both soap and REST). The reason for this is > we want a consistent method for authenticating to the services for both web > applications and rich client applications. We planned on allowing the ST or > PT to be resused, as is done in the Spring Security's stateless mode, in > order to prevent the CAS server from being overwhelmed. Any suggestions on > this would be greatly appreciated. > > Thanks again, > Rob > > > On Mon, Jul 27, 2009 at 10:54 AM, Scott Battaglia < > [email protected]> wrote: > >> Great! :-) Out of curiosity, what are your goals for using the RESTful >> API? There may be alternatives depending on what you need. >> >> Cheers, >> Scott >> >> >> >> On Mon, Jul 27, 2009 at 10:30 AM, Robert Winch <[email protected]> wrote: >> >>> Scott, >>> >>> Thank you for your prompt response. Your points have made me feel better >>> about using the CAS RESTful API. >>> >>> Thanks again, >>> Rob >>> >>> On Sat, Jul 25, 2009 at 10:20 AM, Scott Battaglia < >>> [email protected]> wrote: >>> >>>> On Fri, Jul 24, 2009 at 12:40 PM, Robert Winch <[email protected]>wrote: >>>> >>>>> I am hoping someone can make me feel more comfortable about the fact >>>>> that the CAS RESTful API specifies the TGT in the URL when requesting ST >>>>> [1]. It is my understanding that you should not put sensitive information >>>>> in >>>>> URI's even if it is over HTTPS. This is because URIs are often exposed in >>>>> http access logs (among other things). >>>> >>>> >>>> I understand your concern, but its your responsibility to ensure that >>>> the entire transmission is secure from end-to-end. Even if you put it in a >>>> header, the entire request can be exposed at some point (we, for example, >>>> use monitoring tools that can inspect the HTTPS packets). Not putting it >>>> in >>>> URL merely eliminates it from being logged in an Apache log by default >>>> (though configuring your Apache server can have the same result). >>>> >>>> >>>>> >>>>> >>>>> Does anyone have any information on why the TGT isn't in the header >>>>> and/or why putting the TGT in the URI is safe? >>>> >>>> >>>> Its a RESTful resource and conforms to the definition of REST, which is >>>> why its designed the way it is. Again, its your responsibility to ensure >>>> that you're system is properly secured. If you want to use SOAP or some >>>> other mechanism, that's your responsibility to design. >>>> >>>> >>>>> Is there a possibility to configure the resource to look in the header >>>>> instead/also, or does this cause other concerns? >>>> >>>> >>>> No it can't be configured to look in the header. Its not designed to. >>>> You really have two options: (1) ensure you've secured it or (2) don't use >>>> a >>>> RESTful resource if you're concerned about the resource exposure. >>>> >>>> The RESTful API has one very specific use case: enabling >>>> service-to-service interaction without a user. If you're using it for >>>> anything other than that, you should revisit why you're using it. Its not >>>> intended for any interactions that involve a human user. >>>> >>>> Cheers, >>>> Scott >>>> >>>> >>>>> >>>>> Thanks in advance, >>>>> Rob >>>>> >>>>> [1] http://www.ja-sig.org/wiki/display/CASUM/RESTful+API >>>>> >>>>> -- >>>>> 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-dev >>>>> >>>>> >>>> -- >>>> 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-dev >>>> >>>> >>> -- >>> 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-dev >>> >>> >> -- >> 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-dev >> >> > -- > 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-dev > > -- 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-dev
