search string side menu

ELMA365 Store solutions > SAML integration  / SAML integration with Windows Server

SAML integration with Windows Server

SAML integration allows using Windows Server to authenticate and automatically create internal and external users in ELMA365.

During authentication in ELMA365, a new internal user is created, and an entry is added to the Users directory. If the user is being authenticated on the portal, then an entry is added to the External users directory. If you want an unregistered user to sign in to the portal with SAML, you do not need to send them a personal invite link. All you need to do is send them a link to the portal.  

Please note that for SAML integration with Microsoft Azure additional settings in Azure are required. To learn more, see SAML integration with AZURE.

Configuration

To set up the SAML module, you must have a valid SSL certificate for signing Service Provider requests.

  1. Go to Administration > Modules > SAML.
  2. Select the Enable Module checkbox and click Add item. A service provider settings window opens.
  3. In the Name field, specify the service provider name.
  4. In the Metadata IdP URL field, specify the metadata URL of your AD FS server (for example, https://your-domain.com/FederationMetadata/2007-06/FederationMetadata.xml).
  5. Fill in the Public key field with your public key taken from the .pem file and formatted as a string.
  6. Fill in the Private key field with your private key taken from the .pem file and formatted as a string.
  7. Switch the Create users at authentication option to Yes so that the system can create new users automatically when a user who doesn’t have an account tries to sign in.
  8. Switch the Update existing users option to Yes if you need to update the existing users upon authorization. This update will turn users into external SAML users, and they won’t be able to sign in as before.
  9. Click Save. If service provider settings are saved successfully, the link to the file with metadata will be displayed in the URL field.
  10. Follow the metadata URL link and save the service provider metadata as a .xml file. You will need it at the next step when setting up the AD FS server.

System behavior according to the “Create users at authentication” option

If the Create users at authentication option is enabled, the users who are not logged in will be created with the ability to sign in via SAML, regardless of whether SAML integration is associated with AD/LDAP integration or not.

If the Create users at authentication option is disabled, the users who are not logged in will not be able to sign in.

System behavior according to the “Update existing users” option

The enabled Update Existing Users option is defining the updating of invited or imported users from the AD/LDAP integration not associated with SAML. During the upgrade, such users are converted to SAML users and in this case they will no longer be able to log in in the previous way.

When the AD/LDAP integration is associated with SAML the AD/LDAP users are not updated when authorized through SAML, regardless of the setting of the Update Existing Users option. Such users have the ability to authorize both through AD / LDAP and through SAML.

Configure the associated AD/LDAP integration

You can import users from AD/LDAP and set up their authentication via SAML. To do this, go to the settings of the corresponding AD/LDAP integration and select the previously created SAML integration in the Authentication Type field

Configure authentication on the AD FS server

Once you have set up the integration with the SAML provider and obtained the medatada file, configure the AD FS server.

The instructions in this article are for Windows Server 2016. For other OS versions, the steps may be different.

To configure the authentication on the AD FS server, follow the steps below.

Create a Relying Party Trust

According to AD FS requirements, you must create a relying party trust for each service provider that uses the AD FS server for authentication.

To create a new relying party trust:

  1. Sign in to your AD FS server and start Server Manager.
  2. Open the management console AD FS: Tools > AD FS Management.
  1. In the Actions panel, click Add Relying Party Trust.
  2. The Add Relying Party Trust Wizard window opens. On the Welcome page, choose Claims aware and click Start.
  3. On the Select Data Source page, click Import data about the relying party from a file. Click Browse next to the Federation metadata file location field, select the metadata file you got at the SAML integration setup step earlier, and click Next.
  4. Specify a name for the relying party trust, for example, ELMA365, and then click Next.
  5. On the next page, choose the access control policy.  The pre-selected Permit everyone policy provides access to the relying party trust for all users.
  6. On the Ready to Add Trust page, review the settings and click Close.

Configure claims mapping

AD FS sends a SAML authentication response with confirmation to the service provider on the successful authentication of a user. For valid user authentication, user data must be mapped to SAML response items.

To do this:

  1. In the console tree, under AD FS, click Relying Party Trusts. Right-click the trust you have created earlier, and then click Edit Claim Issuance Policy.
  2. In the window that opens, click Add Rule.
  3. From the drop-down list of claim rule templates, select Send Claims Using a Custom Rule, and then click Next.
  4. On the Configure Rule page, under Claim Rule Name, type the display name for this rule, "CustomRule1", for example. Under Custom Rule, specify the claim rule:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = 
("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/windowsaccountname", 
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", 
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", 
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", 
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/externalCode", 
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname", 
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", 
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone"), query = 
";sAMAccountName,displayName,mail,givenName,distinguishedName,sn,userPrincipalName,telephoneNumber;{0}", param = c.Value);

Click Finish.

Important notes:

  • You must add the fields: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/windowsaccountname", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/externalCode".
  • The value of the "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/externalCode" field must match the value of the "DN" Parameter field from the associated AD integration. This field identifies an existing user when converting from an AD user to a SAML user and vice versa.
  • The value from the sAMAccountName field is used as a login, if you need an email formatted login, use the value of userprincipalname field.
  1. Click Add Rule again to enter another rule.
  2. From the drop-down list of claim rule templates, select Send Claims Using a Custom Rule, and then click Next.
  3. Under Claim Rule name, specify the display name for this rule, "CustomRule2", for example. Under Custom Rrule, specify the claim rule:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"] => issue(Type = 
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, 
OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, 
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = 
"urn:oasis:names:tc:SAML:2.0:nameid-format:transient");

Click Finish.

  1. Click OK to save the rule.

 

 

ad-ldap-troubleshooting.html saml-with-azure.html

Found a typo? Highlight the text, press ctrl + enter and notify us