Configure a SAML2 data provider with Azure AD

[Carlos_Quispe]

Hello Community,

They will have some experience configuring SAML2 with Azure AD, the MRG documentation is very generic for this type of configuration or perhaps some external documentation that can help me with that configuration.

Thank you.

Hyland IDP

Azure AD:

[AdamShaneHyland · Accepted solution]

Hi Carlos.

In the Hyland IDP admin, the configuration is generic as this allows the SAML provider to be configured for any third party authentication provider which supports the SAML protocol.  Azure AD is one of the many which support SAML.

For Azure AD, you'll need to configure the following ...

• Basic SAML Configuration
  • Identifier (Entity ID): https://hylandidp.domain.com/tenantname/SAMLprovidername
  • Reply URL (Assertion Consumer Service URL): https://hylandidp.domain.com/identityprovider/Saml2/Acs

The User Attributes & Claims will need to be mapped according to your solution and the user attributes you are looking to send back to OnBase.

For the Hyland IDP, you'll need to configure the following ...

• Name: This can be any name, but must be the same as the SAMLprovidername referenced above.
• User Attribute Mapping: These will be the user attributes being mapped to claims in the SAML assertion.
• Identity Provider: This will be the Entity ID of the Enterprise Application in Azure AD identified by the Azure AD identifier. 
• External Idp Metatdata Location: This is a reference to the metadata URL referenced by the App Federation Metadata Url.

There are other settings which may apply such as using HTTP Post for both the Authentication Request Binding and the Assertion Binding.  As well, you will likely want your Signing Algorithm to be RSA-SHA256.  Finally, you may or may not be using Signing and/or Encryption Certificates.  These would need to be configured accordingly.

Best wishes.

[#3 · Accepted solution]

If I can save you even a piece of the frustration I just went through, I am glad to provide you with some of the notes I made. We just finally got our SAML with Azure in the Cloud working with OnBase EP2 and then immediately had to upgrade to EP3 due to a software bug with shared Unity Forms working with the IdP server. There was enough difference between EP2 and EP3 to make me learn it all twice to ensure my settings were in the right place. I am still working on getting the servers working right in a load balance environment, so my notes will not contain mention to that just yet.

Some things that I learned that were not clear to me from only reading the MRG. Firstly, if Azure is in the cloud and your IdP server is not, make sure you have the appropriate firewall rules open to allow communication between the servers. Also, knowing which certificate thumbprint to use in each OnBase config file was a bit confusing to me. The appsetting.json file needs the thumbprint of your SSL signing certificate, while the SAML provider configuration uses the Azure thumbprint. Also, some of the settings in the SAML provider configuration that reference Azure are not clear in the MRG, They are best pulled from the Azure xml metadata file that you will place in a network share accessible to IdP. The value of the Identity Provider field is listed in the metadata file under entityID field. The name of the claims can be found in the xml file as well and should be listed as the full Uri that you see in the metadata file (ie http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name). For us, we used HTTP POST for the Authentication Request Binding and the Assertion Binding. We used RSA-SHA256 for both of the signing algorithm fields. Another thing to note was that Azure needs to be configured to only send a partial list of user groups and not all groups so the header file is not too large. Set it up to only send the OnBase user group a person is a part of and not every group. Also, you can generate an xml file from OnBase to import into Azure after you get the SAML provider configured in the IdP. Do this by going to https://yourserverdomainname/identityprovider/tenantname/samlprovidername/metadata

Hope some of these notes help you out.

[Carlos_Quispe]

Hi Jimmy,

The use of "sAMAccountName" is only possible for objects synchronized from a On-Premise Active Directory, which forces me to create users and groups from the On-Premise Active Directory.

Regards.
CQ

[#5]

yes, our deployment is using Azure AD and it is passing the friendly group name through Azure and in OnBase I have the exact same group names created that they sync up to. It is case sensitive. Every character has to match the group name being passed over.

[AdamShaneHyland]

Hi Carlos.

That is a known limitation of user groups with Azure AD (and possibly other authentication providers) where the user group name matching the OnBase User Group is not sent back in the SAML assertion but instead another attribute value (such as the Azure AD Object ID) is sent back instead.  There is a Feature Request documented by CI-2631 which you can follow by submitting a Support Ticket with your first line of support and asking to be attached to the request.

Best wishes.

[Carlos_Quispe · Accepted solution]

Thanks Renee and Adam,

Following his recommendations I managed to configure the connection. Now I will see how it behaves with other clients (unity client, docpop and others).

I leave screenshots of the settings.

Thank you very much.

Hyland IDP

Azure: