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 <tedzo2...@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.battag...@gmail.com> > *To:* Yale CAS mailing list <cas@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 <tedzo2...@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.battag...@gmail.com> >> *To:* Yale CAS mailing list <cas@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. <xbke...@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@tp.its.yale.edu >>> http://tp.its.yale.edu/mailman/listinfo/cas >>> >>> >> >> >> _______________________________________________ >> Yale CAS mailing list >> cas@tp.its.yale.edu >> http://tp.its.yale.edu/mailman/listinfo/cas >> >> > > > _______________________________________________ > Yale CAS mailing list > cas@tp.its.yale.edu > http://tp.its.yale.edu/mailman/listinfo/cas > >
_______________________________________________ Yale CAS mailing list cas@tp.its.yale.edu http://tp.its.yale.edu/mailman/listinfo/cas
