Authentication using federated identity

[Alexander Bokovoy]

On Пят, 09 лют 2024, Falcon Darkstar Momot wrote:
> Practically speaking, most popular IAM and SSO solutions offer OIDC SAML
> tokens but do not offer Kerberos tickets.  OpenID Connect is a standard
> which itself is based on RFC6749 (OAuth2). This provides a compelling reason
> to support it in addition to Kerberos.  I'll also note that OIDC tokens are
> easy to validate without a bidirectional trust relationship between the IdP
> and RP.

In FreeIPA we support issuing Kerberos tickets with user authentication
being handled by an OAuth2 IdP and access authorized via device
authorization grant flow. You'd get a Kerberos TGT ticket that will have
'idp' authentication indicator and this ticket can be used against 
GSSAPI-enabled service, including SSH servers. If your service
understands authentication indicators, then you can limit access on the
service side as well.

> 
> SSH authentication via OAuth2, in particular, would save complexity at most
> organizations I've worked with.  All of them so far have preferred things
> like automated SSH certificate signers or APIs that cause orchestration to
> add SSH keys to authorized_keys on hosts, before they implement Kerberos
> just for this.
> 
> On top of that, Active Directory is a legacy solution now.  Its successor
> uses OAuth2.
> 
> On 2024-02-08 23:49, Nico Kadel-Garcia wrote:
> > On Thu, Feb 8, 2024 at 1:18 PM Chris Rapier <rapier at psc.edu> wrote:
> > > I know that there are some methods to use federated identities (e.g.
> > > OAuth2) with SSH authentication but, from what I've seen, they largely
> > > seem clunky and require users to interact with web browsers to get one
> > > time tokens. Which is sort of acceptable for occasional logins but
> > > doesn't work with automated/scripted actions.
> > Is there some reason you wouldn't simply use Kerberos, baked into
> > Samba and Active Directory, with the long established token handling
> > provided by Kerberos? Convincing Kerbers and the AD admin who may not
> > realize they have it to permit that underlying authentication
> > technology, but it's been stable for decades  Part of the difficulty
> > seems to be every bureaucracy's desire to have their own special rules
> > and not talk to each other without a lot of Gant charts and big
> > picture diagrams, but I've been taking advantage of the underlying
> > Kerberos behind the backs of AD admin for decades.
> > 
> > Unfortunately, everyone seems to want to have their own "invented
> > here" form of authentication token handling, rather than sticking with
> > basics. My old classmates at MIT worked *very hard* to make that work,
> > and to resist abuse, and it still works quite well.
> > 
> > 
> > > I'm just wondering if anyone has done any work on this or has thoughts
> > > on it. I know it would be useful in some contexts (in my case, cross
> > > realm access of independent yet federated services that are pretty
> > > common in R&E HPC communities (e.g. ACCESS)).
> > > 
> > > Chris
> > > _______________________________________________
> > > openssh-unix-dev mailing list
> > > openssh-unix-dev at mindrot.org
> > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
/ Alexander Bokovoy