I'm struggling with setting up an OIDC Provider configuration that also leverages WebSEAL to handle the Authentication to the /authorize endpoint, and the application requesting the access token is protected by this same WebSEAL.

There is a legacy application that runs on standard junctions through a WebSEAL instance, but there are multiple domains that access that WebSEAL, mostly to control which instances in the cluster the user hits. We have eight instances, so there's an online.acme.com that runs against all 8, online-p.acme.com that runs against four, and online-b.acme.come that runs against the other four. We also want to be able to handle requests to each instance directly for testing purposes, so direct to the actual WebSEAL hostname like webseal1.acmeint.org, webseal2.acmeint.org, etc.  

The problem I'm hitting is that i want to be able to control where the entire flow goes through the DNS entries, however the OIDC provider can only be configured with a single issuer. I don't want to set up a dozen provider definitions (which isn't that big of a deal), but I really don't want to force the backend application to need to dynamically change which client ID its using based on the incoming hostname.

We can enable session domain cookies to handle at least the authentication across each domain, but I still need to be able to test the entire flow across just online-p, or direct to a single webseal instance without redirecting out to the singular issuer for the auth code flow.  Is there any way to achieve this without setting up providers for each individual hostname that the webseal instances may encounter?

Hi Brian,

Does your application use OIDC discovery? Because that would indeed complicate the setup.

As long as no discovery is involved, you should be fine. Just as you application junction is accessible via different hostnames, the /sps junction can also be accessible via different hostnames. You just have to choose the correct one when redirecting the user to /authorize.The authorize endpoint doesn't care via which host it is accessed. Of course you have to autorise all possible redirect_uris.

Kind regards,

If you need to change the issuer for the access_token or id_token, you can update the pre-token JS and use the STS to create a customized access token with the issuer (ISS) you want. For example, you can read the HTTP header host and use it as the issuer.
This article may give you some ideas on how to change the issuer:
https://community.ibm.com/community/user/blogs/sumana-narasipur/2018/07/19/oauth-jwt-access-token

And you can customize the OIDC discovery response with the correct host by using a combination of Lua and a static page with macros.
Basically you need a static page in WebSEAL with a custom MACRO like %HOST% in the static HTML page.
The lua transformation will redirect the oidc discovery to this static page. You also can create a new HTTP header using lua and use it in this static page. The macro should be like this: %HTTPHDR{myiss}%


------------------------------
Rudy Santos
------------------------------

Thanks Rudy, that's the path I originally headed down; I modified the outgoing metadata with a lua transformation rule to match the incoming host name, and modified the issuer in the token that gets sent to the target but the target application was still complaining about a mismatch in the issuer.  You mentioned the header, is that the iss query string on the authorize call response?  I tried to modify the stsuu on the post token mapping rule to deal with that but didn't have any luck.

I'm also concerned about the validity of such a configuration.  In a regular scenario the issuer is trusted because of the token validation, but making the issuer dynamic somewhat breaks that trust?

Hi,

The idea is to use the host header to create the access token, using it as the ISS.
But I got your point: if you are thinking about this option, "Include iss in authorization response," then I guess you could use XSLT to change the iss. I've never tried it myself.
For token validation maybe a certificate with Subject Alternative Name (SAN) with all ISS. Never tried too.