When all requirements have been met, you're now able to enable AAD login for the products you decided on (DC and/or MM)

Enabling AAD

To enable the AAD functionality, you need to do the following:

Go to your DC's web.config file and edit it - preferably with Notepad++.

In the <configSections> tag, add the following:

<section name="azureActiveDirectory" type="DigiEyeZ.Framework.WebLibrary.Configuration.AzureActiveDirectorySection" />

Making it look like this

Configuration examples

Not DC - possibly MM

Aka. "DC API server only"

Enabling the beneath configuration will enable only MM to use AAD. The DAM Center will still remain using the default non-AAD login.

Please be aware the the templateMemberId should be the user ID of the template user, you've noted down while verifying that you met the requirements (step 3: The ID of a user of which you want all your users to look like (AAD Template User)). In my case below its 30027.

<azureActiveDirectory>
	<server enabled="true" templateMemberId="30027" />
</azureActiveDirectory>

Implementing the above into the web.config will make it look like the following

DC - possibly MM

Requirements

If you are a partner or are working in professional services, then you need the following information from the customer, in order to set up the solution:

The client's tenant ID
The DC's application ID
The MM's application ID (Used in the MM's web.config - see the MM's AAD guide)

Aka. "DC API server with single tenant client login"

The below configuration enabled both DC and MM to use AAD for logging in.

The "templateMemberId" is again the one you defined in the requirement section (requirement 3 - just as before).
The "clientId" is the Application ID of the DAM Center's App registration you made a note about in the requirements section
The "tenant" is the App ID URI without https:// and the GUID (For example "https://digizuite.onmicrosoft.com/95303ff7-f100-47ab-ad3a-2a465ff47bd0" becomes "digizuite.onmicrosoft.com") - You made a note of this in the requirements section.
The "clientSecret" is the secret key that goes together with the Application ID. This is optional. If you choose not to have it, then remove it (See the image below the code block) ()

<azureActiveDirectory>
	<server enabled="true" templateMemberId="30021" />
	<client enabled="true" clientId="[DC'sApplicationID]" clientSecret="[Client Secret]" tenant="[mytenantid].onmicrosoft.com" />
</azureActiveDirectory>

Implementing the above into the web.config will make it look like the following

In case of using the AAD authentication up against standard Identity Server that uses the OpenID standard, then there are few extra fields required for success. The below illustrates the addition of stsDiscoveryEndpoint, client secret, redirect URI and scope (as per https://openid.net/developers/specs/):

<azureActiveDirectory>
    <server enabled="true" templateMemberId="[member id]" stsDiscoveryEndpoint="https://xxxxx.com/.well-known/openid-configuration" />
    <client enabled="true" scope="openid profile email" clientId="[client secret]" redirectUri=”[redirect uri]” clientSecret="[client secret]" aadInstance="[identity server instance url]" />
</azureActiveDirectory>

Often it is required to also add redirectUri which must be aligned to the reply URLs defined in AAD. You need one for the LoginService (which supports mm5 and office connector) and the DAM Center as seen here:

Not having email as your unique id?

By default, email is used as binding between the SSO and Digizuite DAM so there email must also be considered unique (or domain + initials). If this is not true for your organization, then it is possible to configure bindingNameField="your binding" on the azureActiveDirectory <server> xml element. For instance, in the request from Azure AD (or OpenIdConnect) you could have another field that you like to use. This could be "sub", "username" or similar which would then correspond to <server enabled=true bindingNameField="sub".... />

Understanding "server" and "client"

The sub-elements of the azureActiveDirectory tag (server and client) can be a bit difficult to wrap one's head around - here's some explanation:

Server: Defines the template user used for creating new AAD users.

Client: Defines that the site corresponding to the chosen client ID/application ID and tenant will use AAD for logging in. The client ID of the MM must not be input into the DC's web.config's azureActiveDirectory tag - instead the MM will have its own client ID defined within its own web.config.

Configuration schema

Beneath, you'll see the definition of all the available options you have for setting up

<?xml version="1.0" encoding="utf-8"?>
<xs:schema id="azureActiveDirectory" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
  <xs:element name="azureActiveDirectory" msdata:IsDataSet="true" msdata:UseCurrentLocale="true">
    <xs:complexType>
      <xs:choice minOccurs="0" maxOccurs="unbounded">
        <xs:element name="client">
          <xs:complexType>
			<!-- Enables or disables the client using AAD redirect -->
            <xs:attribute name="enabled" type="xs:bool" use="required" />
			<!-- ClientId corresponds to the Application ID in Azure Portal -->
            <xs:attribute name="clientId" use="required">
				<xs:simpleType>
					<xs:restriction base ="Guid" />
				</xs:simpleType>
			</xs:attribute>
            <!-- AADInstance is the login redirect URI -->
			<xs:attribute name="aadInstance" type="xs:string" default="https://login.microsoftonline.com/{0}" />
			<!-- Tenant is the DNS section of the App ID URI in Azure Portal. Required for single tenant usage -->
            <xs:attribute name="tenant" type="xs:string" />
			<!-- Specifies optional post logout URI. Not used in DC and MM -->
            <xs:attribute name="postLogoutRedirectUri" type="xs:string" />
          </xs:complexType>
        </xs:element>
        <xs:element name="server">
          <xs:complexType>
            <xs:sequence>
              <!-- List of audiences allowed when running multi-tenant applications -->
              <xs:element name="validAudiences" minOccurs="0" maxOccurs="unbounded">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name="clear" type="xs:string" minOccurs="0" />
                    <xs:element name="add" minOccurs="0" maxOccurs="unbounded">
                      <xs:complexType>
                        <xs:attribute name="name" type="xs:string" />
                      </xs:complexType>
                    </xs:element>
                  </xs:sequence>
                </xs:complexType>
              </xs:element>
            </xs:sequence>
			<!-- Enables or disables the server AAD endpoint -->
            <xs:attribute name="enabled" type="xs:bool" use="required" />
			<!-- Discovery endpoint for validating JwT -->
            <xs:attribute name="stsDiscoveryEndpoint" type="xs:string" default="https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration" />
			<!-- Specifies the DAM Center MemberId used to auto-create users on the fly -->
            <xs:attribute name="templateMemberId" type="xs:int" use="required" />
            <!-- Specify to validate the issuer -->
            <xs:attribute name="validIssuer" type="xs:string" />
          </xs:complexType>
        </xs:element>
      </xs:choice>
    </xs:complexType>
	<xs:simpleType name="Guid">
        <xs:restriction base="xs:string">
            <xs:pattern value="([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})|(\{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\})"/>
        </xs:restriction>
    </xs:simpleType>
  </xs:element>
</xs:schema>