Procurement Admin
Sign-in and SSO
Two sign-in modes that exclude each other — and what your identity provider has to do with it.
- Duration: 20 min
- Level: In depth
- Read first: Roles and permissions
An instance runs either with SSO or with user management inside the application. Not both, and there is no fallback from one to the other.
That decision is made before you go live. Reversing it afterwards is not a switch.
The normal case: SSO
e-Request speaks OIDC against Keycloak. If you do not run identity management of your own, a managed Keycloak instance comes with it.
Important: with SSO active, Keycloak owns the role. The application displays it, it does not manage it. Changing roles then happens in the identity provider — and anyone who does not know that will look for the setting in the wrong interface.
If you use Entra ID or AD FS
Those speak SAML. e-Request itself implements no SAML. Your SAML identity provider is connected through Keycloak as a federated provider — Keycloak does the brokering, not the application.
This works and is the intended route. But it is a service, not a checkbox: the connection belongs in the planning and in the quote. Do not assume it is “included”.
The other mode: user management in the application
An instance can also run with no identity provider at all: invitation by email, password, and a lockout against automated guessing. Roles then live in the application.
The supplier side is unaffected
Suppliers always sign in with a username and password, whatever mode your buying side runs. There is no SSO on the supplier side, and that is a decision rather than a gap: a supplier works for many buyers, and an account per portal is the approach that works everywhere.
So never promise a supplier they can sign in with their company account.
Ending access
Access is deactivated, not deleted — on both sides. Anyone who has acted stays traceable in the log while being out of day-to-day operation immediately. See Users and access.