07-13-2021 11:16 AM
Hyland FLOS configured our app server so that the Unity Client and Web Client can authenticate successfully. We are using AD - Enhanced authentication. However, all our custom applications that use the Unity API now fail to authenticate/connect. We are using CreateDomainAuthenticationProperties(). The solution I was given was to stand up a new app server with different authentication properties in IIS just for the API. I thought that the Unity API contained all the functionality that the Unity Client has. So why do I need a second app server? Before upgrading to EP3 we were using OnBase 17 and AD - Basic authentication. Thanks for your feedback/input!
07-13-2021 12:28 PM
Hi Cecelia,
In general it is a best practice to separate out your OnBase Application Server web applications to be specific to the client. For instance, you could have an OnBase Application Server for the Unity Client and another for the Web Server. This way when you have to troubleshoot issues specific to a client, you don't affect users using the other clients. This doesn't mean you need a new server (i.e. VM or physical machine) to host the additional web apps, simply different folders on the server to host the web apps and different Application Pools to service them.
That being said, the Unity Client and the Unity API work off the same basic framework, however they are not identical. Specific to the CreateDomainAuthenticationProperties() method of the Unity API you called out in your question, this assumes the Unity API code is running under the context of a domain user. There are many ways to impersonate a user in an application which is outside of the scope of my comment, however my point is that when using that method, the Unity API is going to attempt to pass the authenticating user up to the Application Server. From there, the Application Server will authenticate the user against Active Directory allowing them access based on successful authentication.
Likely the reason for the different authentication configurations for the respective Application Servers is based on the change to use Kerberos for Authentication with OnBase 18.0.1.67 and higher (link). It is possible that the configurations you need for the Unity API to authenticate against the Application Server are different than the ones used by the Web Server (or any front end web application authenticating against the Application Server via Kerberos) and therefore a recommendation was made to split out the OnBase Application Server in order to have specific authentication settings on the respective OnBase Application Servers.
Best wishes.
07-14-2021 02:58 PM
07-14-2021 05:54 PM
My pleasure
07-13-2021 12:29 PM
I am still waiting on confirmation from my API developers that we use the same connection method (I'm 99% sure we do), but we are running both Unity Client and Unity API traffic through not only the same server but the same application pool and website (a little easier than trying to repeat it the way Roger did above). We had to create a second website on our server to accomodate Disconnected Scanning incompatibility with the IIS authentication settings required when moving from 17 to EP3, but it was not because of the API or Unity Client. We are also using AD-Enhanced currently on 20.3.2.1000.
07-13-2021 01:23 PM
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.