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 <[email protected]> To: Yale CAS mailing list <[email protected]> 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. <[email protected]> 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 [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
