[36648] in Kerberos
Re: Kerberos outside the firewall
daemon@ATHENA.MIT.EDU (Russ Allbery)
Mon Dec 1 18:17:25 2014
From: Russ Allbery <eagle@eyrie.org>
To: "Nordgren\, Bryce L -FS" <bnordgren@fs.fed.us>
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E75CBAA@001FSN2MPN1-044.001f.mgd2.msft.net>
(Bryce L. Nordgren's message of "Mon, 1 Dec 2014 22:58:45 +0000")
Date: Mon, 01 Dec 2014 15:17:10 -0800
Message-ID: <87fvczkljd.fsf@hope.eyrie.org>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
"Nordgren, Bryce L -FS" <bnordgren@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 (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
