Authentication
primedocs does not run a user directory with passwords of its own. Every sign-in goes through the bundled Identity Server (IdS), which is connected to the corporate directory (Entra ID or Active Directory). This page describes who signs in by which method and what the sign-in hands over to primedocs. The corresponding configuration is covered in the Installation section.
Authentication only establishes who signs in. Which data that person holds in primedocs (user fields, profile, organizational unit) is created afterwards by provisioning.
Two kinds of sign-in
| Kind | Who | Method |
|---|---|---|
| People | Users in primedocs Web, Desktop and the Office add-ins | OpenID Connect against the IdS, which forwards the sign-in to the directory |
| Systems | Third-party systems calling Connect, the Web API or the Admin API | OAuth 2.0 against the IdS, usually through client_credentials. The clients are registered in primedocs.config. See API Authentication |
| External administrators | Operations and support access for managing a datasource | A dedicated Entra ID app (<dataSourceAdminAppAuth>), alongside the sign-in of the regular users. These accounts are deliberately not created as users in the datasource. See Entra ID Apps |
In every case the IdS issues the access token, and the primedocs services have it validated by the IdS.
Authentication methods for people
For the sign-in of regular users, a primedocs instance runs in one of the two methods. What decides it is whether an <office365Auth> node is configured in primedocs.config:
| Method | Directory | Use | Configuration |
|---|---|---|---|
| Entra ID | Microsoft Entra ID (formerly Azure Active Directory) | Cloud and hybrid operation. A prerequisite for the Office and Teams add-ins | <office365Auth> in primedocs.config plus an Entra ID app |
| Windows authentication | Active Directory | Pure on-premises operation without Microsoft 365 | No <office365Auth>. Kerberos/Negotiate either directly or through the Windows host of the IdS. Prerequisites: Active Directory requirements |
What the sign-in supplies and what it does not
From the sign-in itself, primedocs takes the identity only:
| Item | Meaning |
|---|---|
| PrimarySid | The unique key of the person. With Active Directory this is the objectSid (format S-1-5-…), with Entra ID the objectId (a GUID). primedocs uses it to match the user record, see Users, Profiles and Organizations |
| Account name | The sign-in name from the token (UPN or preferred_username) |
The display name and the group memberships are not in the token. primedocs reads them from the directory itself after the sign-in (a separate access using the server's permissions, not part of the sign-in). From the group SIDs, primedocs then derives the permissions.
Where the groups come from
The chosen authentication method determines the source primedocs reads the display name and group memberships from. This is the point where authentication and data retrieval genuinely do connect:
| Authentication method | Source for display name and groups |
|---|---|
| Windows authentication | Active Directory via LDAP |
| Entra ID | Microsoft Graph |
| Entra ID with SCIM | The data supplied through SCIM (useful when no application permission may be granted for Microsoft Graph) |
Which directory property serves as the display name is configurable per source. SCIM can only be combined with Entra ID, not with Windows authentication.
From sign-in to user
After the sign-in, primedocs checks whether a user already exists in the datasource for that PrimarySid. If not, the user and a default profile are created automatically. The sequence is described in Provisioning. The details are in Onboarding & Offboarding.
Automatic sign-in (SSO)
If a valid Entra ID session already exists on the workstation, primedocs signs users in without a login dialog. This applies to Desktop, Web and the Office and Teams add-ins. How it works, its prerequisites and the required app registration are described in Single Sign-On (SSO).
Further reading
- primedocs.config: configuration of authentication and of the API clients
- Single Sign-On (SSO): automatic sign-in across all clients
- API Authentication: obtaining tokens for third-party systems
- Provisioning: how user and organization data is created after sign-in
- Roles: how group memberships become permissions