06-02-2022 10:06 AM
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!
06-02-2022 03:04 PM
Hi
I stand corrected. Good find. You can use the Identity Provider Restrictions to accomplish this. The field requires the Id of provider(s) which the Client should be restricted to.
This would alleviate the need to configure multiple instances of the Hyland IDP as different Clients could be configured and limited to specific Providers. The respective unique Client Id's generated within the Admin UI would then be used during configuration of the client applications in order to direct users to the respective Provider.
Best wishes.
06-02-2022 04:30 PM
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
06-03-2022 05:51 AM
Hey
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.
06-24-2022 07:34 AM
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:
Example:
https://HOST/appnet/docpop/...
https://HOST/appnet<friendly-tenant-name>/docpop/...
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:
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.