This document explains how to configure L2L to use Microsoft's Azure SAML services to log in to L2L DISPATCH.

Step 1: Create the L2L SAML Config

We first create a new SAML Config that defines the SAML Trust between Dispatch and Azure. Log in to [customer].leading2lean.com, and navigate to Setup → IT Setup → SAML SSO Config. Click the Add New link.

In the Add New SAML Config page, enter the following information:

• Code: this must be a unique code among all the Dispatch SAML Config’s and gets used in the Dispatch SAML URL’s.
• Display Name: This is user visible text on the Dispatch login page.
• IdP User Naming Attribute: You need to choose how users will log into Dispatch. Choosing email requires that the Dispatch user accounts have their email addresses set to the same email address set on users’ Azure accounts, and choosing username requires that the Dispatch username matches the Azure username.
• Leave all the other fields blank for now and click Save. The remaining fields will be configured using values from the Azure Application in Step 3 below.
• Now click on the new SAML Config that you just created. We'll use the SP Initiate, SP SSO URL, SP SLO URL, and SP Entity ID in the next step.

Step 2: Create a new Application in Azure

1. Create a new Application
   1. Go to All Applications → New Application. Click New Application. Select Non-gallery application. Name your new Application and click Add.
2. Select Configure single sign-on and select SAML.
3. Section 1: Enter the following L2L URLs into the Azure Application. Be sure to include the trailing slash.
   

   L2L URL	Azure Application Setting
   SP Entity ID	Identifier (Entity ID)
   SSO URL	Reply URL
   SSO URL	Sign on URL
   SLO URL	Logout URL

4. Section 2: Set the Unique User Identifier.
   1. If you chose email for the IdP User Naming Attribute in L2L, select user.mail.
   2. If you chose username for the IdP User Naming Attribute in L2L, select user.userprincipalname.

Note about IdP-initiated SSO: For applications that support IdP-initiated SSO, Microsoft Azure/Entra provides the ability to authenticate into a registered application through the "My Apps" web portal. L2L does not support IdP-initiated SSO natively, however, this functionality can be emulated by configuring the Login URL in Azure/Entra to use the L2L SP Initiate URL instead of the of the IdP SSO URL. 

Step 3: Update the L2L SAML Config

1. Download the Certificate (Base 64) from Section 3 in the Azure Application and copy/paste it into the IdP Certificate Information field on the L2L SAML Config Detail screen under the x509 Public Certificate in PEM format tab.
2. Enter the following Azure URLs from Section 4 in the Azure Application into the L2L SAML Config Detail screen:
   

   Azure URL	L2L SAML Config Detail
   Login URL	IdP SSO URL
   Azure AD Identifier	IdP Entity Id
   Logout URL	IdP SLO URL

Step 4: Configure Users in L2L

Now it's time to tie users to a SAML config. You will not be able to use SAML until you have configured a user to use the new SAML config. You can do this two different ways.

One user at a time
Select the appropriate SAML Config setting in the Edit User screen. You can only select one SAML Config setting per user.

Migrate Users tool
If all users registered to a site will be using SAML to authenticate, you can use the SAML Migration tool. This is found at the bottom of the SAML Config Detail screen. Just click the Migrate Accounts button and follow the instructions.

Step 5: Test

1. Go to https://[customer].leading2lean.com and click on the new SSO button. The title of this button will come from the Display Name in the L2L config above.
   1. If prompted, enter your credentials.
   2. You should be logged in to L2L DISPATCH
2. Log out of Dispatch
   
   1. You should be logged out of L2L DISPATCH

Troubleshooting

• Cannot log out
  Sometimes a User can successfully log in to L2L using the SAML route, but cannot log out. If this is the case, try to use the following logout URL in the L2L SAML Config Detail → IdP SLO URL field:
  

  https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0

• Cannot log in
  If there is a mismatch in expected authentication methods between Azure and L2L, this error might appear:
  
  "AADSTS75011: Authentication method 'X509, MultiFactor, X509Device' by which the user authenticated with the service doesn't match the requested authentication method "Password, ProtectedTransport". Contact the Leading2Lean application owner."
  
  By default, L2L enforces the authentication method Password, ProtectedTransport through the requestedAuthnContext field in the SP-Init request. If Azure is configured to allow X509, Multifactor, X509Device authentication, and a user authenticates with this method, then attempts to log into L2L with SSO, L2L will not accept it, and Azure will present this error. 
  
  There are two new optional settings in the SAML Config page that allow you to modify the requestedAuthnContext field. They are found under the Advanced Settings tab in the new Behavior Settings section on the SAML Config page. These optional settings include:
  
  - Disable requestedAuthnContext
  - Include "Unspecified" in the requestedAuthnContext (experimental)
  
  
  
  

  To allow Azure to enforce it's own authentication requirements, either of these options can be selected. It is recommended to first try enabling Include Unspecified in requestedAuthnContext (experimental) to resolve this error. If the error is not resolved, or a new error is generated, disable this option and enable the Disable requestedAuthnContext option. After changing any of these settings, be sure to save the configuration. After saving, log out of L2L and try logging in again with SSO. 
  
  Important Note: Both of these options will give complete autonomy to the Identity Provider to enforce it's own methods of authentication. These options are also mutually exclusive, so only enable one of the two at a time.
  
  There is some inherent flexibility in the implementation of SAML across different Identity Providers (IdPs). Some IdPs ignore the requestedAuthnContext value and proceed with their default authentication method. Some may treat Unspecified as an explicit request to use any available authentication method. Others may default to a preconfigured authentication method, such as Password, ProtectedTransport or MFA. 
  
  Due to this inherent flexibility, it is crucial to test these options thoroughly by attempting to access L2L through SSO after authenticating with your IdP through any method that your organization supports, whether that be username/password, MFA, certificate-based, or others.