>I didn't say SSO didn't work. Also didn't say LDAP was required for >Kerberos authentication to function. :)
Your EXACT words were: Kerberos is not a complete identity solution. You would also need to expose the LDAP p[ao]rt which parcels out a few user attributes (name, email, something like an SID or UID/GID...) Considering the context of the discussion was about authenticating via Kerberos across the Internet, at best this statement is misleading. >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." Meh. I'm not sure it's a peception of high maintenance (the maintenance of cross-realm trust is essentially zero). I get the feeling that the reasons are more due to a lack of understanding about Kerberos. The average AD administrator doesn't understand about Kerberos; they know that users authenticate to the AD domain controller, but they don't know what that means from a protocol persecptive. Combine that with the official guidance from Microsoft ... it's a hard sell to the average AD administrator. >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. Again, I think you're kind of missing the thrust of the discussion. The usual case is clients may be outside of your firewall, but the application servers (the ones that need access to LDAP or some other authorization service) are inside of your trust boundary. That's pretty straightforward, but again it would require Internet access to the domain controller, which is a non-starter for a lot of people. Note that this whole thing springs from the comments from MIT asking why people wouldn't want to expose their KDC to the Internet, since Kerberos was designed to solve the exact problem of authentication users over untrusted networks. I'm neutral about the new PKCROSS proposals; at a MINIMUM it will be 5 years before they become usable (I'm talking about the time it would take to go through the standards process, get implemented and supported in common software, etc). That's the best case, and to me that's a long time to wait. --Ken ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
