Specifying an IdP Provider to avoid the prompt upon login

[Steven_Zeltner3]

Hello!  In Hyland IdP Server 2.11, is it possible to configure a client/consumer to point to a specific Auth Provider that is configured in the IdP?  The use case would be something like:

I have two Auth Providers wired into the IdP via SAML2 (both using Auth0 but in different Auth0 Tenants), I want one of them to use Auth Provider A and the other to use Auth Provider B.  I want to avoid having them click the provider button when they attempt to login.  The more specific use case would be for docpop links exposed via different Web Portals:

User A that belongs to Auth Provider A came in through Web Portal A to access Doc A

User B is authenticated via Auth Provider B and came in through a different Web App in the organization (Web Portal B).  They want to access Doc A through the same Docpop link/Web Server that is wired to the Hyland IdP

To put it another way:

To date, we've been successful passing the Auth Provider A context (from Web Portal A) through the IdP to the Docpop link and having it successfully authenticate and authorize access as the appropriate OnBase User as long as they're accessing the link from a browser that already logged in to Web Portal A.  The new wrinkle is adding a second provider (even if it is "Allow users to logon locally") prompts the user to choose a path.  Is there a way to avoid this?

We've prototyped a few workarounds (using token auth for Unity API to do the retrieval and presentation of the page data) but we are on EP4 and I feel like there were issues doing that with EP4 but I can't remember the specifics.  In any case, the docpop links are the preferred route.

Thanks!

[Ryan_Wakefield]

Thanks for the confirmation. This is really good, especially since it would allow a single IdP instance to potentially connect to multiple SAML providers which means maintenance and more is much MUCH easier, especially when it comes to cutting off permissions. LOL

[AdamShaneHyland]

Hey @Ryan Wakefield ,

My pleasure.  Thanks for calling it out.  With the release of 2.10.0, the Hyland IDP supports multiple SAML providers by enabling the UseNewSamlModulePath setting. 

The setting that you referenced is at the Client level and allows an admin to limit, or more specifically specify, which providers (of any type, not just SAML) are associated with the Client.

Best wishes.

[Steven_Zeltner3]

Hello!  Sorry for the delay.  Thanks to this post we were able to find a mostly-clean solution.  Here's some more background (as it was pitched to the powers that be...) in case it helps someone:

The provider portal uses OnBase DocPop to expose links to documents:

Since our move to Azure, OnBase has been secured by Auth0 via Hyland’s Identity Provider Server (Hyland IdP) using SAML.

Think of DocPop as a feature of the OnBase Web Server.  An OnBase Web Server Web Application can be tied to a single Hyland IdP Client.  A Client can utilize all Providers configured in the Hyland IdP. 

However, unless a single provider is specified, the user will be prompted with a choice to choose how to authenticate

Users will not know which to click unless they are privy to their Auth0 Tenant… (they won't be)

So mapping One Web Server to One Tenant means locking down a specific Client to a particular Provider

This also means creating an OnBase Web Server Web Application for each Provider/Tenant as that is a 1:1 relationship

Having multiple Web Server Web Apps is not a huge lift and the OnBase Team would manage that.  We would just need to agree upon a mapping of tenant to Web Application Name.

There are two other components that are needed to support the approach:

1. From the UI side, massaging of the DocPop URL published on the portal would need to occur.  The docpop link will need to have “appnet” replaced with appnet<tenant> based on the agreed upon naming scheme

Example:

https://HOST/appnet/docpop/...

https://HOST/appnet<friendly-tenant-name>/docpop/...

1. From the Auth0 Side, the same approach taken for the tenant regarding the Auth0 Authorization will need to occur on each of the other Auth0 tenants
   1. Install Auth0 Authorization extension
   2. Create Groups that match the names of the OnBase Groups
   3. Manage the users as they are added and removed from the other tenants

There may be fancier ways to do that Auth0 Authorization and user management but I based the approach on what is working for our other portals.

Using the useNewSamlModulePath and filling in the Identity Provider Restriction allows us to bind a Web Server to a Provider

The other option (much larger lift) might be to resurrect the token based approach that we worked on a while backwhere the token flow was being used instead of auth0.  This would probably require:

• An OnBase EP5 Api/App Server (we're on EP4)
• User-specific token creation on the UI side for auditing purposes of Document Views
• Possibly needing to temporarily stream the document data from OnBase and present it in a frame in the UI instead of opening it in DocPop