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@xxxxxxx> 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@xxxxxxxxxxx > > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev@xxxxxxxxxxx > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- / Alexander Bokovoy _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
