"Nordgren, Bryce L -FS" <bnordg...@fs.fed.us> writes: > I was actually proposing the opposite flow: use SAML or OAuth IdPs to > authenticate users to Kerberos (WebAS). :) If the user can successfully > authenticate to the AS using one of the SASL non-web SAML or OAuth > workflows, they should get a local TGT (provided the KDC is configured > for this).
I think this is working against the strengths of both systems. Kerberos is really good at authenticating users -- there are tons of programs and local tools for managing this, it's integrated with device login, and so forth. But it's bad at conveying attributes and authorization. SAML is great at conveying attributes about a user but completely punts on authentication, requiring that you provide some local auth mechanism (which often defaults to something crappy like passwords). 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. -- Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
