FR: Add support for SSSD to directly authenticate against OIDC servers

[JasonN3]

SSSD has had oidc_child for a little while now, but I don't see any documentation on how to use it. Can you please add some documentation about what configuration options are available?

[alexey-tikhonov]

How would you like to use 'oidc_child' outside of FreeIPA (where, IIRC, it is used as a helper by 'ipa-otpd')?

[JasonN3]

OIDC is a standard protocol and there are plenty of servers available. It would be great if sssd could support authenticating against OIDC servers without requiring FreeIPA.
Basically, what settings need to be put in /etc/sssd/sssd.conf so the machine can authenticate against OIDC?

[alexey-tikhonov]

OIDC is a standard protocol and there are plenty of servers available. It would be great if sssd could support authenticating against OIDC servers without requiring FreeIPA. Basically, what settings need to be put in /etc/sssd/sssd.conf so the machine can authenticate against OIDC?

This functionality might be considered for addition later, but currently it's not supported.
Currently no part of SSSD uses 'oidc_child' (no SSSD provider can authenticate against OIDC server on its own, without FreeIPA).

[JasonN3]

OIDC is a standard protocol and there are plenty of servers available. It would be great if sssd could support authenticating against OIDC servers without requiring FreeIPA. Basically, what settings need to be put in /etc/sssd/sssd.conf so the machine can authenticate against OIDC?

This functionality might be considered for addition later, but currently it's not supported. Currently no part of SSSD uses 'oidc_child' (no SSSD provider can authenticate against OIDC server on its own, without FreeIPA).

I'm fine with this being changed to a feature request for SSSD to support OIDC or I can submit a separate issue if you would prefer

[alexey-tikhonov]

I'm fine with this being changed to a feature request

Please feel free

[JasonN3]

I'm fine with this being changed to a feature request

Please feel free

Updated the title. So this is going to be more about getting SSSD to authenticate OIDC, which should hopefully include documenting it.

[giusepperagusa]

I second this: a generic client-side solution would be highly needed, the server-side part already having several cloud-based (EntraID, Auth0 etc.) and on-premises (Keycloak/RedHatSSO, Janssen/GluuFlex, Zitadel etc.) solutions, and implementing it in SSSD seems the only sensible strategy.
Please note that ideally authorization/identity-mapping (the "NSS part", versus the "PAM part" related to authentication) could be included too (using claims and/or reusing the SSSD algorithmic generation of UIDs/GIDs).

[frasmarco]

This is a very valuable enhancement for the Linux identity governance. Upvote this! Having a modern solution for authentication and authorization could open a great number of opportunities to refresh and modernize user experince on both the server and workstation scenarios.

[giusepperagusa]

This is a very valuable enhancement for the Linux identity governance. Upvote this! Having a modern solution for authentication and authorization could open a great number of opportunities to refresh and modernize user experince on both the server and workstation scenarios.

Indeed!
While researching a solution for modern authentication/authorization in Linux, I initially found some PAM/NSS modules, but all the projects I found are either of limited scope (limited to Azure cloud VMs or to Google Authenticator 2FA or so on) or unmaintained (2 years or so since last commit) or both:

• https://github.com/aad-for-linux
• https://github.com/zhaow-de/pam-keycloak-oidc
• https://github.com/salesforce/pam_oidc
• https://github.com/stfc/pam_oauth2_device
• https://codeberg.org/bergblau/webidamd

Then I realized that a modern approach would be to have this functionality inside SSSD, not directly as a PAM/NSS dedicated module, and so I ended up here :-)

Maybe some of the above sources could be used as a starting point to develop a complete SSD OIDC provider, but neither I am a programmer nor do I know the SSSD internals to judge the feasibility or effort of such a project.

But the sysadmin in me can easily see where this could lead: a Linux equivalent of a Cloud-joined server/workstation (and not public-cloud-join-only, but open to self-managed infrastructure too) and maybe, who knows, an open implementation of management policies will follow too (i.e.: a modern version of AD GPOs).

All of this seems absolutely in scope for SSSD and even needed to keep it relevant in a field where some incumbent solutions (AD, LDAP) are being more or less openly being regarded as "legacy" ;-)

[sumit-bose]

Hi,

jfyi, I'm currently working on generic IdP support for SSSD. I hope there will be something for you to test during the next months.

bye,
Sumit

[AndreasGocht]

Just for the sake of completeness, I like to mention a talk at Fosdem 2024 about this topic:

https://fosdem.org/2024/schedule/event/fosdem-2024-2587-posix-identities-out-of-oauth2-identity-providers-how-to-redesign-sssd-and-samba-/

I wonder if this is the work of @sumit-bose or someone else.

Best,

Andreas

[JasonN3]

@sumit-bose Any luck or progress? Anything I can do to assist? testing or anything else?

[sumit-bose]

Hi,

you can find packages for testing SSSD with Entra ID and Keycloak with some instructions at https://copr.fedorainfracloud.org/coprs/sbose/sssd-idp/

HTH

bye,
Sumit

[JasonN3]

Hi,

you can find packages for testing SSSD with Entra ID and Keycloak with some instructions at https://copr.fedorainfracloud.org/coprs/sbose/sssd-idp/

HTH

bye, Sumit

I gave it a try to see if I could replicate what you did in the video, but it doesn't seem to work. I gave it the app permission User.ReadBasic.All to get rid of the 403 errors when trying to look up a user. oidc_child.log now shows that all requests returned 200 and it logs my name according to Azure, so it was able to resolve the username. However, getent and id can't find the user. It's like the information isn't being passed from oidc_child back to nss.

I'm using Fedora 40, here's the sssd.conf, and I used authselect select sssd --force to enable sssd.
I also tried replacing https%3A%2F%2Fgraph.microsoft.com%2F.default with https://graph.microsoft.com/.default since I wasn't sure if that was an issue with how the page was rendering or if it needed to be url encoded.

sssd.conf

[sssd]
config_file_version = 2
services = nss, pam
domains = MY_DOMAIN

[domain/MY_DOMAIN]
id_provider = idp
auto_private_groups = true
use_fully_qualified_names = true
debug_level = 9
idp_client_id = CLIENT_ID
idp_client_secret = CLIENT_SECRET
idp_token_endpoint = https://login.microsoftonline.com/MY_ENDPOINT_UUID/oauth2/v2.0/token
idp_device_auth_endpoint = https://login.microsoftonline.com/MY_ENDPOINT_UUID/oauth2/v2.0/devicecode
idp_userinfo_endpoint = https://graph.microsoft.com/v1.0/me
idp_id_scope = https%3A%2F%2Fgraph.microsoft.com%2F.default
idp_auth_scope = openid profile email

[nss]
debug_level = 9
default_shell = /bin/bash
fallback_homedir = /home/%f