Document Control Authentication Settings

Revision: 2024-04-08

Email Address Usage

Some authentication methods use email sending and the user's email address in the authentication and/or setup flow. Document Control does not store or record the email addresses of Confluence users. When Document Control needs access to the email address, the email address will be retrieved on demand from the Confluence API. That means Document Control always uses the user's current email address as it is registered in Confluence and the Atlassian user account. The user's organization and/or the user have full control over the email address, and Document Control can not change it. For some authentication methods, the user's Atlassian registered email address is compared to an external email address (e.g. for SSO). When this comparison is done, Document Control will lower case the email addresses before comparison (e.g. "Jane.Anderson@example.com" and "jane.anderson@Example.COM" are considered equal).

Users can view their Atlassian registered email address at their Atlassian profile page.

A Personal Token is a code or password a user needs to set up before the first use. When you enable this authentication method, users without such a token are prompted to create it. Token creation is validated by a short lived code sent by email, and token deletion triggers a warning email to the user.
Token usage and misuse is protected by rate limiting, and if too many incorrect tokens have been tried, the user is prompted to reset the token.

For 2FA authentication, a user needs to install and pair an authenticator app. Compatible apps are:

• FreeOTP+ Authenticator
• Google Authenticator
• Microsoft Authenticator
• Alternative authenticator apps compatible with "TOTP"

API key: When using API key authentication, a user needs to generate a secure token once by using the Atlassian provided secure token management page at the Atlassian API token page. The token is unique to each user, and can be revoked on demand.

The email for the signature must be the email address used for Confluence login.

Single Sign-On (SSO) is supported through OpenID. Document Control works with many OpenID authentication providers, e.g. Okta and Microsoft Entra ID (Azure AD).
The configuration for OpenID requires multiple OpenID provider settings. These settings depend on your organization's OpenID setup.

Setting up OpenID requires you to provide Document Control with the OpenID provider's information, and also requires you to provide specific Document Control settings to your OpenID provider.
As part of the setup process, you will be redirected to your OpenID provider to check if all settings are correct.

• The status describes the current status of the OpenID integration. When the status is "validated", Document Control has validated the OpenID parameters and your users can sign documents with OpenID.
• The name is a short text that is displayed to your users, such that they can understand which authentication method they are using. You can choose this optional field.
• The Issuer URL from the identity provider is a URL string which tells Document Control where to get information about your OpenID setup. This URL is specific to each provider and your specific setup.
• The Client ID from the identity provider is (usually) a random looking, unique string which identifies your specific OpenID client information.
• The Client Secret from the identity provider is a secret which allows Document Control to identify itself to the identity provider. We encrypt the client secret before storing it. You must make sure the client secret is kept confidential, it's role is similar to a password.
  Secret Expiration: Your OpenID might expire the secrets and might require secret rotation. When the secret expires, signing with OpenID is not possible until a new and valid secret is added to the settings.
• The OpenID/OIDC prompt parameter influences how your identity provider processes an identification request. When set to "login", Document Control asks the identity provider to check your login credentials. When set to "no prompt parameter", Document Control gives no identification processing hint to your OpenID provider. The actual identification process of your OpenID provider depends on the settings of the OpenID provider you control. Document Control has no control over these settings, and it is your responsibility to validate the settings and identification flow such that it conforms to the regulatory compliance you need to fulfill.
• The Callback (or redirect) URL is information you must provide to your OpenID provider. Currently the callback URL is:

  https://dccc.phaselockedsoftware.com/openid/callback/openidv1m1

  The callback URL might change with e.g. data residency changes.
• You must also add the Response type as "id_token" to your OpenID provider.

Regulatory Compliance: When using OpenID, Document Control uses an external authentication provider for user authentication for the signatures. Document Control does not control the settings of the external authentication provider, and it is your responsibility to validate the authentication settings to ensure regulatory compliance. Document Control protects the integrity of the signature information in the authentication process, however Document Control can't guarantee the integrity of the authentication request. It is your responsibility as user of Document Control to validate the authentication flow with the applicable regulatory regulations.

Microsoft Entra ID

Okta