Single sign-on

With single sign-on (SSO), your employees sign in with their company account. That is the account they already use for email and other tools. They then do not need a separate procuris password. Sign-in takes place at your identity provider. Its sign-in rules therefore also apply to procuris.

Your IT controls in the identity provider who may sign in. Roles in procuris are still assigned by people with the role Owner in procuris. Their accounts stay outside SSO as emergency access, see Existing accounts and new employees.

Protocols and identity providers

procuris supports SAML 2.0 and OpenID Connect. These are the two common standards for company sign-in. The connection only requires that your identity provider speaks one of the two. Microsoft Entra ID, Google Workspace and Okta do. Below are the values in general and the settings for Entra ID and Google Workspace.

The role Owner makes the entries in procuris. Only people with this role see the Single sign-on section under Settings › Organization, even if your organization has several. The section exists only once access has been set up after the contract is signed. Until then, the Single sign-on row in the On request section of the same page only requests a quote. Your IT sets up the identity provider and gives the owner the values procuris needs. The owner enters them, verifies the domain and manages the SCIM token. If your IT lead has the role Owner, they do both.

<organisation> is the short name of your organization. It appears in the address of the app.

SAML 2.0

What procuris needs: the metadata of your identity provider as a URL or XML file. The owner enters it under Single sign-on.

NameID: the business email address, format emailAddress.

Attributes: email, first name, last name. procuris accepts the short names email, givenName, surname and the long names that Entra ID sends by default:

Signature: signed assertion or signed response, with SHA-256. The defaults of Entra ID (Sign SAML assertion, SHA-256) and Google Workspace (only the assertion signed) fit.

Microsoft Entra ID with SAML

1. Entra ID › Enterprise apps › All applications › New application, create an application of your own, and in it Single sign-on › SAML.
2. Under Basic SAML Configuration, enter the Entity ID and the ACS URL from above.
3. Under Attributes & Claims, set the value of the name ID (Name identifier value) to the attribute user.mail, format Email address. The default is the sign-in name (UPN), which does not always match the email address.
4. Under SAML Certificates, copy the metadata URL and give it to the owner for Single sign-on.
5. Assign the application to the people who use procuris. Assigning groups requires Microsoft Entra ID P1 or P2.

Google Workspace with SAML

1. In the Admin console, create a custom SAML app.
2. Download the metadata from Google. Google offers it as a file, not as a URL. The owner uploads this file in procuris under Single sign-on.
3. Under the service provider details, enter the ACS URL and Entity ID from above. Signed response stays turned off. Set the name ID format to EMAIL. The name ID itself stays at the default, the primary email address.
4. Under attribute mapping, use Select field to create three mappings: primary email address to email, first name to givenName, last name to surname.
5. Turn the app on with On for everyone or for single organizational units.

With Google Workspace, the way without SCIM applies. According to its own help, Google offers automatic provisioning for apps from its catalog. For custom SAML apps, Google names no automatic provisioning. You therefore lock out people who have left as described under Without SCIM.

OpenID Connect

What procuris needs: the issuer URL, client ID and client secret. The owner enters them under Single sign-on. procuris reads the configuration at <Issuer-URL>/.well-known/openid-configuration.

Claims: email is required. procuris takes given_name and family_name as the name. procuris does not require email_verified, because Entra ID does not send it. If Entra ID sends the optional claim xms_edov with the value false, procuris rejects the sign-in.

Microsoft Entra ID with OpenID Connect

1. Entra ID › App registrations › New registration. Give it a name, for example "procuris", and under Supported account types choose Single tenant only, so that only accounts of your company sign in. Create it with Register.
2. On the Overview page, copy the Application (client) ID. That is the client ID. The tenant ID for the issuer URL is under Entra ID › Overview › Properties in the field Tenant ID.
3. Under Authentication › Add Redirect URI, choose the platform Web, enter the redirect URI from above and save with Configure.
4. Under Certificates & secrets › Client secrets › New client secret, choose a description and an expiry, then Add. Copy the Value right away. Entra ID does not show it again after you leave the page. A client secret is valid for at most 24 months. Microsoft recommends less than 12. If it expires, sign-ins fail. Create a new one before it expires for this reason and give it to the owner.
5. Under Token configuration › Add optional claim, add given_name and family_name for the ID token. Entra ID sends these two claims in version 2.0 tokens only when they are requested.

Entra ID sends email only for accounts with a stored email address, through the scope email. Without an address on the account, sign-in to procuris fails, because email is required. Check this especially for accounts that only have a sign-in name.

Google with OpenID Connect

1. In the Google Cloud Console, choose a project of your organization. Under Google Auth Platform, choose Internal for the audience, so that only accounts of your organization sign in.
2. Under Google Auth Platform › Clients, choose Create client, application type Web application.
3. Under Authorized redirect URIs, enter the redirect URI from above and create it with Create.
4. Copy the client ID and client secret. Google shows the client secret only once, at creation. After that, you only see its last four characters there. Give it to the owner through a password manager. If it gets lost, create a new secret in Google.

The issuer URL is https://accounts.google.com. With Google, the way without SCIM applies here as well.

Existing accounts and new employees

Existing accounts are kept, missing ones are created by procuris at the first sign-in.

• First sign-in through SSO without an account: procuris creates the account in your organization, with the role Member. People with the role Owner can then change the role in the sidebar under User Management.
• Existing account with the same email address: is taken over, with its role and all content. The previous password is no longer valid.
• After the switch: accounts of the verified domain sign in only through SSO. Accounts with the role Owner are the exception, see emergency access.
• Emergency access: Accounts with the role Owner stay outside SSO and keep signing in as before. This way your organization gets into procuris even if the identity provider fails or is set up wrongly.
• Session length: A sign-in through SSO is valid for at most 12 hours. After that, the person signs in again through the identity provider.
• A domain belongs to exactly one organization. If it is already verified for another organization, support resolves the conflict at support@procuris.eu, because neither of the two organizations can resolve it alone.

Lock out people who have left automatically with SCIM 2.0

SCIM locks out people who have left without anyone clicking in procuris. SCIM is a standard through which your identity provider creates, changes and locks accounts in other applications. Once SCIM is set up, procuris locks an account as soon as your identity provider reports the lockout. The lockout also ends the running sessions of this account.

Entra ID syncs at intervals, not instantly. In the application under Provisioning › Admin Credentials, enter the base address in the field Tenant URL and the SCIM token in the field Secret Token. Under Attribute Mapping, turn off the mapping for groups. If you remove a person from the application or block their account there, Entra ID sends active: false in the next cycle. After the first cycle, Entra ID usually syncs about every 40 minutes. According to Microsoft, the length of a cycle depends on the scope, for example on the number of assigned people and groups. Entra ID shows the status under Provisioning in the section Current Status. Assigning people by group instead of one by one requires Microsoft Entra ID P1 or P2.

Rotating or revoking the SCIM token is done by the owner under Single sign-on. For a rotation without downtime, they create a second token. As soon as your IT has entered it in the identity provider, the owner revokes the old one. If a token has become public, they revoke it right away and create a new one. If nobody with the role Owner can be reached, write to support@procuris.eu. We then revoke the token after checking back with your organization.

Without SCIM

Without SCIM, you lock out in two places. This applies to Google Workspace and to every identity provider that offers no SCIM for custom applications. If you block the account in the identity provider, the next sign-in to procuris fails right away. However, a running SSO session ends only after at most 12 hours. The second place is procuris: there, people with the role Owner remove the person in the sidebar under User Management with Remove User. After that, the person no longer appears in the list of your organization.

Verify the domain

Without a verified domain, procuris forwards no sign-in to your identity provider. Verifying proves that the domain belongs to your company. For this, your IT creates a DNS record of type TXT for your domain:

procuris-verification=<value>

procuris shows the value to the owner under Single sign-on. The owner passes it to your IT. As soon as the record is visible in DNS, the domain counts as verified, and procuris shows the status there. The record can stay in place afterwards.

Related pages

• Integrations: the way to a quote
• User management