Federate Existing Providers

If your organisation already has a corporate identity provider, you do not need to migrate user accounts to EUnifyer. EUnifyer can federate with your existing IdP so users sign in with the credentials they already use every day.

This is called identity brokering. EUnifyer sits in front of your services and delegates authentication to your existing IdP.

Supported providers

EUnifyer federates with any provider that speaks OIDC or SAML 2.0, including:

Microsoft Entra ID (formerly Azure AD), see the dedicated Entra ID guide.
Google Workspace. OIDC.
Okta. OIDC or SAML.
OneLogin. SAML.
Ping Identity. OIDC or SAML.
ADFS. SAML.
Auth0. OIDC.
Surfconext (Dutch research and education federation). SAML.
DigiD / eHerkenning (Dutch citizen and business IdP, on request). SAML.
Any other OIDC- or SAML-compliant provider.

How federation works


   ┌──────────┐        ┌────────────┐        ┌─────────────────┐
   │  User    │──①────▶│  EUnifyer  │──②────▶│  Your existing  │
   │ browser  │        │   login    │        │       IdP       │
   └──────────┘        └────────────┘        └────────┬────────┘
        ▲                    ▲                        │
        │                    │                        │
        │                    └────────③ identity ─────┘
        │
        └─────────────────④ EUnifyer session ─────────────────

User opens an EUnifyer service and is redirected to the login page.
They click “Sign in with <your provider>”.
Your IdP authenticates them and returns identity claims (email, name, group membership).
EUnifyer creates or updates a local account from those claims and issues an EUnifyer session.

The user only sees their familiar corporate login screen. After that they are inside EUnifyer.

What gets mapped

By default, federation maps these attributes from the upstream IdP:

Claim	Mapped to
`email`	EUnifyer user email
`given_name`, `family_name`	First / last name
`preferred_username`	Username
`picture`	Avatar (if provided)
Custom group / role claim	EUnifyer roles (configurable)

You can add custom claim mappings if your IdP exposes additional attributes (department, employee number, cost centre, etc.).

Scenario	Recommendation
Staff and contractors of one organisation	Federate against the existing corporate IdP. Use EUnifyer’s local accounts only for guests.
Multi-organisation tenant (consultancy, holding)	One brokered IdP per organisation, keyed by email domain. EUnifyer auto-routes to the right one.
Education sector	Federate against Surfconext (Dutch research and education) for staff and students.
Public sector with citizen-facing services	Federate against DigiD / eHerkenning for citizens, against the municipal IdP for staff.
Mixed Microsoft / Google estate	Federate against both. The user picks at the login screen.

What you keep when you federate

Existing usernames and passwords (we never see them).
Existing MFA policy enforced by your IdP.
Existing offboarding workflow, when you disable a user in Entra/Google, their EUnifyer access stops at the next session check.
Existing group / role assignments, mapped into EUnifyer roles.

What changes when you federate

The first time a user signs in via the brokered IdP, EUnifyer auto-provisions a local account from their claims.
Group membership claims become EUnifyer roles. You can override on a per-organisation basis.
Local-only accounts (created directly in EUnifyer) keep working alongside federated ones.

Setup outline

In EUnifyer, open Admin → Single Sign-On, click Configure SSO, pick your provider (Entra ID, Google, Okta, or Generic OIDC / SAML 2.0), and click Test connection once to print the redirect URI.
In your IdP, register EUnifyer as a relying party / application and paste the redirect URI from step 1.
Copy the Client ID and Client Secret from your IdP back into EUnifyer.
Add the email domains that should auto-route to this provider.
Click Test connection to verify discovery, then Configure SSO to save.
Once tested with one user, optionally turn on Require SSO for all org users.

For provider-specific walkthroughs, see Microsoft Entra ID.

Not yet self-service: custom claim mappings and group-to-role mapping currently require an onboarding engineer. The UI ships these as a roadmap item.

Need a provider that is not listed?

If your IdP speaks OIDC or SAML, it works. If it speaks something more exotic (LDAP, Kerberos, smart-card PKI), we can still bridge it via Keycloak’s pluggable authenticator layer. Contact your EUnifyer onboarding engineer with the protocol details.