3 posts tagged with "saml 2.0"

How to use SAML 2.0 protocol to access Secret Server​

Secret Server allows the use of SAML Identity Provider (IDP) authentication instead of the normal authentication process for single sign-on (SSO). To do this, SS acts as a SAML Service Provider (SP) and communicates with Monokee that's acting as a SAML IDP.

In this use case, the user who wants to access Secret Server will not log in through a Secret Server form, but will be redirected to Monokee, which will take care of validating the credentials and communicating the data necessary for user identification to Secret Server, which will eventually log the user in.

Then, the former authenticates the user and provides the latter with the attributes necessary for it to be correctly identified and for it to access the service.

In the following article we explain how the proposed scenario can be put in place; therefore, the steps to be taken on the Secret Server side and the Monokee side in order to achieve a proper SAML 2.0 configuration related to the two providers will be explained.

Monokee Configurations​

In order to get Monokee's domain and Secret Server's domain to communicate properly, you need to do three things on Monokee:

• A Add a custom attribute where the user's identifier will be present on Secret Server
• B Set up a SAML 2.0 identity provider that has the correct parameters to successfully work with Secret Server
• C Configure a SAML 2.0 application with all the parameters related to Secret Server.

The first two points will be explained below, while the third will be discussed in more detail after the necessary Secret Server-side operations are explained.

A) Attribute to Identify the User on Secret Server​

Secret Server allows the user to be identified only by username which is uniquely within the custom domain.

It is therefore necessary for the Monokee side to have a custom attribute in which this field is saved for each user in the domain.

It is assumed that an attribute called secretserver_user exists for this purpose. Creating and enhancing this field for domain users is outside the scope of this article.

B) Setting up the Identity Provider on the Monokee side​

The next stage is to configure the Identity Provider, let's see what steps are required to accomplish this.

1. Navigate to your Monokee custom fully qualified domain name (FQDN) or if you haven't set up a custom FQDN, go to Monokee's default page and enter your domain ID. Then, enter your login credentials to access your account.

2. Open the left sidebar and select SAML Providers from the menu.

3. This will display a two-tab page, choose the IDENTITY PROVIDERS tab. Click the Add button located in the top right corner.

4. Within the presented modal, in the General configuration section, enter the desired Name for your new provider, such as Secret Server IDP SAML 2.0. Leave all other settings unchanged.

5. For this use case, it is not necessary to specify values for Organization and Contact person, so you can leave the fields of the two reference sections empty.

6. Secret Server supports sending signed SAML Requests, so the flag IDP requires signed authentication requests in Signing options section can be checked.

7. Load your PKCS1 Private Key and the corresponding Certificate in the Signature section. If you want you can generate this key-pair with the following openssl command:

   openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048
   

   A series of information will be asked, here's an example:

   • Country Name: IT
   • State or Province Name: TN
   • Locality Name: Trento
   • Organization Name: Monokee
   • Organizational Unit Name: Monokee SAML 2.0
   • Common Name: 1f414952-d73b-4c79-a3cb-fb5d413fe5fe
   • Email Address: john.doe@example.org
     
     
   caution

   For the Common Name you can use the value of <provider_id> generated by the Entity ID.

   

   This command should output a certificate directly in the terminal and the private key will be placed in a file named privkey.pem. The private key will be in PKCS8 format so it must be converted to PKCS1 with the following command:

   openssl pkey -in privkey.pem -traditional
   

   The new private key will be displayed in the terminal output.

   

8. Left untouched the Single Sign-On Services and Single Logout services configurations.

9. The Attributes section can be left empty, as Secret Server does not require any additional attributes other than the subject.

10. Click the Save button to save the configuration.

11. Now click the button representing a cloud with a downward arrow to download the identity provider metadata file you just created. Upon clicking the button a modal will be opened, so download the file by pressing the Download button without flagging the Request signed metadata checkbox. The file you just downloaded will be needed for Secret Server side configurations.

Secret Server Configurations​

Let's leave aside for a moment the configuration of the SAML 2.0 application on Monokee to complete the part about defining the service provider on the Secret Server side. These informations will then be necessary for the creation of the application on Monokee.

Below is the procedure for importing the SAML 2.0 identity provider details just defined on Monokee to Secret Server and for downloading the SAML 2.0 service provider metadata that is associated with Secret Server.

1. As a first step, access your Secret Server domain. You must use a user with an administrative role.

2. Once logged in, go to the Single Sign-On Settings section, which can be found in the left menu at the Administration > Core Actions > Configuration > SAML. Click on the edit button and check the checkbox of the SAML Enabled option to enable it. Click the Save button.

3. From this screen you can also upload the identity provider configuration previously created on Monokee. Under IDENTITY PROVIDERS section click on Create New Identity Provider. A popup will be displayed with 2 options. Click on the second option which is Import IDP from XML Metadata. Select the file idp_metadata_Secret Server IDP SAML 2.0.xml exported previusly from Monokee.

4. After the successful upload, you will note the Identity Provider is added under this section (You can change the DISPLAY NAME as you like, it will be displayed later on the LOGIN PAGE).

5. Now that the Identity provider has been added, it is possible to download the service provider metadata related to the Monokee configuration. This file will be useful for creating the SAML application on Monokee. Before doing that you need to set a Name that must be identical to the Entity Identifier field in Monokee App by clicking on the Edit button. As an example we choose the SecretServer SP name. A SSL certificate of the Secret Server Public FQDN must be also added by clicking on the "Select certificate" link, in our example it was generated by Let's Encrypt. Click on the Download Service Provider Metadata (XML) button.

We now have all the necessary data to proceed with the creation of the SAML application on Monokee.

C) Create SAML 2.0 Application on the Monokee side​

The last configuration to do before you can test Secret Server access via SAML 2.0 protocol is to create a SAML Application on Monokee by following the procedure below:

1. Navigate to your Monokee custom fully qualified domain name (FQDN) or if you haven't set up a custom FQDN, go to Monokee's default page and enter your domain ID. Then, enter your login credentials to access your account.

2. Open the left sidebar and select Applications from the menu.

3. This will display a list of applications. To create the application, click the Add button located in the top right corner of the table. Then, select SAML Application and click Add.

4. Monokee will open the General Configuration step.

5. Set the Name of you application. For example Secret Server.

6. Leave the URL parameter empty.

7. Optionally, set a Description for your application, for example Secret Server SAML 2.0 integration.

8. Leave the Hide this application from the application broker parameter unchecked, this will allow you to see the application in Monokee Application Broker.

9. You can load an optional application icon using the Load From File or Load by URL options.

10. Skip the Protect with flow configuration. In this way the default Authentication Flow will protect this app.

11. Click Create to proceed to the SAML 2.0 specific configuration. You will be referred to the Service Provider Configuration step.

12. In the Service Provider metadata section you can load the Secret Server metadata previously downloaded. You can load it directly from Load from file input. This operation will automatically fill all the fields on this step.

13. Check the SP signs authentication requests and SP requires signed assertions options and add the public certificate of your public FQDN that you have generated in the previus step "Secret Server Configurations - 5".

    

14. Click Next to proceed to the Additional Configuration step.

15. In the Additional Configuration section, in the Identity Provider input select, choose the identity provider created before Secret Server IDP SAML 2.0, in Signature algorithm choose the value http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 and in Digest algorithm the value http://www.w3.org/2001/04/xmlenc#sha256.

16. All the fields in Identity provider signing options can be checked.

16. Click Next to proceed to the last step Response Statement Configuration.

17. In the Authentication statement options select urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress as Subject format and urn:oasis:names:tc:SAML:2.0:cm:bearer as Subject confirmation method.

18. In the Subject mapping rule you must specify the attribute to be mapped with the subject. To do so, follow the steps:
    • Click the pencil icon next to subject label
    • Click the Add button, a dialog will appear
    • In the Value select present in the dialog choose the attribute secretserver_user
    • Click the Add button in the dialog

19. You can left the Attribute statement section empty.

20. Click the bottom right corner Create button to save the configuration.

You can now associate the newly created application with the users and groups for which you need to grant access to the application.

Time to test the configuration​

It is now time to test the configuration made.

As a first step, we need to value the secretserver_user attribute for all users who are to have access to the application. For testing purposes, you can first do this with your own user. The value of the attribute must match the username of one of the users in the Secret Server domain that you have federated.

We are going to test the configuration in both the IDP initiated and SP initiated scenarios.

IDP Initiated SSO​

In the IDP initiated scenario, the login flow starts from the Identity Provider, so in this case from Monokee. Then go to your application broker and click on the card for the Secret Server application you just created.

The click will cause a new browser tab to open where the SAML 2.0 IDP Initiated login flow will be initiated, after which you will be redirected to the home page of the configured Secret Server domain.

SP Initiated SSO​

On the other hand, to test the SP initiated flow you must go to the login page of your Secret Server domain, at the url https://<my-domain-name>/secretserver.

By clicking on the Demo Monokee SAML link will start the SP initiated login flow which will first authenticate the user according to the chosen security flow and then send back to the home page of the configured secret server domain.

How to use SAML 2.0 protocol to access Salesforce​

An effective way to gain access to a custom Salesforce domain by delegating credential control to Monokee is attaché to the saml 2.0 federation protocol.

In this use case, the user who wants to access Salesforce will not log in through a Salesforce form, but will be redirected to Monokee, which will take care of validating the credentials and communicating the data necessary for user identification to Salesforce, which will eventually log the user in.

The requirement illustrated above describes the context in which Monokee acts as an Identity Provider SAML 2.0, while Salesforce acts as a Service Provider SAML 2.0. Then, the former authenticates the user and provides the latter with the attributes necessary for it to be correctly identified and for it to access the service.

In the following article we explain how the proposed scenario can be put in place; therefore, the steps to be taken on the Salesforce side and the Monokee side in order to achieve a proper SAML 2.0 configuration related to the two providers will be explained.

Monokee Configurations​

In order to get Monokee's domain and Salesforce's domain to communicate properly, you need to do three things on Monokee:

• A Add a custom attribute where the user's identifier will be present on Salesforce
• B Set up a SAML 2.0 identity provider that has the correct parameters to successfully work with Salesforce
• C Configure a SAML 2.0 application with all the parameters related to Salesforce.

The first two points will be explained below, while the third will be discussed in more detail after the necessary Salesforce-side operations are explained.

A) Attribute to Identify the User on Salesforce​

Salesforce allows the user to be identified in two different ways: using the email address used for login or with another attribute that allows the user to be uniquely identified within the custom domain.

In the article, the first case is explored, thus the use of the email address that the user enters when logging in.

It is therefore necessary for the Monokee side to have a custom attribute in which this field is saved for each user in the domain.

It is assumed that an attribute called SalesforceEmail exists for this purpose. Creating and valorizing this field for domain users is outside the scope of this article.

B) Setting up the Identity Provider on the Monokee side​

The next stage is to configure the Identity Provider, let's see what steps are required to accomplish this.

1. Navigate to your Monokee custom fully qualified domain name (FQDN) or if you haven't set up a custom FQDN, go to Monokee's default page and enter your domain ID. Then, enter your login credentials to access your account.

2. Open the left sidebar and select SAML Providers from the menu.

3. This will display a two-tab page, choose the IDENTITY PROVIDERS tab. Click the Add button located in the top right corner.

4. Within the presented modal, in the General configuration section, enter the desired Name for your new provider, such as Salesforce IDP SAML 2.0. Leave all other settings unchanged.

5. For this use case, it is not necessary to specify values for Organization and Contact person, so you can leave the fields of the two reference sections empty.

6. Salesforce supports sending signed Saml Requests, so the flag IDP requires signed authentication requests in Signing options section can be checked.

7. Load your PKCS1 Private Key and the corresponding Certificate in the Signature section. If you want you can generate this key-pair with the following openssl command:

   openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048
   

   A series of information will be asked, here's an example:

   • Country Name: IT
   • State or Province Name: TN
   • Locality Name: Trento
   • Organization Name: Monokee
   • Organizational Unit Name: Monokee SAML 2.0
   • Common Name: 1f414952-d73b-4c79-a3cb-fb5d413fe5fe
   • Email Address: john.doe@example.org
     
     
   caution

   For the Common Name you can use the <provider_id> generated by the EntityID

   

   This command should output a certificate directly in the terminal and the private key will be placed in a file named privkey.pem. The private key will be in PKCS8 format so it must be converted to PKCS1 with the following command:

   openssl pkey -in privkey.pem -traditional
   

   The new private key will be displayed in the terminal output.

   

8. Left untouched the Single Sign-On Services and Single Logout services configurations.

9. The Attributes section can be left empty, as Salesforce does not require any additional attributes other than the subject.

10. Click the bottom right Save button to save the configuration.

11. Now click the button representing a cloud with a downward arrow to download the identity provider metadata file you just created. Upon clicking the button a modal will be opened, so download the file by pressing the Download button without flagging the Request signed metadata checkbox. The file you just downloaded will be needed for Salesforce side configurations.

Salesforce Configurations​

Let's leave aside for a moment the configuration of the SAML 2.0 application on Monokee to complete the part about defining the service provider on the Salesforce side. These information will then be necessary for the creation of the application on Monokee.

Below is the procedure for importing the SAML 2.0 identity provider details just defined on Monokee to Salesforce and for downloading the SAML 2.0 service provider metadata that is associated with Salesforce.

1. As a first step, access your Salesforce domain from the Current my Domain Url, which generally has the format https://<my-domain-name>.my.salesforce.com/. You must use a user with an administrative role.

2. Once logged in, go to the Single Sign-On Settings section, which can be found in the left menu at the Settings > Identity > Single Sign-On Settings path.

2a. If you are using the "Salesforce Classic" version instead of the "Lightning Experience" one, you can find the same entry by clicking on the Setup button in the upper right-hand corner and, from the left-hand menu that will have appeared, to the Administer > Security Controls > Single Sign-On Settings path.

3. From this screen you can upload the identity provider configuration previously created on Monokee. It is recommended to do so through the New from Metadata File button, uploading the metadata file downloaded as explained above.

4. After uploading the file as explained in the Salesforce form, click the Create button. You will be redirected to the configuration import summary page, here you need to give a Name and API Name for the configuration, e.g. Monokee, then click the Save button at the bottom to confirm the import.

5. Therefore, from the final summary pages, it is possible to download the service provider metadata related to the Salesforce configuration from the Download Metadata button. This file will be useful for creating the SAML application on Monokee.

6. Finally, you need to enable the identity provider you just uploaded for it to show up in the Salesforce domain login form. This will allow the user to choose from the login page whether to log in with the default form or to delegate the login to Monokee. To do this you need to access the Authentication Configuration menu area located at the Settings > My Domain > Authentication Configuration path if using the "Lightning Experience" version while at the Domain Management > My Domain > Authentication Configuration path if using the "Salesforce Classic" version. Here you need to click the Edit button, which in both cases will open a new page.

In the opened page Authentication Configuration the available Authentication Services will be displayed. Click the check for the newly added configuration Monokee and then the Save button.

We now have all the necessary data to proceed with the creation of the SAML application on Monokee.

C) Create SAML 2.0 Application on the Monokee side​

The last configuration to do before you can test Salesforce access via SAML 2.0 protocol is to create a saml application on Monokee. Following is the procedure to be performed:

1. Navigate to your Monokee custom fully qualified domain name (FQDN) or if you haven't set up a custom FQDN, go to Monokee's default page and enter your domain ID. Then, enter your login credentials to access your account.

2. Open the left sidebar and select Applications from the menu.

3. This will display a list of applications. To create the application, click the Add button located in the top right corner of the table. Then, select SAML Application and click Add.

4. Monokee will open the General Configuration step.

5. Set the Name of you application. For example Salesforce.

6. Leave the URL parameter empty.

7. Optionally, set a Description for your application, for example Salesforce SAML 2.0 integration.

8. Leave the Hide this application from the application broker parameter unchecked, this will allow you to see the application in Monokee Application Broker.

9. You can load an optional application icon using the Load From File or Load by URL options.

10. Skip the Protect with flow configuration. In this way the default Authentication Flow will protect this app.

11. Click Create to proceed to the SAML 2.0 specific configuration. You will be referred to the Service Provider Configuration step.

12. In the Service Provider metadata section you can load the Salesforce metadata previously downloaded. You can load it directly from Load from file input. This operation will automatically fill all the fields on this step.

13. Click Next to proceed to the Additional Configuration step.

14. In the Additional Configuration section, in the Identity Provider select choose the identity provider created before Salesforce IDP SAML 2.0, in Signature algorithm choose the value http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 and in Digest algorithm the value http://www.w3.org/2001/04/xmlenc#sha256.

15. All the fields in Identity provider signing options can be checked.

16. Click Next to proceed to the last step Response Statement Configuration.

17. In the Authentication statement options select urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified as Subject format and urn:oasis:names:tc:SAML:2.0:cm:bearer as Subject confirmation method.

18. In the Subject mapping rule you must specify the attribute to be mapped with the subject. To do so, follow the steps:
    • Click the pencil icon next to subject label
    • Click the Add button, a dialog will appear
    • In the Value select present in the dialog choose the attribute SalesforceEmail
    • Click the Add button in the dialog

19. You can left the Attribute statement section empty.

20. Click the bottom right corner Create button to save the configuration.

You can now associate the newly created application with the users and groups for which you need to grant access to the application.

Time to test the configuration​

It is now time to test the configuration made.

As a first step, we need to value the SalesforceEmail attribute for all users who are to have access to the application. For testing purposes, you can first do this with your own user. The value of the attribute must match the email of one of the users in the Salesforce domain that you have federated.

We are going to test the configuration in both the IDP initiated and SP initiated scenarios.

IDP Initiated SSO​

In the IDP initiated scenario, the login flow starts from the Identity Provider, so in this case from Monokee. Then go to your application broker and click on the card for the Salesforce application you just created.

The click will cause a new browser tab to open where the SAML 2.0 IDP Initiated login flow will be initiated, after which you will be redirected to the home page of the configured Salesforce domain.

SP Initiated SSO​

On the other hand, to test the sp initiated flow you must go to the login page of your Salesforce domain, at the url https://<my-domain-name>.my.salesforce.com/. Here, in addition to the classic domain login form, a button should have appeared asking if you want to log in through Monokee.

Clicking on this button will start the SP initiated login flow which will first authenticate the user according to the chosen security flow and then send back to the home page of the configured salesforce domain.

If you want to log in to the Salesforce custom domain using only Monokee via Saml protocol, you can do so by navigating to the Authentication Configuration page on Salesforce and disable access via Login Form by unchecking the relevant item and clicking Save.

By so doing, the Salesforce custom domain login page will automatically redirect to Monokee for login without displaying the classic login form.

Accessing Microsoft 365 with Monokee: possible with SAML 2.0 protocol​

Accessing a Microsoft 365 tenant using Monokee is possible using the SAML 2.0 protocol. In this scenario Monokee will act as an Identity Provider (IDP) delivering identities to Microsoft 365 which will then act as a Service Provider (SP).

Specifically, this means that when a user of this Microsoft 365 tenant tries to log in to Microsoft 365, he will be redirected to the login page of the Monokee domain, which will authenticate the user and finally return to Microsoft 365 the user's information required for authentication on his side according to the dictates of the SAML 2.0 protocol.

This article explains how to integrate Microsoft 365 as a SAML 2.0 application in Monokee, starting with the configurations to be made on the Monokee, continuing with Office 365 side configurations and ending with the creation of the SAML application on the Monokee side.

Preliminary steps on the Monokee side​

In order to be able to federate between a Microsoft 365 tenant and a Monokee domain, it is necessary to do some preliminary work on the Monokee side.

In particular, it is necessary for the Monokee domain, and thus the users in it, to have the required attributes that Microsoft will use to identify the user who wishes to log in, and to create the identity provider configuration of the Monokee domain.

User identification attributes for Microsoft 365​

In order to identify the user, Microsoft needs the user's immutableID and email address from Azure.

We therefore assume that two custom attributes exist on the Monokee domain that contain this information, called AzureImmutableID and AzureIDPEmail respectively.

The first attribute AzureImmutableID will be sent as the subject in the authentication SAML Response, while AzureIDPEmail will be used to value an attribute to be included in the attribute statement of the response.

Creating these custom attributes and valuing them for domain users is outside the scope of this article.

Creation of the SAML 2.0 Identity Provider​

We can proceed with the creation of an Identity Provider SAML 2.0 on the Monokee domain.

Below are the steps to follow with the specialized procedure for Microsoft 365.

1. Navigate to your Monokee custom fully qualified domain name (FQDN) or if you haven't set up a custom FQDN, go to Monokee's default page and enter your domain ID. Then, enter your login credentials to access your account.

2. Open the left sidebar and select SAML Providers from the menu.

3. This will display a two-tab page, choose the IDENTITY PROVIDERS tab. Click the Add button located in the top right corner.

4. Within the presented modal, in the General configuration section, enter the desired Name for your new provider, such as Microsoft 365 IDP SAML 2.0. Leave all other settings unchanged.

5. For this use case, it is not necessary to specify values for Organization and Contact person, so you can leave the fields of the two reference sections empty.

6. Microsoft 365 does not send signed Saml Requests, so the flag IDP requires signed authentication requests in Signing options section must remain unchecked by default.

7. Load your PKCS1 Private Key and the corresponding Certificate in the Signature section. If you want you can generate this key-pair with the following openssl command:

   openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048
   

   A series of information will be asked, here's an example:

   • Country Name: IT
   • State or Province Name: TN
   • Locality Name: Trento
   • Organization Name: Monokee
   • Organizational Unit Name: Monokee SAML 2.0
   • Common Name: 1f414952-d73b-4c79-a3cb-fb5d413fe5fe
   • Email Address: john.doe@example.org
     
     
   caution

   For the Common Name you can use the <provider_id> generated by the EntityID

   

   This command should output a certificate directly in the terminal and the private key will be placed in a file named privkey.pem. The private key will be in PKCS8 format so it must be converted to PKCS1 with the following command:

   openssl pkey -in privkey.pem -traditional
   

   The new private key will be displayed in the terminal output.

8. Left untouched the Single Sign-On Services and Single Logout services configurations.

9. In the Attributes section, include the attribute IDPEmail which is the only attribute required by Microsoft 365 in addition to the subject for user authentication with SAML 2.0 protocol. To do so, follow these steps:

   • Click on the Add button on the Attributes section, a dialogue will appear
   • In the dialog, set IDPEmail as the value for both the Name and Descriptive Name fields
   • Click the Add button of the dialogue to confirm the operation

10. Click the bottom right Save button to save the configuration.

How to federate an Microsoft 365 tenant with Monokee​

After completing the preliminary steps on the Monokee side, it is necessary to continue the configuration on Microsoft 365 so that it recognizes Monokee as an external Identity Provider.

Configuration must be done using the Microsoft Azure Active Directory Module for Windows PowerShell.

Once the application is open, you will need to log in with an administrative user using the commands:

$UserCredential = Get-Credential
Connect-MsolService -Credential $UserCredential

The former will show a pop-up asking you to enter credentials, while the latter will take care of the actual connection.

You can for convenience save the domain name in a variable through:

$dom=<microsoft365-tenant-hostname>

where microsoft365-tenant-hostname is the hostname of your Microsoft 365 tenant.

Once connected, to view the current configuration you need to type the command:

Get-MsolDomainFederationSettings

You will then be prompted for the domain name, and once indicated, the current configuration will be displayed.

To change the configuration, it is first necessary to put the domain in Managed mode by typing:

Set-MsolDomainAuthentication -DomainName $dom -Authentication Managed

Now we need to indicate the new configuration parameters, saved on variables:

$entityid=<monokee-idp-entity-id>
$ssourl=<monokee-idp-single-sign-on-services>
$slourl=<monokee-idp-single-logout-services>
$cert=<monokee-idp-signing-certificate>

where the specified fields should be replaced as follows:

• monokee-idp-entity-id is the entity ID of the Identity Provider SAML 2.0 created before, you can find this value in the Identity Provider configuration at the field Entity ID.
• monokee-idp-single-sign-on-services is the location of the Single Sign-On service of the Identity Provider. You can find the correct value on the Identity Provider configuration page, within the Single Sign-On Services section by clicking the down arrow icon next to the urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST string and by copying the value at field Location.
• monokee-idp-single-logout-services is the location of the Single Logout service of the Identity Provider. You can find the correct value on the Identity Provider configuration page, within the Single logout services section by clicking the down arrow icon next to the urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST string and by copying the value at field Location.
• monokee-idp-signing-certificate is the certificate used by the Identity Provider to sign the responses to be sent to the Service Provider. You can find the correct value on the Identity Provider configuration page, within the Signature section by clicking the down arrow of the card and by copying the value at field Certificate.

You can now set these new values using the command:

Set-MsolDomainAuthentication -DomainName $dom -FederationBrandName $dom -Authentication Federated -PassiveLogOnUri $ssourl -SigningCertificate $cert -IssuerUri $entityid -LogOffUri $slourl -PreferredAuthenticationProtocol SAMLP

At this point you can view the new configuration through the command:

Get-MsolDomainFederationSettings

Create SAML 2.0 Application in Monokee​

At this point the only thing missing is to create the saml application on the Monokee side.

The following steps will guide you through the process of setting up the SAML application associated to the Microsoft 365 tenant:

1. Navigate to your Monokee custom fully qualified domain name (FQDN) or if you haven't set up a custom FQDN, go to Monokee's default page and enter your domain ID. Then, enter your login credentials to access your account.

2. Open the left sidebar and select Applications from the menu.

3. This will display a list of applications. To create the application, click the Add button located in the top right corner of the table. Then, select SAML Application and click Add.

4. Monokee will open the General Configuration step.

5. Set the Name of you application. For example Microsoft 365.

6. Leave the URL parameter empty.

7. Optionally, set a Description for your application, for example Microsoft 365 SAML 2.0 integration.

8. Leave the Hide this application from the application broker parameter unchecked, this will allow you to see the application in Monokee Application Broker.

9. You can load an optional application icon using the Load From File or Load by URL options.

10. Skip the Protect with flow configuration. In this way the default Authentication Flow will protect this app.

11. Click Create to proceed to the SAML 2.0 specific configuration. You will be referred to the Service Provider Configuration step.

12. In the Service Provider metadata section you can load the Microsoft 365 metadata, you can find it at this Microsoft 365 url. You can load it directly pasting this url in the field Load by URL. This operation will automatically fill all the fields on this step.

13. Click Next to proceed to the Additional Configuration step.

14. In the Additional Configuration section, in the Identity Provider select choose the identity provider created before Microsoft 365 IDP SAML 2.0, in Signature algorithm choose the value http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 and in Digest algorithm the value http://www.w3.org/2001/04/xmlenc#sha256.

15. All the fields in Identity provider signing options must be kept unchecked.

16. Click Next to proceed to the last step Response Statement Configuration.

17. In the Authentication statement options select urn:oasis:names:tc:SAML:2.0:nameid-format:persistent as Subject format and urn:oasis:names:tc:SAML:2.0:cm:bearer as Subject confirmation method.

18. In the Subject mapping rule you must specify the attribute to be mapped with the subject. To do so, follow the steps:
    • Click the pencil icon next to subject label
    • Click the Add button, a dialog will appear
    • In the Value select present in the dialog choose the attribute AzureImmutableID
    • Click the Add button in the dialog

19. In the Attribute statement section, you must specify the IDPEmail attribute that Microsoft 365 uses to identify user. In order to achieve this, follow the steps:
    • Click New rule and insert IDPEmail
    • Click Add
    • Choose AzureIDPEmail from available items
    • Click Add

20. Click the bottom right corner Create button to save the configuration.

You can now associate the newly created application with the users and groups for which you need to grant access to the application.

Test the correct functioning of the configuration​

To test that the configurations you have made are working properly, you can value the AzureImmutableID and AzureIDPEmail attributes for your user and associate the application with him.

The test can be taken for IDP initiated and SP initiated access.

Regarding IDP initiated access, navigate to application broker, a card related to the newly created Microsoft 365 application should have appeared. Click on it to test that the configuration is working properly.

Upon clicking it, a new browser tab will be opened where you will run the application protection flow and then you will be rendered to Microsoft 365.

To test the SP initiated flow, you can navigate directly to the Microsoft 365 login page, after entering your email, you will be redirected to the Monokee login flow. A as in the previous case, upon login, you will access to Microsoft 365 with your user.

In both cases, if all the configurations have been done correctly, you will log in to your Microsoft 365 restricted area.