ADFS with SAML SSO

Connect Active Directory Federation Services (ADFS) to Document360 with SAML so your users and readers sign in to Document360 with their existing Active Directory credentials instead of a separate password. You create a relying party trust in ADFS, add claim rules, and then complete the SSO configuration in Document360. ADFS has no built-in SCIM support, so automatic provisioning needs a third-party tool or a custom integration.

When to use ADFS with SAML SSO

Use this setup when:

• Your organization manages identities in an on-premises Active Directory and uses ADFS for federation.
• You want users to sign in to the knowledge base portal and readers to sign in to the knowledge base site with the same Active Directory account.
• You want people to open Document360 directly from ADFS (IdP-initiated sign-in).
• You manage several Document360 projects and want a new project to inherit SCIM settings from an SSO configuration in a parent project.

Before you begin

• You need the Owner or Admin role in your Document360 project.
• You need administrator access to your ADFS server.
• Keep Document360 open in your browser and the ADFS Management console open on your ADFS server. You switch between them during setup.
• When you export the X.509 certificate from ADFS, you must select Base-64 encoded (.CER). Document360 does not accept the default DER encoded format.
• If you plan to use SCIM, set up your third-party provisioning tool or custom integration first, and have a secure place ready, such as a password manager, to store the SCIM secret tokens.

How to set up SAML SSO with ADFS

Step 1: Start the SSO configuration in Document360

1. Go to Settings () > Users & Permissions > Enterprise SSO.
2. Select Create SSO.

3. Select SAML (Enterprise SSO using SAML 2.0).
4. Select ADFS as your identity provider.

The Configure SP step opens and shows the Document360 values you enter in ADFS: Service provider entity ID, Callback path, Signed out callback path, Subdomain name, and Metadata path. Keep this tab open.

Step 2: Create a relying party trust in ADFS

1. Log in to the ADFS Management console on your ADFS server.

2. Go to Relying Party Trusts.

3. Right-click Relying Party Trusts and select Add Relying Party Trust.

4. In the Add Relying Party Trust Wizard, choose Claims aware and click Start.

5. Select Enter data about the relying party manually and click Next.

6. Enter a display name, such as Document360 SAML SSO, and click Next.

7. In the Configure Certificate step, click Next. Skip this step unless you use a token encryption certificate.

8. Under Configure URL, select Enable support for the SAML 2.0 Web SSO protocol.

9. In the Configure URL and Identifiers steps, enter the values from the Document360 Configure SP step:

   ADFS	Document360
   Relying Party Identifier	Service provider entity ID
   Sign-On URL	Callback path
   Sign-Out URL	Signed out callback path
   Relying Party Trust Identifier	Subdomain name
   Metadata URL	Metadata path

10. Click Next and complete the remaining steps in the wizard, such as setting up multi-factor authentication if your organization requires it and permitting all users to access the application.

11. Review your settings and click Next to add the relying party trust.

12. On the final screen, select Open the Edit Claim Rules dialog and click Close.

The relying party trust appears under Relying Party Trusts, and the Edit Claim Rules dialog opens.

Step 3: Add claim rules in ADFS

Claim rules tell ADFS which user details to send to Document360.

1. In the Edit Claim Rules dialog, click Add Rule.
2. Select Send LDAP Attributes as Claims as the rule template and click Next.
3. Enter a name for the claim rule, such as Send LDAP Attributes.
4. Configure the rule:
   • Attribute Store: Select Active Directory.
   • Mapping:
     • LDAP Attribute: User-Principal-Name | Outgoing Claim Type: Name ID
     • LDAP Attribute: E-Mail-Addresses | Outgoing Claim Type: Email-Addresses
     • LDAP Attribute: Display-Name | Outgoing Claim Type: Name
5. Click Finish to add the rule.
6. Click Apply to save your changes and close the dialog.

Step 4: Enter the ADFS details in Document360

1. Switch to the Document360 tab and click Next to go to the Configure IdP step.

2. (Optional) To reuse SCIM settings from a parent project, select an SSO configuration that already has SCIM turned on in Configure an existing connection. This configuration becomes the child and inherits the SCIM settings from the parent project.

3. Enter the values from your ADFS configuration:

   ADFS	Document360
   SAML Sign-On URL	Sign on URL
   Identifier (Entity ID)	Entity ID
   X.509 Certificate	SAML certificate

4. Export the X.509 certificate from ADFS in Base-64 encoded (.CER) format and upload it in SAML certificate.

5. To let people open Document360 from ADFS without visiting the Document360 login page first, turn on Allow IdP initiated sign in.
6. Click Next. The SCIM step opens.

Step 5: (Optional) Set up SCIM provisioning

SCIM keeps users and readers in sync between your directory and Document360. Because ADFS does not support SCIM natively, you need a third-party tool or a custom-built integration to send SCIM requests to Document360.

If you don't need SCIM, leave Enable SCIM provisioning off, click Next, and go to Step 6.

1. Turn on Enable SCIM provisioning.

2. In the confirmation dialog, review the terms, select the checkbox, and click Agree. The SCIM base URL and the primary and secondary secret tokens appear.
3. Enter the SCIM base URL and the primary secret token in your third-party tool or custom integration.
4. In Default role, keep Contributor or select another role. The default role applies to users only.
5. In User groups and Reader groups, select the groups to add new people to. Users in the selected user groups get the default role. Readers in the selected reader groups always get read-only access.
6. Click Next.

Step 6: Name the configuration and create it

1. In SSO name, enter a name for the SSO configuration.
2. In Login button text, enter the text for the sign-in button. The default text is Login with SSO.
3. (Optional) To sign out users after a period of inactivity, turn on Idle session SSO timeout and set the Timeout duration (HH:MM).
4. (Optional) To switch existing accounts to this SSO configuration, turn on Convert existing team and reader accounts to SSO. Then, under Send invite to, select All users or Selected users. Each existing account is converted to SSO; Document360 does not create a second account.

5. Click Create.

The configuration appears in the Enterprise SSO list.

Step 7: Test the sign-in

1. Open the Document360 login page in a private browser window.
2. Enter your email address or subdomain and click Login with SSO (or the button text you set in Step 6).
3. Sign in with an Active Directory account that ADFS permits to access the relying party trust.

You're signed in to Document360. If sign-in fails, read SAML SSO issues and SSO login issues.

View and manage SSO readers in Document360

To find readers who sign in through ADFS and manage their content access:

1. Go to Settings () > Users & Permissions > Readers & groups.

2. Select a reader to open their reader profile. Readers provisioned through SCIM show an SSO-SCIM badge next to their name.
3. Click Manage Content Access.
4. Choose the access level from the dropdown and click Update.

Content access permissions are set to None by default, and you can change them at any time. To manage a reader's groups, click Manage groups under the Reader Group section.

Limits and limitations

Best practices

• Export the certificate in Base-64 encoded (.CER) format. Always select Base-64 encoding when you export the X.509 certificate from ADFS.
• Plan provisioning before you turn on SCIM. Choose and set up your third-party tool or custom integration first, because ADFS can't send SCIM requests on its own.
• Check all three claim mappings. Missing or incorrect Name ID, Email-Addresses, or Name claims cause sign-in failures.
• Test with one user first. Before you roll out SSO to everyone, sign in with a single test account to confirm that the claim rules, certificate, and URLs work.
• Store SCIM secret tokens like passwords. Keep them in a password manager or secrets vault, never in plain text files or code repositories.

FAQ