More auth options (Azure, RADIUS, SAML etc.)

Feature Requests Royal Server
1

Hi all,

I’d like to see more authentication and authorization options for Royal Server. Not just AD and its groups. It would be great to have an option to connect it to Azure AD or to RADIUS or to be able to utilize SAML or OAuth for other identity services and use their groups and their MFA capabilities for example.

Cheers,

Deworn

2

We would like to see this too. RADIUS would probably be the easiest to implement whilst supporting the largest amount of services. I know Duo, Okta and Jumpcloud all either support RADIUS or have a RADIUS connector

3

We need AD-SSO on Prem.
If Windows account is loged on, why not using this AD Session?

Providing the Windows Password within RoyalTS Client is a pain.

To store this securely, the application Doc has to be encrypted, with a password the user has to type in.

Thats painfull and users comlaining.

The will start storing complex passwords in txt doc to access RoyalTS Client.

4

Would also great from my side if there is a possible RADIUS-Auth…

5

We are/were considering Royal to replace Devolutions, but the lack of SAML/SSO was a show stopper. We like what we see so far, however…

6

Hi,

unfortunately there are a couple of technical obstacles which prevents us to implement a good SSO solution (including SAML support):

  • right now, the local group membership of Secure Gateway and Royal Server users is used to determine access to the Royal Server/Secure Gateway. Even though you can put a domain group into the Royal Server’s local group, it’s not really possible to verify group membership from the client. We could implement a new feature which allows you to configure the Royal Server to use a certain AD Group instead of the local group to circumvent that.

  • AFAIK there’s no APIs for the client side which makes it easy to submit a token/ticket in a secure and verifiable way which ensures the client has the current user successfully authenticated. If someone is aware of such APIs, let us know.

  • We also need to keep in mind non-windows scenarios for our macOS and mobile users. Even though one or the other scenario would be possible to implement, it would only be available on Windows.

  • A couple of workflows on the Royal Server (especially modules) are doing impersonation on the server. This means a logon will be performed on the server using the submitted credentials and code will be executed in this user context. AFAIK this is not possible any other secure way where tickets or tokens are passed on to the server.

If we could get the group membership/claims done on the client we might be able to pull off SSO for Secure Gateway and/or documents but this would be a huge effort.

Sorry for not having better news on that front.

Stefan

7

You should look at authentication and permissions seperately. Most applications that use SAML or OIDC simply create the User locally on first login and permissions are managed also locally from there on.

If you want to provision users beforehand, you could make use of SCIM, or simply make an “import user from Entra ID” button that gets the user info and creates the local user accordingly.

So it would be totally OK to let the authentication be handled by OIDC/SAML with Entra ID, create the user locally, and then let the admin assign permissions locally.

Also, limiting users from login to RoyalTS is done on the IdP side (Entra ID). So you dont have to worry about that on RoyalTS side.

Regarding APIs, check this on how OIDC works:

OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform | Microsoft Learn

8

To be honest, we are also on the lookout for a Devolutions alternative because of the constantly rising prices. And SSO is also a showstopper for us.

9

regarding SSO support and different authentication providers (like Radius, for example):

SSO is a very broad term and Royal TS as well as Royal Server provide access to many different services and features from different 1st and 3rd party vendors which may or may not support SSO.

To better understand the requirements we would need a detailed description of scenarios, involved products and integrations to look at and find out if there’s even a way to support this on a technical level. It would also help to send us products which do support your scenarios to help us understand what kind of SSO support you are looking for.

As an example: RDP using the Microsoft ActiveX control supports SSO by passing on the current user of the local desktop session to sign you in to the remote desktop session. PuTTY, for example, does not support that.

If you can provide us more details, we can definitely look into it.

10

Its not SSO through to the RDP-Client I am talking about, but SSO with Entra ID (preferrably OIDC) login into RoyalTS/RoyalServer/RoyalPasswords.

Devolutions Products are a good example here. Login to Remote Desktop Manager, Devolutions Password Server, and the Devolutions Workspace Browser Addon all support OIDC login with EntraID.

11

It’s still not 100% clear to me how you imagine the workflow. The way it works now is like this:

  • open the client (Royal TS/X)

  • open a document and provide a password if it is password protected

  • the document contains a Royal Server object with credentials for the Royal Server

  • other documents and gateway connections can be established through the Royal Server object and the credentials assigned to it

Can you outline the flow you have in mind?

12

Since I am not 100% sure how royal ts and royal server work, here is how it works in devolutions.

Remote Desktop Manager has a datasource, in this case a Devolutions Password Server.

When I open RDM, i have to authenticate against the datasource, in this case the DPS with my Entra ID credentials.

After that I am connected and can access all Vaults, Documents, Hosts, Services I have permissions to.

Is there any way to get a trial version of RoyalTS and Server?

13

Sure, you can request a trial here:
https://royalapps.com/trial/

I guess the datasource in Remote Desktop Manager is something similar than the document. Right now, the documents can only be password protected. There’s no notion of a user/role or “log on” in any way right now. We do have plans to extend the document in a way where we can have users to log in with different permissions. Once we have that, we can probably also support authentication using Entra ID.

14

Hi Stefan,

Just to add a bit of context how we use Royal Server currently, and how we would see SSO/SAML/OIDC working in our use case.

Currently

  • Engineers use their Active Directory (AD) user credentials to authenticate against the Royal Server
  • On the Royal Server we use AD groups for ACLs on the documents
  • The DUO MFA authentication method is used and engineers get a MFA prompt on their secondary devices
  • Once approved, they are required to enter the document password (for encryption purposes)

How we’d like it to work

  • The Royal Server is not bound to Active Directory, and instead, users authenticate via our IDP through SAML/OIDC/etc
  • Document ACLs can be configured to allow certain SAML/IDP groups access to them
  • MFA no longer needs to be enforced by Royal, as the IDP can do this and is the only permitted login route to the Royal Server
  • Engineers would still need to enter the document password to decrypt the document

Best,
Ryan

15

Hi, I found this topic as we are currently in the same situation. Is there any update on this feature request as I would love the possibility to authenticate via Entra ID so that we don’t need local users as we do not have a local domain anymore. I’m grateful for any update in this topic - thank you :slight_smile: