Rethinking Authentication with Hybrid Single Sign-On Access

This is a series of blogs about Delphix’s SaaS-based Central Management offering. If you are new to Central Management or would like a refresher, check out the introduction here.

Central Management rethinks the way that authentication happens with Delphix. If you’re a current user of Delphix Virtualization or Delphix Masking, this new capability will dramatically simplify the process of authenticating your users and automated processes. The mechanisms for authenticating humans and processes are different, so let’s discuss each separately.

User Authentication

Without Central Management, user (human) access to your Delphix engines can be authenticated by one of three methods:

• Local users: Engines have a username (e.g. user1) and a password (which is stored in hashed format). This is not recommended except as a fall-back.

• LDAP/Active Directory: Users will authenticate against an external directory service.

• Single Sign-On (SSO): Users will authenticate against an external Identity Provider (IdP)

Notably, each of the three is configured per engine, meaning that users must be set up on each engine and that each engine must both authenticate every user upon access as well as maintain connections to individual authentication services. While this may be adequate when deploying one to two Delphix engines, user management can become quite burdensome when scaling. The proliferation of different authentication mechanisms/setup for each engine can become a nightmare in the case of an audit.

How authentication works in absence of Central Management.

With Central Management, authentication is handled at a single point via integration with an IdP (e.g. Okta, Azure AD). Once authorized to access Delphix, users (again, humans) authenticate with their IdP and seamlessly access Delphix Central Management. By enabling single sign-on (SSO) powered by the IdPs our customers already use, we both create a more enjoyable experience for the end-user as well as provide industry-best secure authentication.

Engines connected to Central Management. Once an engine is connected, authentication is handled via Central Management, so authentication does not need to be set up on a per-engine basis nor do users have to reauthenticate per engine.

Engines are registered with Central Management, forming a hybrid system with engines close to the data and management being run in the cloud by Delphix. When these engines are registered with Central Management, Central Management tracks the permissions of users on each engine and will allow seamless access to the engines on which each user has access. For example, if the user “delphix_user_two” has access to two virtualization engines and one masking engine but not the other five masking engines, they will be able to automatically access those first three engines simply by clicking a link in Central Management and will not have to authenticate a second time.

Engines continue to exist wherever they are needed, but when connected to Central Management, authentication is centralized.

Automated Processes, APIs and API Keys

As discussed above, we’ve introduced single sign-on via common Identity Providers for human authentication. That does, however, beg the question of how to handle machine- or process-based authentication. If you use the APIs with Delphix Virtualization or Masking engines today, you know that we’ve orchestrated these products with an API-first design strategy. All new features start as APIs first, and once they’ve matured, they are added to the UI. The authentication for these APIs is done with the same username and passwords that are used for user-based authentication.

This approach changes as we’re moving away from support for usernames and passwords across the product line. We have industry-standard API keys, generated by Central Management and used with each engine. These keys can be generated by both standard and administrative users, but in both cases, there must be a properly authorized account on each engine.

An example of a client ID and secret generated as part of an API key.

Generating a key will yield a client ID and a client secret. The secret, as you’d expect, is the protected credential needed to access the engines. Note that you can actually have more than one client ID and Secret per key to be able to rotate keys as needed.

Once the key is generated, the client ID and client secret can be used to authenticate with any Delphix engine on which there is an associated authorized user, which means there’s no longer a need to set up specific accounts on a per engine basis!

Closing Thoughts

Finally, we’re also evaluating a number of similar projects that we’d love to get feedback on.

• Simplifying the creation of users across Delphix and providing group/attribute support.

• There’s a third leg to this strategy, which involves eliminating usernames and passwords to access hosts and databases. We’re currently working with popular secret management vendors to bring this functionality to you.

• Much like Delphix Virtualization and Delphix Masking, Central Management is built on top of REST APIs. We’ve released the UI version of Central Management and are in the process of hardening the public APIs.

If you’d like to participate in the design and testing of any of these projects or just want to tell us what you’d like to see, please reach out to your customer success representative for more.