> So using Kerberos for authorization and SAML for authentication is really > unintuitive to me, and I think is maximizing your pain levels. :) Whereas > using > Kerberos for authentication and then exposing that information via SAML is > well-trod ground.
I'm not certain where using Kerberos for authorization came into this. :) Can we just agree not to do it and stop talking of it? 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. 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? 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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
