Generic OIDC/SAML client for SSO login

Hi @micheleschelfi,

Thank you for reaching out, it is not currently planned to support generic OIDC/SAML SSO in Devolutions Server but we have received the request previously. If you may disclose, which identity provider do you use? We might have more chances of supporting that specific provider than a generic one.

Cheers,

Hi @micheleschelfi,

Thank you for reaching out, it is not currently planned to support generic OIDC/SAML SSO in Devolutions Server but we have received the request previously. If you may disclose, which identity provider do you use? We might have more chances of supporting that specific provider than a generic one.

Cheers,

Hi @Luc Fauvel, thank you for explaination

We are currently using Keycloak (RHBK), which supports both OIDC and SAML

Thanks

I want to upvote this feature, we are also heavily interested in a generic SAML/OIDC, currently running both Keycloak and Authentik.

Upvote!

We have the same use-case for Devolutions Password Server. Corporate policy does not allow us to use remote authentication services like Entra ID, Ping or Okta. We use an on-premise IDP based on SimpleSAMLphp.

We might have more chances of supporting that specific provider than a generic one.

@Luc Fauvel With all due respect, but I strongly disagree here.

SAML and OIDC are open standards and should work generically on any Identity Provider. What Microsoft and Ping are doing here by requiring a tenant-id or environment-id is a way for them to deliver an all-in-one experience that also does user (de-)provisioning between their identity store and Devolutions. This is probably great for Small and Medium Enterprises, but it results in a lock-in with big tech if that's all the flavours you support. From an enterprise-grade piece of software, I expect to be able to split authentication (using SAML 2.0 or OIDC) from user (de-)provisioning using SCIM. Large enterprise organizations usually split this across several systems/teams.

Kind regards,

Tim van Dijen

Hi @timdijen,

I understand your point, having myself contributed to similar specifications and implemented both SAML and OIDC in our products.

However from a product standpoint, we tend to want to offer guided experiences for administrators less familiar with these specifications, hence why we prefer to offer provider-specific options. It is not out of the question for us to implement generic IdP support, but we still would need to have proper documentation, inform our support staff how to help customers with these implementations and all the other work that goes into properly offering enterprise grade support.

Hope that helps and we’ll note your added interest for generic IdP support.

It is not out of the question for us to implement generic IdP support, but we still would need to have proper documentation, inform our support staff how to help customers with these implementations and all the other work that goes into properly offering enterprise grade support.

Hope that helps and we’ll note your added interest for generic IdP support.

@Luc Fauvel First of all, thanks for the incredibly fast reply!

Point taken! I understand it's an advanced use-case.

Please add SCIM to that list as well, because that's probably what Entra's Graph API is being used for to (de-)provision users. That's not usually a task for an IdP/Authentication server.

+1 from us! We’d also like a generic OIDC/SAML option for SSO between RDM and Devolutions Server.

Our company needs a solution that works with our existing identity provider, without being tied to specific platforms like Okta or PingOne. User and group import/synchronization would be a big plus too.

Would love to see this added in a future release!

@micheleschelfi

As Devolutions Server is able to run on Linux or Docker with a Postgres backend it would make sense to also start supporting other IdP's next to EntraID, Octa and PingOne like KeyCLoak and Authentik

Please add support for this as we do not want to be bound to using specific IdP's.