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
