Scott and Jose, Thank you both for your replies! Scott, I completely agree with you that usernames and passwords should never be passed via GET. The plan was to POST them all along. I just wanted to temporarily test my CAS deployment via a web browser, since I wasn't getting the behavior I expected. Your suggestion to grab the _eventId parameter and submit it along with the lt parameter, username, and password worked for me.
Thanks again, Pat From: Scott Battaglia [mailto:[email protected]] Sent: Wednesday, April 28, 2010 11:52 PM To: [email protected] Subject: Re: [cas-user] authenticating a user via URL parameters I'll repeat what I've said before. No client application should be passing the username and password directly to CAS. No client application should be doing this either via a GET, POST, or RESTful API call. There are one exception to this rule: Applications that monitor your infrastructure. One of the main points of CAS (besides actual single sign on) is that the client applications NEVER see the username and password. So if its not easy, convenient, etc., to do this, there's a reason for it. The reasons for this are numerous (and have been detailed before). That said, any thing that can GET the page, parse out the LT, and then POST can interact with CAS programmatically. If you need it to *look* like the application is authenticating you, you should look towards one of the solutions that uses IFRAMES to embed the login into the page. Apologies if this response sounds harsh, but since all of these emails are publicly archived, I need to make sure the security warning appears every time otherwise someone will come along and say "oh you didn't say not to do this and it was on the list" :-) Cheers, Scott 2010/4/28 José Miguel Parrella Romero <[email protected]<mailto:[email protected]>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Scott Battaglia escribió: > To authenticate a user, the values should be passed via POST. We don't > recommend you pass them EVER as part of the query String. The point is > that no application should know the password. > > If you grab the other parameter (the _eventId) you may be able to do it > via GET (I haven't tried), but again we don't recommend it. Scott and Patricia, I've been trying to authenticate via GET using lt, _eventId, username and password to no avail. At least for me the problem resides on lt being generated on each request, and you need to use it in the next request, otherwise you keep getting redirected to the login form. What I did is implemented as a client-side Javascript piece of code which relies on an additional parameter (e.g., 'auto') and submits the form after prepopulating it with username and password. It also needs the <input type="submit" ...> name being changed from submit to other thing, such as 'submitButton' or 'sendIt' This way, you accomplish requesting via GET or POST, passing just the username, password, service and the 'auto' parameter which triggers the Javascript code which auto-submits the form. Take into account that CAS will redirect you back to the service (302 with the ticket being passed as a parameter via GET to the service) unless you use method=POST, in which case your application should be prepared to receive params back. This is really a difficult way of 'automating' logins to CAS, and I think that using the RESTful interface would make for more elegant results, even though I had to write down a Perl webservice which uses WWW::Mechanize to go to the login form, write down the form and then submit it, get a redirect back to the service with the ticket, and extract it... a truly complex solution. HTH, - -- José Miguel Parrella Romero (bureado.com.ve<http://bureado.com.ve>) PGP: 0×88D4B7DF Debian Developer Caracas, VE/Quito, EC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJL17zGAAoJEMAyQqmI1LffySIQAKfs8v24Ldev9avrWcxjxN2v DiLpgzblKbxjX3SwlstL7qhn7m4pTrVd2nSKvk+WXBNE1SdzdtiIrWyIGq7O9O+y Dqaj9uIcgsCq5UcoXUxC2NEvmu4Cd9Dctqn4UABtRo6zYoN7I/Vvsy7d8Narm5P0 d99wOtvGw8JWbpEg4c8MvAKLfndDu9WFPTCV1ZJtNtboOryRgPosN73xUeT4kygO 3DlUaXt/irKMjfAqPfomOJQyykk511XW4s90W+DNNB0SUMKxx24BCZSzUfagpUs2 nIdSL1J51IJMwS9LKoo3cifej82KKTgQ50vrB+Ecdc/KkLvEOudUHayqcMUAlznq olyoV3q+7U1loZDSFbUPTDTx8fZYbSb6W7whElyHEilAOFaWzt4ZJQ6ouy75GM7G xOIRObOskiYQJZzu0SYlibE9q3tv6j3fQsG58gqET9Gix3d1BVkt5oFF3pe3ZEW0 I4ijrXQxFKprq6jzndvHChtJf7/6uro+IJ3oNX1DNo1ZB2/KsMgktPgqgFGX5jPm z6SPZTpa3BtcDek5tLedjeajFnrmk2n2JGszM5FXakbFeicQTBVuZuUTaYjIkW3G UtV8WEinAmKx85bVSCl1v2EarSKdT+ZzVBDHD8deuimfFmsqsQ265hUK9adQQO0Q ccwWMmA0x0SLdLhBFyyR =qM1x -----END PGP SIGNATURE----- -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
