With a move to cloud-based hosting of the application servers, a typical application is not a member of the same corporate IT environment anymore. Application servers often use OAuth 2.0 protocol flows to identify their users. Identity Providers (IdPs) provide OAuth 2.0 endpoints to applications and pull over the tasks of authenticating and authorizing users’ access to application resources. They become a central point of interaction between enterprise domains, if those still in use in the organization, and applications. This approach allows to integrate both in-house applications and cloud-based SaaS applications provided by third parties.

The separation of enterprise IT architecture and an enterprise domain structure, however, leads to a larger issue. While in the past management of the application servers was part of the enterprise domain services (Active Directory, RHEL IdM, …) where regular users and application developers were present at the same time. Maintaining common access to these servers was easy: since the application server is enrolled into the domain, it can consume domain identities. Not anymore: there is no such guarantee to have both application servers and application developers belonging to the same domain. Effectively, there is a need to access information that is only available in a federated way: through some broker, like IdP. On top of that, the broker might not be able to pass through a certain type of information that might simply not exist on the other side. For example, for Linux servers working together as a compute capacity, it is crucial to have a uniform view on POSIX information about users and groups. But an IdP might simply lack this information because there might be no need for it at the place where a user account is defined.

This talk aims to define a common set of requirements and approaches to represent a secure POSIX identity management integration with OAuth 2.0-based identity providers. Aside from requirements towards client software on the Linux platform, we aim to define possible requirements towards other components of the integration, based on our experience developing Samba, SSSD, and FreeIPA for more than 25 years.