Single Sign-On: Bring Your Own Identity Provider

Single sign-on has arrived in AI Rule Engine. Organization members authenticate against your own identity provider instead of a personal Google, Microsoft, or LinkedIn account, which means your security team gets what it actually asks for: one place where identity lives, one place where MFA policy is enforced, and one place where an offboarded employee loses access.

That last part is the one that matters most in practice. When someone leaves, disabling them in your directory removes their path into the rule engine too. No hunting for which personal account was attached to which seat, and no shared logins nobody wants to admit exist. SSO is an Enterprise-plan feature and is configured by an organization admin.

Two protocols, your choice

Both OpenID Connect and SAML 2.0 are supported, and you pick whichever your identity provider does well. Entra ID, Okta, AD FS, Shibboleth, Ping, Auth0, and anything else that speaks either protocol will work.

There is no preferred vendor here and no single-provider integration wearing the label “SSO.” You configure the protocol, the app tells you exactly which URLs to hand your provider, and you are done. If you migrate providers later, the domain you claimed stays claimed; only the connection details change.

Claiming and verifying a domain

SSO starts with proving you own the email domain your people sign in with. In the SSO admin screen you add a domain such as contoso.com, and the app shows you a DNS TXT record to publish:

_ruleengine-verification.contoso.com

The value to publish is shown on screen ready to copy. Add it at your DNS provider, come back, and hit verify. The app resolves the record live and only marks the domain captured once it actually sees it. Until then the domain grants nothing at all, so a half-finished setup can never affect a sign-in.

Consumer domains are rejected outright. Nobody gets to claim gmail.com or outlook.com, for reasons that should be obvious the moment you picture the alternative.

Turning on enforcement

Verifying a domain makes SSO available. Turning on enforcement for that domain makes it mandatory: Google and Microsoft social sign-in are refused for any address on the domain, so those members go through your identity provider and only your identity provider.

One tip worth following, and the docs say the same thing in bolder letters: complete a real end-to-end sign-in through your provider before you flip enforcement on. Enforcement applies to everyone on the domain, admins included, so switching it on while the connection is still half-configured locks out the very account you would use to fix it. Sign in once successfully, then enforce. It takes an extra two minutes and saves a support ticket.

Enforcement is per domain, so an organization with several claimed domains can roll it out one at a time.

Setting up OpenID Connect

OIDC needs three values from your provider:

• Issuer URL
• Client ID
• Client secret

Going the other direction, the app displays the redirect (reply) URL to paste into your provider’s app registration. Copy it exactly; a mismatched redirect URI is the single most common reason a first attempt fails.

The client secret is write-only. Once you save it, it is never displayed again, not to you and not to another admin. When you come back later to change the issuer or client ID, leave the secret field blank and the stored secret is kept as-is. You only type a secret when you genuinely mean to replace it.

Setting up SAML 2.0

SAML is an exchange in both directions. The app shows you three values to give your identity provider:

• ACS (reply) URL, where assertions are posted
• SP entity ID, which is identical to the ACS URL by design
• Metadata URL, which most providers will import directly so you can skip typing the other two

In return you supply your provider’s IdP entity ID, its Sign-on URL, and one or more signing certificates in PEM or base64.

Multiple certificates, zero-downtime rotation

That “one or more” is deliberate, and it is the part worth pausing on. Signing certificates expire, and in most SSO integrations rotation is a coordinated outage: you swap the certificate on one side, and every assertion signed with the other one is rejected until both sides agree again.

Here you add the new certificate alongside the old one, let your provider cut over on its own schedule, then remove the retired certificate. Both are trusted in the overlap, so there is never a window where a validly signed response is refused. The screen lists each certificate with its subject, thumbprint, and expiry date, and starts warning you 30 days before one lapses, which is the point of a rotation feature: you find out with a month of runway rather than at 7 a.m. on the day it breaks.

Name ID format

The Name ID format must be persistent or emailAddress. Transient is refused, and that refusal is a feature. A transient identifier changes on every sign-in, so the same human would arrive as a brand new user account each time they logged in, accumulating duplicates and losing their role assignments along the way. Better to reject the configuration than to quietly produce that mess.

Attribute mapping and IdP-initiated sign-in

Standard email attribute names are recognized automatically, covering the shapes Entra ID and AD FS, Shibboleth, and Okta emit by default. If your provider sends something unusual, a manual override lets you name the attribute yourself.

IdP-initiated sign-in is off by default, which is the stricter and safer setting: sign-in starts at the AI Rule Engine sign-in page. If your members are used to launching apps from a tile in your provider’s portal, turn it on and that flow works too.

What sign-in looks like day to day

A member types their work email on the sign-in page. If that domain is captured, they are redirected to your identity provider, authenticate there, and come back already signed in. No password to manage on our side, no second set of credentials.

One rule holds no matter what your provider says: the email that comes back must land on a domain your organization has actually verified. If the provider authenticates someone whose address sits on an unclaimed domain, the sign-in is refused, because nothing in that response ties the person to your organization. Authentication and authorization are separate questions, and this is where the second one gets answered.

Not supported yet

Plainly, so you can plan around it: signed AuthnRequests, encrypted assertions, and Single Logout are not implemented. If your security review requires any of those, tell us and we will weigh it accordingly.

SCIM provisioning and group-to-role mapping do exist, but they are configured through the API rather than this screen today.

Open Organization settings, claim your domain, and connect your provider.

Visit RuleEngine.ai to try it.

The AI Rule Engine Team