DocuWare supports Microsoft Active Directory Federation Services as an identity provider for single sign-on. Here's how to connect DocuWare to Active Directory Federation Services.
In the DocuWare Configuration in the Organization Settings > Security area, activate the single sign-on option.
Go to your AD FS Server Manager.
Click on Tools and AD FS Managements
Go to Service > Endpoints and find the OpenId Connect Discovery endpoint.
Switch to DocuWare Configuration. Go to Organization settings > Security > Enable single sign-on > Configure single sign-on connection. Choose Microsoft Active Directory Federation services as Identity provider in the first dropdown.
In the Issuer URL input field insert the OpenId Connect discovery endpoint url. As an example: If your ADFS host is at “https://myadfs.net” and your discovery endpoint is “/adfs/.well-known/openid-configuration” then you would need to insert: https://myadfs.net/adfs/.well-known/openid-configuration
Go back to your AD FS settings and choose Application Groups.
Click on Add Application Group... in the right sidebar.
Choose a name and description for the application group, e.g. “DocuWare,” choose the option for Server Application accessing a Web API and click Next.
A Client Identifier is generated. Copy it and go to DocuWare.
Paste the client identifier in the “Client ID” field, copy the Callback URL provided and save your settings and switch to AD FS.
Go to AD FS configuration and paste the Callback URL in the Redirect URI box and click Add. Then click Next.
The next window will prompt you to select application credentials which we don’t need. You can choose Generate a shared secret and keep going.
On the next screen you’ll see the Identifier box. Copy the Client ID which was provided earlier and click Add. It’s important that it is exactly the same. Then, click Next.
On the next screen you can leave the default settings and click Next.
Select the application which you just created. From the Permitted scopes list at the bottom choose allatclaims, profile and openid. Then click Next.
Check that everything is set up correctly and finish your application creation
Double click on your newly created application group. A window will open. Double click the DocuWare Web API.
In the new window, choose the tab Issuance Transform Rules and add a rule.
In the newly opened window, choose Send LDAP Attributes as Claims from the Claim rule template dropdown. Then click Next.
Now choose your claim rule name e.g. “DocuWare object guid rule.” Choose Active Directory from the Attribute store dropdown. Then, in the table below, type objectGUID for the field LDAP Attribute and oid for the Outgoing Claim Type field.
Click Finish and apply your changes.
After saving the settings, users can log in with DocuWare user name and password and also use Single Sign-on via Microsoft. Logging in using DocuWare login data cannot be deactivated at this time.
Option “Automatically link existing users at login”
If this option is enabled, DocuWare searches for a matching existing DocuWare user with the corresponding username and email address the first time a user logs on with single sign-on. The DocuWare username must match the local part (first part before @) and the DocuWare email address must match the complete username in Active Directory.
Only when the username AND email address match, can the Active Directory user account and DocuWare user account be connected.
Example:
Username: peggy.jenkins@peters-engineering.net
DocuWare username: peggy.jenkins
DocuWare Email address: peggy.jenkins@peters-engineering.net
It is not necessary to create DocuWare users via the User Synchronization app in order to use single sign-on. Even if you create new users manually or import them via an interface, the external user account and the DocuWare account are automatically synchronized.
Once a user has been assigned, the user is recognized from this point through an external object ID. This means that even if the email address and/or username no longer match, the user will still be recognized.
Security settings for logout with single sign-on
In Azure Active Directory there are some default settings that DocuWare customers or their administrators may not be aware of.
Default setting for persistence of browser sessions
When browser session persistence is enabled, users can choose on their personal devices whether to continue the session after successful authentication with a Stay signed in? prompt. When users confirm the option, it is no longer possible to simply log out of an application. The single sign-on token is not invalidated or deleted and remains valid for other applications.
This is a security risk: for example, if you log on and off from an Internet cafe using Single Sign-on in DocuWare Cloud, you will still be logged on to Microsoft. The next user on the computer could access all connected systems.
Default setting for the validity period of tokens
The risk is aggravated by the fact that the tokens for the Stay signed in option are valid for 90 days by default for devices (with unchanged default setting). For applications even up to 180 days (depending on the configuration settings).
DocuWare therefore recommends the following measures:
Follow the Azure Active Directory guidelines for conditional access to control the lifetime of session tokens.
In Azure Active Directory, define the sign-in frequency option for DocuWare.
Disable the option for persistent browser sessions.
Remove the Stay logged in option from the Microsoft Logon dialog
Information on these measures can be found in the next section.
Notes on configuring logout security settings
The persistence of browser sessions is extensively documented by Microsoft.
Summary:
"Conditional Access" describes the concept of login policies in Azure Active Directory. The policies can be used to configure the validity of a token.
For example, a token consists of an account, a client (device) and a resource. Instead of configuring the validity period of the token, you use policies to define the frequency of login, that is, the intervals at which users must re-authenticate when using a particular resource. For critical applications, users often need to re-logon, while tokens for less critical resources are valid for longer.
This feature can be integrated into applications that implement the OAUTH2 or OIDC protocol.
Another important aspect of this security concept is the management of "stay-signed-in" functionality. While extended session validity is useful for mobile or thick applications, it is not suitable for use cases where the client functionality is provided by a Web application.
To prevent the access control policies described above from being overridden by the stay-signed-in settings, it is advisable to disable this functionality by setting the persistent browser session configuration to Never persistent.
Additionally, the option to select stay-signed-in can be removed from the Login with Microsoft dialog box in the Add branding to your organization's sign in page settings.