Re: SSO - Kerberos

This is a discussion on Re: SSO - Kerberos ; On Thu, Jul 17, 2008 at 6:46 PM, Russ Allbery wrote: >> And that is the scenario where direct SPNEGO / NTLMSSP solutions are >> going to perform better. > > If by "better" you mean "pretty much the same," ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Re: SSO

  1. Re: SSO

    On Thu, Jul 17, 2008 at 6:46 PM, Russ Allbery wrote:
    >> And that is the scenario where direct SPNEGO / NTLMSSP solutions are
    >> going to perform better.

    >
    > If by "better" you mean "pretty much the same," yes, modulo the
    > configuration note that I mentioned.


    No, I definitely meant "better".

    With direct SPNEGO we 401 the initial HTTP request, accept one GSSAPI
    token and get a TGT.

    With something like WebAuth, the client is redirected to a central
    server, then you have to do all of the above (or an explicit login
    which is more stuff) and then redirect the client back to the original
    target (and this doesn't include getting a TGT on the target server).

    With Plexcel we can do SPNEGO, check group membership (we extract the
    group SIDs from the PAC), app-level access to basic user info and a
    get TGT without talking to a third party at all. The time between the
    initial HTTP request and the 200 response is less than 20 ms (or ~50
    ms if the user is in a few hundred groups).

    Mike

    --
    Michael B Allen
    PHP Active Directory SPNEGO SSO
    http://www.ioplex.com/

  2. Re: SSO

    Michael B Allen wrote:
    > On Thu, Jul 17, 2008 at 6:46 PM, Russ Allbery wrote:
    >>> And that is the scenario where direct SPNEGO / NTLMSSP solutions are
    >>> going to perform better.

    >> If by "better" you mean "pretty much the same," yes, modulo the
    >> configuration note that I mentioned.

    >
    > No, I definitely meant "better".
    >
    > With direct SPNEGO we 401 the initial HTTP request, accept one GSSAPI
    > token and get a TGT.


    Is the TGT sent by the browser in the SPNEGO blob? Up to now I thought
    it's just a service ticket.

    Ciao, Michael.

  3. Re: SSO


    On 18 Jul 2008, at 12:13, Michael Ströder wrote:
    > Is the TGT sent by the browser in the SPNEGO blob? Up to now I thought
    > it's just a service ticket.


    SPNEGO is a GSSAPI mechanism, wrapping the Kerberos one. If you set
    the deleg_creds flag when calling into the API, then a TGT will be
    included.

    S.



  4. Re: SSO

    On Fri, Jul 18, 2008 at 7:13 AM, Michael Ströder wrote:
    > Michael B Allen wrote:
    >> On Thu, Jul 17, 2008 at 6:46 PM, Russ Allbery wrote:
    >>>> And that is the scenario where direct SPNEGO / NTLMSSP solutions are
    >>>> going to perform better.
    >>> If by "better" you mean "pretty much the same," yes, modulo the
    >>> configuration note that I mentioned.

    >>
    >> No, I definitely meant "better".
    >>
    >> With direct SPNEGO we 401 the initial HTTP request, accept one GSSAPI
    >> token and get a TGT.

    >
    > Is the TGT sent by the browser in the SPNEGO blob? Up to now I thought
    > it's just a service ticket.


    Yes, the relevant SPNEGO token is basically a wrapped AP-REQ wihch is
    composed of a service ticket and an authenticator. I believe the TGT
    or what is used to build a TGT is in the authenticator (at least
    that's what WireShark calls it). Incidentally the encrypted part of
    the service ticket contains the authorization data (the PAC if it was
    issued by AD) which I assume is combined with the TGT data in the
    authenticator to build a TGT with authorization data. Otherwise it
    would have to dupe that data and the size of blobs in the SPNEGO token
    doesn't represent that.

    Mike

    --
    Michael B Allen
    PHP Active Directory SPNEGO SSO
    http://www.ioplex.com/


  5. Re: SSO

    Simon Wilkinson wrote:
    >
    > On 18 Jul 2008, at 12:13, Michael Ströder wrote:
    >> Is the TGT sent by the browser in the SPNEGO blob? Up to now I thought
    >> it's just a service ticket.

    >
    > SPNEGO is a GSSAPI mechanism, wrapping the Kerberos one. If you set the
    > deleg_creds flag when calling into the API, then a TGT will be included.


    Which entity has to set this flag when calling into the API? The web
    browser or the web server?

    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.

    Ciao, Michael.

  6. Re: SSO

    Michael Ströder writes:

    > Is the TGT sent by the browser in the SPNEGO blob? Up to now I thought
    > it's just a service ticket.


    It's optional. The browser can choose to delegate credentials or not,
    based on local configuration. (In Firefox, for example, it's two separate
    configuration options.)

    --
    Russ Allbery (rra@stanford.edu)


  7. Re: SSO

    On Fri, Jul 18, 2008 at 12:03 PM, Michael Ströder wrote:
    > Simon Wilkinson wrote:
    >>
    >> On 18 Jul 2008, at 12:13, Michael Ströder wrote:
    >>> Is the TGT sent by the browser in the SPNEGO blob? Up to now I thought
    >>> it's just a service ticket.

    >>
    >> SPNEGO is a GSSAPI mechanism, wrapping the Kerberos one. If you set the
    >> deleg_creds flag when calling into the API, then a TGT will be included.

    >
    > Which entity has to set this flag when calling into the API? The web
    > browser or the web server?


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

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

    Mike

    [1] Kerberos provides other ways to limit how the TGT can be used and
    to proxy service tickets and such but I don't think browsers have
    support for such things yet.

    --
    Michael B Allen
    PHP Active Directory SPNEGO SSO
    http://www.ioplex.com/


  8. Re: SSO

    "Michael B Allen" writes:

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


    Unless you use a system such as WebAuth or Cosign that supports limited
    delegation, in which case you can send only exactly the credentials that
    the web application needs.

    > [1] Kerberos provides other ways to limit how the TGT can be used and to
    > proxy service tickets and such but I don't think browsers have support
    > for such things yet.


    They don't so far as I know. Delegation in all the current browsers is an
    all-or-nothing affair.

    --
    Russ Allbery (rra@stanford.edu)

  9. Re: SSO

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

  10. Re: SSO



    Michael B Allen wrote:
    > On Fri, Jul 18, 2008 at 12:03 PM, Michael Ströder wrote:
    >> Simon Wilkinson wrote:
    >>> On 18 Jul 2008, at 12:13, Michael Ströder wrote:
    >>>> Is the TGT sent by the browser in the SPNEGO blob? Up to now I thought
    >>>> it's just a service ticket.
    >>> SPNEGO is a GSSAPI mechanism, wrapping the Kerberos one. If you set the
    >>> deleg_creds flag when calling into the API, then a TGT will be included.

    >> Which entity has to set this flag when calling into the API? The web
    >> browser or the web server?

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


    Just to clarify, A Windows KDC will set the OK-AS-DELEGATE flag in the
    Kerberos flags in the service ticket if the TRUSTED_FOR_DELEGATION
    UserAccountControl glag is set for the service account. This is advisory
    to the client. But the bit was introduced in Windows first. I have seen
    mods to the MIT Kerberos to set this bit and mods in the client to check
    if it is set.

    Unfortunately the client needs to know if the KDC has implemented the
    code to set the bit or not, because the default for the bit is off,
    and non windows clients have always assumed delegation was OK. (The bit
    should have been NOT-OK-AS-DELEGATE, It would have made introduction of the
    feature much cleaner.)

    A client using any protocol, should always be very cautious in delegating,
    as a delegated TGT is usually as good as the one you get with login or kinit.
    SSH has the ssh_config "GSSAPIDelegateCredentials yes" to control delegation.

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


    Have you looked at the Sun Access Manager?
    http://www.sun.com/software/products..._mgr/index.jsp
    Or other SSO products?

    >
    > 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).
    >
    > Mike
    >
    > [1] Kerberos provides other ways to limit how the TGT can be used and
    > to proxy service tickets and such but I don't think browsers have
    > support for such things yet.


    Too bad, limiting the capabilities of delegated credentials is one of the
    areas Kerberos implantations need improvement. It is one of the reasons
    Kerberos will not scale well across organization boundaries and makes site
    security nervous. The OK-AD-DELEGATE is a step, but its all or nothing.

    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444

+ Reply to Thread