On November 29, 2011 16:28 , "J.Lance Wilkinson" <jl...@psu.edu> wrote: > I guess I'm confused that something which SEEMS as commonly needed as this > kind > of feature would be, that there wouldn't be a cut/paste cookbook to implement > it. Every example in these discussions (and I see there are a few) differ in > details and I've tried to model every one of them with no luck.
I think what you are trying to do is really neat, and I agree that it can be useful. I've never needed to do it, though, because I've been lazy and lucky and have always been able to configure my web applications to use cosign for authenticating users and to use something else (a client-side SSL certificate, or a "trusted" IP address) to authenticate scripts. The "Satisfy any" directive for Apache HTTP Server is useful for this. Hopefully someone else -- someone who has written a script that authenticates by emulating a web browser -- will be able to help with the question you actually asked. The overall flow should be: 1. GET the login page on the central weblogin server in order to get and save the central weblogin cookie. 2. POST the username and password to the CGI on the central weblogin server, providing the central weblogin cookie when you do so. You will get a number of redirects and cookies back; ideally, you'd want to follow all the redirects and save all of the cookies. 3a. GET a URL for your webapp; note that you cannot POST here because you are not yet authenticated to the cosign service for your webapp, you're only authenticated to the central weblogin servers at this point, and POST data will be lost during authentication. 3b. you will be redirected to the central weblogin servers: https://${cosignHost}/?{cosignServiceName}&${url_from_step_3a} 3c. you will be redirected back to the URL validator on the web server running your web app: https://${your_web_server}/cosign/valid/${cosignServiceName}=${temporary_cosignServiceCookieValue}&${url_from_step_3a} 3d. A cosign service cookie will be set -- you need to save this and provide it on all subsequent requests to your web app -- and at the same time you will be redirected to the URL from step 3a. 3e. Your web app provides the content for the GET request originally made in step 3a, which you made again in step 3d. 4. POST the data that you want to the appropriate URL for your webapp, providing the cookie set in step 3d. I suspect that, from what you described, you are not performing steps 3b-3e, all of which should be performed by the third curl command you listed. Try to get a better idea of what the third curl command is or is not doing; the -v or --head options may be useful for this if the -w you already have is not showing you what's happening. Again, I recommend using a different type of authentication for scripts, such as client-side SSL certificates, if this is possible in your case. -- Mark Montague LSA Research Systems Group University of Michigan markm...@umich.edu ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
