Hi, Andrew:
Thanks for your reply. Here are my answers:
>> Do you have workflow 1 or 2 implemented? From your description it sounds
like you're using workflow 1.
We have a mix of #1 and #2 deployment now:
serviceB is configured to look for any incoming cosign cookies and will
pass them along. It will also look for any associated proxy cookie files
and pass the cookies inside. This means serviceA sends both proxy cookies
for serviceB and serviceC over to serviceB. serviceB will also check if
there are proxy cookies to pass and send those.
>Given what I know about the services you're using (thanks to a umich
e-mail thread), I'd say workflow 1 is what you want in the long run, since
service B on its own would also benefit from retrieving proxy cookies for
service C.
serviceB is already talking with serviceC using the CoSign proxy cookies.
Our task now is to add another layer, serviceA to this workflow.
I agree that #1 is better approach.
> Yes, this is what it should be doing. The mod_cosign filter has no way of
distinguishing a proxy cookie from a cookie attached to a user's browser
request. Where do things break down? What responses do you get from
services B and C? What do you see in the apache error logs on services A
and B?
We do not have this pattern deployed for CoSign server now, i.e. send
serviceB proxy to service A, and send serviceC proxy to serviceB
The patter we have now is sending both serviceB and serviceC proxy cookies
to serviceA.
The result is serverA gets "Unable to locate the proxy cookie for service"
status message from serviceB. So I guess it is due to the serviceB cannot
use the proxy cookie from serviceA to locate the proxy cookie file, and
furthermore the proxy cookie for serviceC is not effective.
I do not have access to serviceB log files. And the developer there is out
for this week.
Thanks,
- Zhen
On Wed, Dec 4, 2013 at 1:25 PM, Andrew Mortensen <and...@weblogin.org>wrote:
> Answers inline below.
>
> On Dec 3, 2013, at 11:55 PM, Zhen Qian <zq...@umich.edu> wrote:
>
> > Hi, all:
> >
> > Using cosign proxy cookie, user can be automatically authenticated to
> secondary services (
> http://webapps.itcs.umich.edu/cosign/index.php/Using_Proxy_Cookies).
> >
> > I now have three services that are integrated in this sequence: serviceA
> -> serviceB - > serviceC. I have questions as for how to pass the proxy
> cookies.
> >
> > Here are two proposed workflows:
> >
> > # 1: ===============
> > 1) User authenticate with serviceA , which will bring down a proxy
> cookie for serviceB
> > 2) Make a request to serviceB, attaching the serviceB proxy cookie
> > 3) Authentication is successful to the serviceB, the serviceB server
> will pull its own set of proxy cookies including one for serviceC
> > 4) serviceB makes a request to serviceC, attaching the serviceC proxy
> cookie
> >
> > # 2: ===============
> > 1) User authenticate with serviceA, which will bring down a proxy cookie
> for serviceB and serviceC
> > 2) Make a request to serviceB, attaching the serviceB proxy cookie and
> the serviceC proxy cookie
> > 3) Authentication is successful to the serviceB server
> > 4) serviceB makes a request to serviceC, using the serviceC proxy cookie
> that was originally sent from serviceA
> >
> > Now that I have "#2" workflow implemented, however in step 3) serviceB
> cannot pull down its own set of proxy cookies (not sure why this would be,
> maybe the proxy cookie process does not kick off when one authenticate
> using a proxy cookie, which would shut down chaining. And the subsequent
> step 4) failed authenticating user with serviceC using the serviceC proxy
> cookie.
>
> Do you have workflow 1 or 2 implemented? From your description it sounds
> like you're using workflow 1.
>
> > My questions are:
> >
> > 1. Between #1 and #2, which is the recommended approach? Or is #2
> approach feasible at all?
>
> Workflow 1 has the drawback that services A and B must be configured to
> pull down proxy cookies. Workflow 2's has the ugly necessity of sending the
> cookie for service C in the request to service B, either as an X-header or
> in the body, and service B must know how to extract the service C cookie.
>
> Given what I know about the services you're using (thanks to a umich
> e-mail thread), I'd say workflow 1 is what you want in the long run, since
> service B on its own would also benefit from retrieving proxy cookies for
> service C.
>
> > 2. Is it possible that upon user authentication as in step 1), cosign
> server pass serviceB proxy cookie to serviceA server, AND also pass
> serviceC proxy cookie to serviceB server?
>
> Yes, this is what it should be doing. The mod_cosign filter has no way of
> distinguishing a proxy cookie from a cookie attached to a user's browser
> request. Where do things break down? What responses do you get from
> services B and C? What do you see in the apache error logs on services A
> and B?
>
> andrew
>
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss
