"Nordgren, Bryce L -FS" <bnordg...@fs.fed.us> writes: > Again we return to the start: a lack of exposed Kerberos identities. The > point of the suggestion was to make a bevy identities available to the > top use cases for Kerberos: desktop/workstation logins and > fileservers. SAML and OAuth are incompatible with this purpose, but > that's where the available identities are.
But desktop/workstation logins and fileservers are generally *also* not allowed outside of a VPN, so I don't understand what you're gaining. The resource to which you're trying to authenticate is likely to be even more restricted than access to the Kerberos KDC because it's more vulnerable to attack. I'm pretty sure there are a lot more attacks on CIFS/SMB than there are on Kerberos; the exposed protocol is far more complex. > You'd likely only be using this method for remote identities, when > Kerberos IDs are not exposed. And you're likely only doing this out in > the DMZ, where you're supposed to be working with others. Is manually > creating an account for the remote user and emailing them a password > really better than just leveraging an existing authentication source? > Hiring someone to deliver the password by phone? If management is willing to expose a Kerberos-authenticated file server to the Internet but not a Kerberos KDC to authenticate to that file server, but *is* willing to expose some sort of authentication mechanism probably built with passwords on top of SAML to the Internet and maintain some complicated bridge to use that for file service and expose *that* to the Internet... that management is so utterly confused about security and authentication that I really can't predict what sort of nonsense they'd be willing to do. :) If you're just looking for a collaborative file store outside of the firewall and local restricted network environment because it's used for collaboration with third parties, there are a wealth of cloud storage providers that support exactly that use case and are willing to use SAML identities or OpenID or other methods of identity that you're probably already exposing. For an environment that isn't willing to expose Kerberos but does want to have collaborative, authenticated public file stores, that's the route I personally would recommend. (Full disclaimer: I now work for one of those companies, but I believe I would have made the same recommendation six months ago before I took a job there.) Personally, I think you should just expose the Kerberos KDC to the Internet and use AFS for shared file service, but I suspect the chances of getting management to understand the merits of that approach are low. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
