I recently struggled with a setup of an OIDC federation setup on IBM Security Access Manager. Instead of using standard, transparent path junctions, I was now using Virtual Host Junctions. And I could not get the federation to work.

After a while the penny dropped. 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
  • single federation per Reverse Proxy instance and session sharing

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: https://www.ibm.com/developerworks/mobile/library/se-accessmanager/index.html

To enable Single Sign on between your virtual host and base webseal ( that now are accessed on the same hostname ), you do need to enable shared-domain-cookies. You don’t need to define a domain, the standard host-based cookie is fine.

The infocenter explains this in more detail: https://www.ibm.com/docs/en/sva/10.0.4?topic=hosting-virtual-host-junction-solution

[junction]
match-vhj-first = no  

[session] 
shared-domain-cookie = yes

Other approaches would be to use DSC or Redis for session sharing.

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:

[junction]  
match-vhj-first = yes  
  
[session-cookie-domains]  
domain = mydomain.tld  

[session]  
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 or Redis Session Sharing, and this does not work if you don’t have a single “cookie domain” .

Federations

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]  
local-response-redirect-uri = https://mywebseal.mydomain.tld/mga/sps/oidc/rp/<oidc1>/kickoff/<oidc-partner>

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