Kerberos outside the firewall

[Nordgren, Bryce L -FS]

> > In the spirit of choosing our battles wisely, I sense that convincing
> > my CIO to expose corporate identities to the internet is certainly a loser.
>
> Given that you cannot outsource any IT service without doing this, my
> experience is that CIOs are not only willing but eager to find ways of exposing
> corporate identities to the Internet.  It's more that this is almost entirely to
> authenticate to web applications such as Salesforce, and that's why Kerberos
> is not very interesting, not because it's the Internet.  All that stuff these days
> is based on either SAML or OpenID.

I need to refine then: Convincing my CIO to expose corporate Kerberos IDs is a loser. My CIO has operated a public facing SAML IdP since 2006-7 or so. The original question was asked because of an observed recalcitrance concerning the exposure of Kerberos IDs. To clarify, have you observed an eagerness on the part of CIOs to expose Kerberos IDs?

> I think the biggest problem with this approach is that most SAML
> authentications aren't based on an identity, at least solely.  Rather, they're
> based on some sort of attribute set, probably best thought of as roles.  SAML
> carries a bunch of attributes, such as whether the person is an employee,
> whether they should have access to this application or that one, and so on.
> In other words, it's both an authorization and an authentication system,
> whereas Kerberos provides only the authentication component.

It's easy to discard information. If it doesn't belong in Kerberos, don't include it in the ticket. Remote roles are likely not useful in a local environment anyway. Things typically used for authorization (UidNumber) are particularly prone to collision if one is foolish enough to directly leverage that attribute in the local realm. Useful attributes describe the human (name/GECOS, email, etc.). If there's a way to package this useful data in the TGT, great. Otherwise, let the larger identity solution handle it. (This does imply that the server API would need an interface for people to write an "attribute inspector", so that interesting-but-not-for-Kerberos data can be captured.)


> > Collaboration related machines and apps can get corralled into the
> > DMZ, get their own Kerberos realm and WebAS enabled KDC (and attribute
> > provider). The totally separate, not-trusted, DMZ-residing KDC can be
> > the thing which leverages WebSSO. Corporate IDs can stay islanded
> > inside the firewall.
>
> And this is the approach that we took at Stanford, and that I think is fairly
> common: Kerberos is the internal authentication mechanism, and is used to
> authenticate our users to the identity providers for things like SAML.
> Information exchange with trusted third parties is done via protocols like
> SAML that can carry a richer set of information.

I was actually proposing the opposite flow: use SAML or OAuth IdPs to authenticate users to Kerberos (WebAS). :) If the user can successfully authenticate to the AS using one of the SASL non-web SAML or OAuth workflows, they should get a local TGT (provided the KDC is configured for this).

All we'd be changing is the need for a shared secret between the user and the KDC. The principal name can reflect the fact that the client does not originate in the local realm. Operationally, this gives the local realm access to identities in the SSO ecosystems which can fairly be described as "thriving"; reduces the number of accounts one has to create for external partners; and avoids the people problem of trying to convince admins to expose Kerberos identities.

Bryce





This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.