Tips & tricks for installing and running IBM products

Virtual host junctions and federation on ISAM

Tom Bosmans  9 August 2019 10:15:40
I recently struggled with a setup of an OIDC federation setup on IBM Security Access Manager.

Instead of using standard, transparant path junctions, I was now using Virttual Host Junctions.
And I could not get the federation to work.

After a while, the penny dropped , and I realised that the /mga junction is not avaiable in the Virtual host junction.  Which I should have realised from the beginning of course...

So there's 2 options

match-vhj-first and session sharing

The "match-vhj-first " is set to yes by default, and this means that you cannot access the /mga junction (and hence cannot kick off the federation etc).  Set this parameter to "false", and the /mga junction is available in the Virtual Host Junction.
For federation, you may get away with just that change, as long as you setup seperate federations per virtual host.

See this older article by Philip Nye on the related topic of Context Based Access control:

Single federation per Reverse Proxy instance and session sharing

For the OIDC Federation, I opted for a slightly different approach though.  There is no real need to change the default "match-vhj-first" setting.  What is important in setting up Federations, is that the hostnames used are constant throughout the OIDC federation flow.  And by setting up a "master" federation partner, I can kick off federation on all virtual host junctions on the same reverse proxy - no need to change anything in the federation setup when adding a new virtual host junction.

Webseal configuration

In the Webseald.conf configuration file , I set fhe following parameters:

match-vhj-first = yes

domain = mydomain.tld

shared-domain-cookie = yes
tcp-session-cookie-name = PD-H-SESSION-ID-rp1
ssl-session-cookie-name = PD-S-SESSION-ID-rp1

This enables the sharing of the webseal session between the junctions (including virtual host junctions) within a reverse proxy (webseal).
This is not necessary if you use DSC , and this does not work if you don't have a single "cookie domain" .


Key here is to have a single OIDC Federation set up against the "base" webseal reverse proxy, eg. the ip address or hostname you used to setup the reverse proxy.

The URLs to use in the Federation components (  redirectUriPrefix, providerId ) need to point to that base webseal reverse proxy.
Make sure to not mix the hostnames here, because then the Federation will fail.

If you enabled local-response-redirect, you can then use the following kickoff URL to start the Federation.

local-response-redirect-uri = https://mywebseal.mydomain.tld/mga/sps/oidc/rp//kickoff/

After a successful federation, thanks to the session sharing, you are also logged into your Virtual Host Junction.

No Comments Found