Joachim Keltsch <[EMAIL PROTECTED]> writes: > Package: webauth > Version: 3.5.5-1 > XX-Debbugs-CC: [EMAIL PROTECTED] > XX-Debbugs-CC: [EMAIL PROTECTED] > Severity: wishlist > Tags: patch > > Hello everybody, Russ, > > as discussed in > https://mailman.stanford.edu/pipermail/webauth-info/2007-June/000286.html > here it finally is: a patch that allows Weblogin to use forwarded > credentials instead of a username and password. (Well, I must admit, > that were some very long three weeks ;-)
[...] As you've seen, this is now in 3.6.0. I wanted to follow up, though, since the implementation was somewhat different. > Weblogin (login.fcgi) has been adjusted to check if forwarded Kerberos > Tickets are available. If so, the script will store the delegated TGT > in the login token instead of a username and password (and the user > won't be bothered with the login page) Rather than changing the interface around <requestTokens> and the login token, I made use of another WebKDC interface that's been quietly lurking that we added for potential desktop single sign-on but which has otherwise been unused. You can use the <webkdcProxyTokenRequest> interface to do a Kerberos authentication to the WebKDC and get back a WebKDC proxy token. I modified login.fcgi to check whether it had forwarded credentials and, if so, use this interface to get a token first that it can pass into the WebKDC. This required adding some more interfaces on the Perl side, but it kept down the number of required changes to mod_webkdc itself. > For any WAS that does not require password authentication, we skip the > confirmation page if the user has been authenticated with a forwarded > TGT. This is to give our users a real single sign-on feeling. Closing > the Browser won't be too useful anyway - the page is accessible > immediately again with the credentials cached in the ticket cache of the > operating system --- unless the users have destroyed their ticket caches > manually. This is now a separate option ($BYPASS_CONFIRM), since you may want to enable it in other circumstances as well and there's nothing particularly special about delegated credentials that would mean the confirmation page shouldn't be displayed. Thank you very much for your work! And please let me know if you have any problems with 3.6.0. -- Russ Allbery <[EMAIL PROTECTED]> Technical Lead, ITS Unix Systems and Applications, Stanford University -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
