Apteryx has our own IdentityServer that handles storing all login information for Apteryx. When you attempt to log in to Apteryx, user credentials are sent to the IdentityServer to confirm that the information used to log in matches up to the currently valid credentials in that Apteryx URL’s group of users. If it does not, then it does not allow you to log in. This IdentityServer is managed and owned by PlanetDDS/Apteryx in lieu of a customer-owned Identity Provider.
Where SSO Comes in to play is having our IdentityServer instead direct user authentication to a customer-owned Identity Provider/Server. Doing so allows the customer’s employees to sign in to our software using credentials managed by their IT team, providing a single account login that the employees of our customer need to remember and use to access multiple business applications that they use, including Apteryx. This enables the customer to maintain security through that one SSO system rather than having multiple systems that they need their users to manage credentials for. It also streamlines onboarding and offboarding processes for their IT organization.
At the time of writing this article, we have 2 Identity Providers that we can support.
The first being traditional ADFS Servers that are owned, supported, and managed by the customer’s IT organization. This includes the hardware.
The second being Google, which has a slightly different method of doing the same thing - providing the customer a single set of sign-on credentials. The big difference being that rather than the customer’s IT organization own, support, and maintain the hardware, it is instead all handled through Google’s systems and managed via cloud services by the IT team.
SAML - We do not have an open generic "SAML" integration. Only via Google SSO.
SAML is just the protocol used for a given user's claims/privileges. Apteryx's Google SSO integration works via configuration within the org's Google Workspace. So, a user goes to log in, Google popup shows, they log in, Google Workspaces validates a given user's claims/privileges, sends that information via SAML protocal to our identity server. That user then gets redirected to Apteryx with appropriate user privileges. So asking if we integrate via SAML is really only asking half the question.-
Lastly, this one is not currently on our Product roadmap or directly supported: Microsoft Entra ID (formerly known as Azure AD). Microsoft Entra ID is basically the same thing as Google SSO, just through Microsoft instead of Google.
Note: There is a method possible for using an ADFS Server to integrate Apteryx with Entra ID. This would integrate in XVSD the same way that Option #1 would on our side. This would need to be configured and supported by the customer’s IT.
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-fed-whatis
In order to configure the integration, the Planet DDS Implementations team needs to coordinate enabling and testing for new customers. For existing customers, we need to use a test site to enable and test with. Once testing is complete and successful, then you can coordinate a Go-Live date with the customer. Be aware that the customer needs to provide Change Management in the form of informing their staff of the change in login procedures.
Supporting Materials:
PDDS Enabling ADFS/SSO Integration
SSO/ADFS Customer Integration Steps
SSO/ADFS Troubleshooting