michael at stroeder.com
Sat Jul 19 10:16:44 EDT 2008
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 principal at REALM 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 . 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.
More information about the Kerberos