Hi community,

When configuring a reverse proxy for federation, you need to configure a runtime junction. Documentation explains (and strongly recommands) to use a (normal) /isam junction for that.

However, migrating from an TFIM environment (where the PoC URL was https://$hostname/sps/...) this would mean that various URLs would need to change (ex: login endpoints when acting as IDP and ACS url's when acting as SP).

Would it be possible to use a transparant path junction /sps to a runtime endpoint as an alternative?
Has anyone tried something like that? Are there any caveats/known issues?

Thx in advance

------------------------------
Kristof Goossens
------------------------------

Hi Kristof,

From my experience, I believe that it does work for some of the runtime exposed services. I know historically that TFIM did also have the /FIM junction which was set up towards the TFIM runtime in some cases.. either way;

I believe this is recommended to separate the streams between AAC (/mga junction) and FED (/isam junction), even though the same runtime instance is being accessed. 
It is important to note that there are slight changes in terms of URL endpoint patterns for OAuth2 between ISAM and TFIM (federation name being replaced with oauth as this has now been organized differently within ISAM AAC).

And I believe the AAC and FED runtime configuration options from the LMI assume this aswell, so you would be better off by moving to this setup instead.

Assuming that both TFIM and ISAM FED exposed through the same ISAM webseal, then I would probably test this by introducing a HTTP transformation rule for /sps triggering a URI rewrite to /isam/sps (or have a go at JMT) and check the results.

------------------------------
Abdel Hamrioui
------------------------------

Hi Abdel,

Thx for your insight.

We will set up complete new environments, so we don't have the same webseal instance in front.
Luckily we don't have to work with rewrite rules and JMT, as it increases complexity somewhat and introduces  a point where I can see things go sideways :)

We used to use TFIM only for SAML, so changes for other protocols are not an issue in our setup.
I do agree that it is better to keep AAC and FED separate, but I think we'll do that by creating another junction for AAC.

It's important that the TFIM/FED urls can stay the same, but AAC is new, so we don't have any requirements for those endpoints.

Kind regards

------------------------------
Kristof Goossens
------------------------------

Original Message:
Sent: 02-06-2019 05:14 AM
From: Abdel Hamrioui
Subject: /isam runtime junction for federation module

Hi Kristof,

From my experience, I believe that it does work for some of the runtime exposed services. I know historically that TFIM did also have the /FIM junction which was set up towards the TFIM runtime in some cases.. either way;

I believe this is recommended to separate the streams between AAC (/mga junction) and FED (/isam junction), even though the same runtime instance is being accessed. 
It is important to note that there are slight changes in terms of URL endpoint patterns for OAuth2 between ISAM and TFIM (federation name being replaced with oauth as this has now been organized differently within ISAM AAC).

And I believe the AAC and FED runtime configuration options from the LMI assume this aswell, so you would be better off by moving to this setup instead.

Assuming that both TFIM and ISAM FED exposed through the same ISAM webseal, then I would probably test this by introducing a HTTP transformation rule for /sps triggering a URI rewrite to /isam/sps (or have a go at JMT) and check the results.

------------------------------
Abdel Hamrioui
------------------------------