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