Mechanics of Authentication

[Sharon_Griffin]

Can you explain the communication and verification process between the workstation, OnBase and AD to authenticate the user?

[Andy_Rusnak]

Thanks for posting to the OnBase Community!  In terms of the flow of information during the authentication process, are you looking for the authentication process for a core based module or for the classic OnBase Thick Client?

[Michelle_Proper]

I would like insight into that also. I am interested in the OnBase thick client, the web client and Application Enabler.

[Andy_Rusnak]

Since there is interest in both the Thick Client and Core Products (such as Unity or Application Enabler) I can elaborate on both.  They both follow a similar process, however the application that is actually communicating with AD will differ between the Thick Client and Core Products.  For the Thick Client, the actual client application on the users workstation will be the one reaching out to AD, for core products that will be the Application Server reaching out to AD.  The reason this is important is because the user running the Application Server AppPool will need the ability to reach out to AD and query other users user groups.  Therefore the 'Read Group Membership' rights will need to be granted to that account within AD.  For the Thick Client since the user running the application will always be able to query their own groups, there is no need for any additional permissions in that case. 

Basically the process happens as follows for the Thick Client: 

1.) The Client application will reach out to AD and ensure that the user's credentials are valid.  

2.) The User Groups are then requested from AD

3.) The Client then requests the list of OnBase User Groups from the OnBase database/the mappings configured for User Groups within OnBase to User Groups within AD.  

4.) These two lists are then compared by the Client.  If the user has successful mappings the user will be logged into OnBase.  If there are no successful mappings then the user will not be logged into OnBase.  

For core-based products the process is as follows:

1.) The client workstation will pass the users credentials to the Application Server via IIS protocols. 

2.) The AppServer will take the user credentials validate the user against AD.

3.) If the user is valid, the AppServer will request the list of the users user groups from AD. 

4.) Then the AppServer will reach out to the OnBase Database and request the list of OnBase User Groups and or mappings between OnBase and AD User Groups.  

5.) The AppServer will then compare these two lists and if there is a successful mapping the user will be logged into OnBase.  If there is not a successful mapping the user will not be logged into OnBase.  

[Michelle_Proper]

Thank you for that explanation. The statement "The reason this is important is because the user running the Application Server AppPool will need the ability to reach out to AD and query other users user groups." Is AD read access sufficient for the user running the App Server AppPool? We have AppServer and AppNet app pools. What is the IIS auth configuration for App Enabler if we have AD integration turned on? AppNet Windows enabled and anonymous disabled and App Server anonymous enabled and Windows disabled? We are having some auth issues with App Enabler and I think the IIS set up is the issue. Thanks again!