Renaming thread.
> Not sure what you mean by that; been doing cross-organization SSO for over
> 15 years with a wide variety of organizations; it works just fine.
>The specific implementation of Active Directory may require LDAP (or other
>protocol) access for Windows clients, but it is important to note that this is
>NOT a requirement for the Kerberos protocol in general.
I didn't say SSO didn't work. Also didn't say LDAP was required for Kerberos
authentication to function. :) I said Kerberos wasn't a good SSO solution,
mostly for the reasons given in [1] and [2]. Simply put, it is reasonable to
believe that cross-organizational Kerberos SSO hasn't caught on because, real
or perceived: "high maintenance is bad."
As to the other thing...I consider the absolute number one use case to be
providing identities for desktop logins to Linux/Windows/Mac (real and virtual
workstations as well as cluster machines). Number two use case would be
standing up a file server. Number three would be providing identities for
websites. All of the top three require additional user attributes, and not just
for authorization. Kerberos in isolation is a pretty esoteric edge case in an
enterprise environment. The question of why CIOs don't use Kerberos outside the
firewall is ill-formed, and needs to become: "Why don't CIOs use
Kerberos-containing identity solutions outside the firewall?" This makes
consideration of those "other" components valid.
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. My read of
this list is that this may be common to more than just my CIO. If the heart of
SSO is "no new passwords for users" rather than "my corporate identity
everywhere else", then the path forward might be establishing a process where
the local KDC can do initial authentication with a publicly exposed remote
identity provider. 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.
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.
Given a choice between solving the do-able technical problem and the
intractable people problem, the technical problem should win. :)
Bryce
[1] https://tools.ietf.org/html/draft-ietf-cat-kerberos-pk-cross-08
[2] https://tools.ietf.org/html/draft-williams-kitten-krb5-pkcross-03
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.
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
