Re: [Cosign-discuss] Cosign proxy cookie chain question
Thanks to Andrew, Gordon, and Liam for your help along the way. Now with the developer back to office, we finally figured things out! FYI, the Unable to locate the proxy cookie for service was due to a Regular Expression parsing error in service B. The current setting (service A gets both service B and service C cookies and passes them along to service B) does work. Thanks, - Zhen On Thu, Dec 5, 2013 at 10:06 AM, Andrew Mortensen and...@weblogin.orgwrote: On Dec 4, 2013, at 11:23 PM, Zhen Qian zq...@umich.edu wrote: Does service B work when you have service A send only the proxy cookie for service B? No. It does not work with service A sending only proxy cookie for B. As I understand it, you *do* separately have B getting proxy cookies for C, though, and that works. Correct? If that's the case, it sounds to me like there's a problem in service B's handling of the request from service A, and the only way you're going to be able to debug that is with the aid of the person responsible for service B. The response from B you described--Unable to locate the proxy cookie for service--is not in the cosign code, so it must be originating from the B webapp. 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=111408631iu=/4140/ostg.clktrk___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] Cosign proxy cookie chain question
I haven't played with chaining proxy cookies, and I don't have time to right now.. but, in my experiments, I configured server A to get proxy cookies for server B, and server B to get proxy cookies for server C. When I accessed the page at server A (which fetched content for server B), I checked /var/cosign/proxy on server B, and found proxy cookies for server C. I didn't try to use them.. but I'd expect them to work. Liam But mprint-dev is already working with mfile-qa. The change is made last Wednesday. One can go to the mprint-dev.dsc.umich.edu web site, and upload files there. So I assume the the answer to your question is yes. However, the problem with my code is that both proxy cookies are found on ctools side, and there is no corresponding proxy cookie on mprint-dev for mprint-qa server. That's where it is blocked. -- 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=111408631iu=/4140/ostg.clktrk ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] Cosign proxy cookie chain question
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.orgwrote: 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
Re: [Cosign-discuss] Cosign proxy cookie chain question
On Dec 4, 2013, at 1:50 PM, Zhen Qian zq...@umich.edu wrote: 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. So you're sending the service B *and* C cookie in the Cookie header to service B? That's a variation of workflow 2. But service B's app is expecting to get the service C cookie from /var/cosign/proxy/cosign-serviceB=COOKIE_VALUE. That's workflow 1. The design seems fishy to me. How's service B handling the proxied cookies being passed to it? 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. Does it work if you *only* send the service B cookie? I do not have access to serviceB log files. And the developer there is out for this week. Can't help you there. andrew 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 signature.asc Description: Message signed with OpenPGP using GPGMail -- 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=111408631iu=/4140/ostg.clktrk___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] Cosign proxy cookie chain question
On Dec 4, 2013, at 4:35 PM, Zhen Qian zq...@umich.edu wrote: Service B currently 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 that multiple cookies are attached to the request (e.g. one for serviceB, one for serviceC), both will be passed along. It will also check if there are proxy cookies to pass and send those. This means we would be sending 4-5 cookies at serviceC , but this seems alright in practice. Hm. That sounds more like throwing everything at the problem hoping something will stick. Isn't service B already configured to retrieve proxy cookies for service C? As I understand it, you've got service A getting proxy cookies for B and C, and sending them both to B; B retrieves a proxy cookie for C, and sends that one AND the one passed from service A on to service C. 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. Does it work if you *only* send the service B cookie? The workflow works if I attached the proxy cookie to serviceB I got from browser by login in to serviceB web interface. So this means that serviceB can use that proxy cookie, locate the proper proxy cookie file locally in /var/cosign/proxy, and find the cookie for serviceC and pass it along. A proxy cookie is one retrieved by mod_cosign from cosignd, not copied from your browser's cookie jar. :) Does service B work when you have service A send only the proxy cookie for service B? Are you working in UMich? Will you be able to help with the CoSign proxy cookie setting? I don't work for umich, sorry. andrew signature.asc Description: Message signed with OpenPGP using GPGMail -- 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=111408631iu=/4140/ostg.clktrk___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] Cosign proxy cookie chain question
Hi, Andrew: My answers inline: On Wed, Dec 4, 2013 at 10:52 PM, Andrew Mortensen and...@weblogin.orgwrote: On Dec 4, 2013, at 4:35 PM, Zhen Qian zq...@umich.edu wrote: Service B currently 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 that multiple cookies are attached to the request (e.g. one for serviceB, one for serviceC), both will be passed along. It will also check if there are proxy cookies to pass and send those. This means we would be sending 4-5 cookies at serviceC , but this seems alright in practice. Hm. That sounds more like throwing everything at the problem hoping something will stick. Yes, it is for now, unfortunately. Isn't service B already configured to retrieve proxy cookies for service C? Yes. As I understand it, you've got service A getting proxy cookies for B and C, and sending them both to B; B retrieves a proxy cookie for C, and sends that one AND the one passed from service A on to service C. It should be B TRIES to retrieve a proxy cookie for C based on the proxy cookie for B from A. But it failed to locate the proxy cookie file. And I think that is why the error status message unable to locate the proxy cookie for service is returned to service A. On the other hand, obviously the proxy cookie for C which is passed from A does not do the trick, either. 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. Does it work if you *only* send the service B cookie? The workflow works if I attached the proxy cookie to serviceB I got from browser by login in to serviceB web interface. So this means that serviceB can use that proxy cookie, locate the proper proxy cookie file locally in /var/cosign/proxy, and find the cookie for serviceC and pass it along. A proxy cookie is one retrieved by mod_cosign from cosignd, not copied from your browser's cookie jar. :) Sorry, I should say the CoSign cookie for service B from browser. So if I pass that CoSign cookie value to B, B can find the proxy cookie for C file based it, and we can pass C's authentication. Does service B work when you have service A send only the proxy cookie for service B? No. It does not work with service A sending only proxy cookie for B. It does work, as I said above, with service A sending browser CoSign cookie for B. Are you working in UMich? Will you be able to help with the CoSign proxy cookie setting? I don't work for umich, sorry. Sigh... - Zhen -- 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=111408631iu=/4140/ostg.clktrk___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
