Do we really need 2 app servers in order to get domain authentication to work with Foundation EP3 Unity API?

[Cecelia_Rocha]

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!

[AdamShaneHyland]

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.

[Cecelia_Rocha]

@Adam Shane Thank you so much for your clear and detailed explanation.  I was told by FLOS to create a second app server with different authentication configuration for the API clients and this worked but I thought it was a kludge of sorts. lol  Your last paragraph hit the nail on the head! Thanks! 

[AdamShaneHyland]

My pleasure @Cecelia Rocha .  Happy to help.

[Rob_Keberdle]

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.

[AdamShaneHyland]

Hi @Rob Keberdle , you can use the same Application Server for the Unity Client and Unity API (or any other remote application like the Office Business Application, etc).  The problem is when you have a front end web app (OnBase Web Server, OnBase Patient Window, Deficiency Pop, etc) which connect to the same Application Server.