SSO

[Michael Ströder]

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 [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.