02-09-2021 09:32 AM
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:
02-09-2021 11:11 AM
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 ...
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 ...
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.
02-09-2021 01:03 PM
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.
02-10-2021 10:03 AM
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:
02-09-2021 11:11 AM
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 ...
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 ...
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.
02-09-2021 01:03 PM
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.
02-11-2021 08:43 AM
Hi Renee,
In the solution, did you manage to synchronize the Azure AD groups with those of OnBase through names? In my case, if I manage to synchronize but it has to be through the Object ID. In OnBase I have to create groups with names that refer to the Object ID, which at the OnBase administration level will be somewhat complicated to have codes as identification.
Regards.
02-11-2021 09:12 AM
Hi Carlos,
The Hyland IdP is performing a character match in order to map user groups from the assertion to user groups in OnBase. The value passed in the assertion for the role/group claim type has to be identical to the name of the OnBase user group. For example, the "Manager" user group in AD would have to be passed in the assertion with a value of "Manager" in order to map to the "Manager" user group in OnBase.
Typically, the "friendly" group name can be passed rather than the Object ID. This can be accomplished within Azure by using a security group with the "sAMAccountName" as the "Source Attribute". The following Microsoft documentation details that setup further (link).
Jimmy
Find what you came for
We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.