Michael B Allen wrote: > > It's the client's responsibility to decide whether or not to include a > TGT. A client can always request a forwardable TGT in which case it > can be submitted to the web server. For example on Linux if you do > kinit -f [EMAIL PROTECTED] and then point Firefox at an SPNEGO protected > page, and it has network.negotiate-auth.delegation-uris set to the > target domain, it will send the TGT. > > However, if you're using Windows clients in an AD environment and the > HTTP service account has "Trusted for delegation" turned off, the TGT > will not be sent.
Ok. Thanks (also to Russ) for clarifying this. >> My goal when doing SSO for web applications is that I don't trust the >> web applications so much not to reveal the user's credentials. > > Your choices are based on necessity, not trust. If the web application > needs delegated credentials (e.g. to authenticate as the user with > another tier), then you need to send the TGT [1]. If the web app does > not need delegated credentials then configure your clients not to send > the TGT (in AD this means simply turning off the "Trusted for > delegation" flag on the HTTP service account). I have two scenarios: 1. One is using CAS with SPNEGO/Kerberos (see http://www.ja-sig.org/wiki/display/CASUM/SPNEGO) and fall-back to simple bind. In this scenario I don't want the browser to send the TGT. 2. I'm thinking about implementing SPNEGO/Kerberos in web2ldap to let the use bind via SASL/GSSAPI to the LDAP server (up to now a "local" TGT has to be present for this to work). For this I need the TGT. So I'm glad both is possible. Ciao, Michael. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
