Kerberos outside the firewall

[Russ Allbery]

"Nordgren, Bryce L -FS" <bnordgren at fs.fed.us> writes:

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

It's completely routine to expose a SAML or OpenID identity provider to
the Internet at large, even assuming you're talking about the sort of
environment where the company isn't using "Google authentication" for a
ton of things anyway.

> There's been a fair amount of activity defining non-browser SASL
> workflows for OAuth and SAML. Close the loop: define a concise, logical,
> human-friendly way to express these foreign identities as Kerberos
> principals, define the effect on the transited path, define how to
> encode some subset of whatever attributes the remote source provides in
> the TGT, require some unspecified means of configuring permissible
> identity sources, and give that remote user a TGT for the local realm!
> If necessary, make a new KDC! service ("WebAS") leveraging these
> non-browser SASL workflows.

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.

What you're describing is essentially extending Kerberos to carry
authorization information.  I'm a bit dubious about that, if for no other
reason than that extending the size of Kerberos tickets causes various
problems, and there are lots of other, well-established authorization
systems these days.  So it's not clear why one would want to reinvent that
partiuclar set of wheels.

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

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>