Contents
Signing in to a governance tool with a corporate account looks like a convenience at first glance: one less password to remember. Its real value is on the security side. A governance tool is where who approved what is recorded; if the question of who got in is answered wrongly, the rest of the record loses its value too. This article covers four decisions: the password, the role, the leaver and the emergency account.
Where the Password Should Live
The answer: only at the identity provider. The user presses the button, the browser goes to the identity provider's own page, the password and the second step are typed there, and the user returns to the product with a signed answer. The product verifies that answer; the password never touches the product. So there is no password in the product to steal, no reset flow to forget, and no separate place to manage the second factor. The organisation manages the second step in its own system under its own policy.
Where the Role Should Come From
Authenticating tells who the person is; it does not say what they may do. The healthiest method is to assign the role from a group in the identity provider: IT adds the person to the 'DBA Team' group and the product grants the role; remove them from the group and the access drops. Three rules make this mapping safe. If several groups match, the highest role wins. If no group matches, the person does not get in, and is not quietly admitted with low privileges. And the most privileged role, the system manager, is never granted by a group mapping. Otherwise a group edit in the identity system could hand out the product's most privileged role, tying the administrators of two separate systems into a chain of privilege that neither can see. An organisation that prefers to manage roles by hand can turn the mapping off.
When a Leaver Is Closed Out
When a corporate account is closed in the identity system, no new session can be opened. But what if a session is already open? Access tokens stay valid for a while and in most systems access effectively continues for that time. The right behaviour is that closing a user's sessions on the product side both revokes the refresh tokens and makes the access token still in hand be rejected on the next request. The session should not be left to expire on its own. There can be two different speeds for closing an account between the identity system and the product; the question to ask when evaluating is how quickly a revocation on the product's own side takes effect.
What the Door Does When the Identity System Goes Down
A governance tool that depends only on the identity provider locks up when the identity provider goes down. Being unable to reach the governance tool while there is a fire in production is the worst design outcome for the tool. That is why a local emergency sign in should exist. But that door cannot be allowed to stay silent: signing in with a local password while SSO is on should appear in the audit trail not as an ordinary sign in but as a separate event, and go to the SOC as an alarm. That way the question of whether the emergency account is really used in an emergency is answered on a single line each morning. Likewise, a forged or replayed identity answer coming from the identity provider should reach the SOC regardless of the filter.
OpenID Connect or SAML
Both do the same job: they carry the identity provider's signed answer to the product. OpenID Connect works through the authorization code flow with PKCE; Entra ID, Keycloak and Okta speak it. SAML 2.0 returns over HTTP-POST; AD FS, Entra ID and Keycloak speak it. The organisation's choice usually depends on what the existing identity system supports better. What matters is that the product supports both and that more than one provider can be defined at once; a misconfigured provider should not be used and should not affect the others or local sign in.
Six Questions When Evaluating a Product
- Does the password ever reach the product, or does it stay only at the identity provider?
- If several groups match which role wins, and what happens if none does?
- Can the most privileged role be granted by a group mapping?
- When a user's sessions are closed, when does the access token still in hand stop working?
- If the identity system goes down is there a way into the product, and what reaches the record and the SOC when it is used?
- Does a misconfigured provider affect the others or local sign in?
The first three questions show where authority comes from; the last three show when and how it is taken back. If a product cannot answer the second group clearly, corporate sign in stays a convenience and nothing more.
On the SQL Change Guard side
OpenID Connect (authorization code flow with PKCE) and SAML 2.0 (HTTP-POST) are supported and more than one provider can be defined at once. The password never reaches the product. The product role can be assigned from the group in the identity provider: if several groups match the highest role wins, if none matches the person does not get in, and the system manager role is never granted by any mapping. An organisation that prefers to manage roles by hand can turn the mapping off. When a user's sessions are closed on the product side, the access token still in hand is also rejected on the next request. Signing in with a local password while SSO is on is written as a separate event and goes to the SOC as an alarm. OpenID Connect and SAML were verified end to end against a local Keycloak and with automated tests; setup steps for Entra ID and AD FS are ready and we verify them with you against your own tenant at first setup. See the integrations page for details.
Frequently Asked Questions
Can you sign in to a database governance tool with Entra ID or AD FS?
Yes. OpenID Connect and SAML 2.0 are supported and the product is designed to work with identity providers such as Entra ID, AD FS, Keycloak and Okta. The user types the password on the identity provider's page and the password never reaches the product. It was verified end to end against a local Keycloak; setup steps for Entra ID and AD FS are ready and we verify them with you against your own tenant at first setup.
Should administrator rights come from a group under SSO?
No. The product role can be assigned from a group in the identity provider, but the system manager role is never granted by any mapping. Even if it is written into a group mapping it is ignored. That way a group change in the identity system cannot quietly hand out the product's most privileged role.
What happens if someone signs in with a local account while SSO is on?
They can sign in, because if the identity system goes down the product's door should not close with it. But it is an emergency sign in: in addition to the normal sign in record a separate event is written and it goes to the SOC as an alarm. The auditor sees 'who signed in locally while SSO was on' on a single line.