CAS and remote methods

Wed Jan 28 08:12:34 EST 2009

For an interaction that doesn't involve a web browser, you need to take care
to obtain a ticket BEFOREHAND and supply it to the service on the first
request.

You can do this by either (a) obtaining a proxy ticket if you're acting on
someone's behalf or (b) using something like the RESTful API to get a
service ticket for your service.

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

On Wed, Jan 28, 2009 at 2:19 AM, Kevin M. <xbkevin at gmail.com> wrote:

> Hi,
>
> I don't mind at all... it's helping me to try to understand how CAS works.
> But I'm still trying :)
>
> I'm trying to understand a CAS flow diagram, when there's a remoting
> protocol involved (e.g. HttpInvoker)   A helpful diagram is at
> http://mattfleming.com/node/287, that shows a CAS sequence involves spring
> security, though not with HttpInvoker in the picture.
>
> [browser] (let's say instead it is some application or service) is  trying
> to connect to another [application], using HttpInvoker, wanting to
> authenticate as some user (but not on behalf of one).  So when a request is
> made from [browser] to the [application] (step #2), there's a redirect done
> to [browser], to go to the CAS Server (step #5).  I think the HttpInvoker is
> able to maintain session information/cookies; I'm trying to figure out how
> to get authenticated through the HttpInvoker call (if that's possible?) in
> the first place.
>
> But, at #5 (redirect to CAS Server), wouldn't the HttpInvoker get messed
> up?  From what I've been informed, the HttpInvoker doesn't handle redirects
> well?  But if it does handle them well, also, wouldn't the HttpInvoker get
> stuck at the redirect to the login?  As in, would one be expected to input
> the credentials there?  I didn't think the HttpInvoker could do that (my
> view is that on the client side, the HttpInvoker calls the URL to the
> [application] and expects a response back... and having the CAS
> presence/redirection poses a dilemma, since it's not expected in the flow).
>
> I wonder, for remoting, should this diagram even be considered? I think I
> am thinking about the approach in the wrong manner.  I apologize also, if
> this question doesn't seem to make much sense; (thought I was starting to
> understand CAS a little bit until it was mentioned to consider HttpInvoker
> requests)...
>
> Thanks for your time and insights!
>
> Kevin
>
>
> On Tue, Jan 27, 2009 at 3:11 AM, tedzo <tedzo2003 at yahoo.com> wrote:
>
>> Thanks for your response.
>> A related question (I apologize to the OP for hogging this thread.
>> Hopefully, the information is useful to him too..) - In the wiki describing
>> the RESTful API, it states "Applications need to programmatically access
>> CAS. Generally, proxying works for this". Where can I find out how this
>> proxying thing works with respect to accessing CAS programatically?
>>
>> Thanks. Your effort is appreciated, as always.
>>
>> ------------------------------
>> *From:* Scott Battaglia <scott.battaglia at gmail.com>
>> *To:* Yale CAS mailing list <cas at tp.its.yale.edu>
>> *Sent:* Monday, January 26, 2009 7:41:06 PM
>>
>> *Subject:* Re: CAS and remote methods
>>
>> Depending on why the service is accessing the web service you should
>> either use a proxy ticket (if you're accessing on behalf of a person) or the
>> RESTful API if a service is attempting to access another service.
>>
>> -Scott
>>
>> On Fri, Jan 23, 2009 at 2:24 AM, tedzo <tedzo2003 at yahoo.com> wrote:
>>
>>> This is something I have been thinking about a bit.
>>>
>>> About option #2, I assume the service for which a ticket is obtained is
>>> the url of the web service I am trying to invoke. Does that sound right? Is
>>> there a standard method to obtain a service ticket for a web service url? In
>>> the past, I have used a hack that posts a request (2 actually) and parses
>>> the response to extract the service ticket. I am wondering if there is a
>>> standard approach to doing this.
>>>
>>> Thanks for your time.
>>>
>>> ------------------------------
>>> *From:* Scott Battaglia <scott.battaglia at gmail.com>
>>> *To:* Yale CAS mailing list <cas at tp.its.yale.edu>
>>> *Sent:* Thursday, January 22, 2009 5:35:06 PM
>>> *Subject:* Re: CAS and remote methods
>>>
>>> For web services, its up to your application to maintain some form of
>>> session, otherwise the application would need to re-authenticate each time.
>>>
>>> That means you have two options:
>>> 1. Do something like what Spring Security does, which is cache the
>>> service ticket key for a period of time, and essentially forces it to be a
>>> session key.
>>> 2. Have your calling application retrieve a service or proxy ticket
>>> before making each request to the web service.
>>>
>>> -Scott
>>>
>>> -Scott Battaglia
>>> PGP Public Key Id: 0x383733AA
>>> LinkedIn: http://www.linkedin.com/in/scottbattaglia
>>>
>>>
>>> On Wed, Jan 21, 2009 at 8:01 PM, Kevin M. <xbkevin at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Sorry, another newbie-related question.  I have some questions about
>>>> if/how CAS works with calls on remote objects.  I'm not that
>>>> Spring-knowledgable, but from discussions with developers who are
>>>> Spring-saavy, they are interested in using the a remote invocation mechanism
>>>> called HttpInvoker to carry out these requests using HTTP(s), so from one
>>>> machine they can make a call on an object that resides on a remote pc.  What
>>>> seems confusing to me is, wouldn't the CAS URL pattern filters (say, if I
>>>> had in my  "/*")  intercept every HttpInvoker call made, and then cause
>>>> problems, if we are communicating from pc1 to pc2 (who is using CAS to
>>>> protect their web application).  Say, HttpInvoker makes some call, and
>>>> expects the call is going straight through to access the remote object
>>>> and/or return some object/value.  But, the CAS URL filter will intercept,
>>>> and (may redirect to login URL, for example), which would throw off what
>>>> HttpInvoker would expect?
>>>>
>>>> 1) Am I looking at this situation in the right way?  Is there an
>>>> existing page that describes in some detail how the above might play happily
>>>> together?  If there is not, would somebody mind to explain an approach (or
>>>> key points to be aware of?)
>>>>
>>>> 2) Is there some way to make these invocations without needing to
>>>> explicitly log-in?  Kind of like where the remote API call is running as an
>>>> "internal service" level?  Because it seems awkward to me to have so many
>>>> steps (but, maybe it is necessary?) to have to go through some process to
>>>> log-in (as some predefined "service" user, maybe, which also seems like
>>>> awkward) , get the single-sign-on cookie, and grab a service ticket, to
>>>> build the connection, for something that is considered sort of "background"
>>>> process.
>>>>
>>>> 3) I had remembered seeing (older, pre 2.0) notes for Acegi security
>>>> that describes what sounded like a similar dilemma, and mention of a
>>>> "stateless" user.  I didn't fully understand how it worked, and was looking
>>>> in the Spring Security's 2.0 documentation (
>>>> http://static.springframework.org/spring-security/site/reference/html/springsecurity.html) for perhaps an update/example, but I could not locate anything that
>>>> described the stateless-ness.  I see in the API docs, there is a
>>>> CasAuthenticationProvider which mentions "CAS_STATELESS_IDENTIFIER" (and
>>>> that sounds a lot like what will be done with HttpInvoker), though.
>>>>
>>>> But, assuming HttpInvoker and CAS being friendly is possible, is Spring
>>>> Security necessary to support such a setup, or can this be easily(?) handled
>>>> with CAS standalone?
>>>>
>>>> Thank you for any insights!
>>>>
>>>> Kevin
>>>>
>>>> _______________________________________________
>>>> Yale CAS mailing list
>>>> cas at tp.its.yale.edu
>>>> http://tp.its.yale.edu/mailman/listinfo/cas
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Yale CAS mailing list
>>> cas at tp.its.yale.edu
>>> http://tp.its.yale.edu/mailman/listinfo/cas
>>>
>>>
>>
>>
>> _______________________________________________
>> Yale CAS mailing list
>> cas at tp.its.yale.edu
>> http://tp.its.yale.edu/mailman/listinfo/cas
>>
>>
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20090128/a0d4707d/attachment-0001.html 