IPSIE IdP Chaining

[deansaxe]

Should IPSIE specify how this behaves in case of IdP chaining? I'm thinking more specifically of a setup like:

• app1 federated to idp1
• app2 federated to idp2
• idp2 federated to idp1 (idp2 acting as a RP)
• (this is an example of sharepoint federated to EntraID itself being federated to Okta)

If I first access to app1, I get authtime set to t0 by idp1 and sent to app1
If I then, 1 hour later, access to app2, idp1 should send t0 to idp2 (provided session is still on). Is that an authentication event from idp2 pov? Should app2 receive t0 or t0+1h?
IMHO app2 should receive t0 (except if idp2 does some additional MFA?) and IPSIE should require an IdP to transfer any authentication time it received if it's acting as both RP and IdP

Originally posted by @teddyber in #89

[deansaxe]

On our planning call today, @aaronpk and I discussed this issue briefly. We'd like to find an author to tackle writing guidance for these use cases that includes:

• How data is propagated from idp1 to idp2 to RP (e.g. amr and auth_time claims)
• How data is propagated from RP to idp2 to idp1 (e.g. max_age and prompt parameters)
• How to translate between protocols (e.g. idp1 federates to idp2 via OIDC, idp2 federates to RP via SAML)

Given the potential complexity, we don't think this will be achievable in time for delivering the implementers draft for the interop, so we will explicitly keep this out of scope for the interop at the end of 2025/early 2026.

@teddyber Are you able to write draft language for this issue?

[teddyber]

OK I'll try to draft something next week. And yes I foresee some complexities when translating between protocols...

[deansaxe]

Thanks @teddyber.

Perhaps to avoid any issues with protocol translation we can specify that any chaining of IdPs requires the use of the same protocol across each hop in order to be IPSIE compliant? I worry that this eliminates a potentially useful integration pattern that I have seen in the wild. Once you've had a chance to write a bit on this topic, let's review with the WG members and gather their input on protocol translation.

[mcguinness]

Flowing auth context across IdP hops feels very specific to the trust agreement and deployment model. IdP hops may also enforce their own policy and not trust a issuer. Additionally some intermediates may just be brokers and want to abstract complexity to an RP. The auth_timr:amr tuple becomes something more likeauth_time:amr:issuer.

[sbroddy]

FWIW, I would guess that somewhere north of 90% of commercial IdPs are proxied in the R&E enterprise world due to lack of feature support in vendor IdP implementations. It's not really a question of if, it's more a question of how in R&E.

This is a well discussed reality/problem in the R&E space. There's even a company that was entirely founded to fill that niche.

[deansaxe]

This is a well discussed reality/problem in the R&E space. There's even a company that was entirely founded to fill that niche.

I would appreciate any data you can point us to from R&E that will help us. If standards exist, we should look at using them if they are compatible with IPSIE.

[sbroddy]

Here's a couple of documented architectures from Microsoft.
https://learn.microsoft.com/en-us/entra/architecture/multilateral-federation-solution-two
https://learn.microsoft.com/en-us/entra/architecture/multilateral-federation-solution-one

This doc is more around policy/trust than it is technical architecture:
2024 InCommon Federation Proxies Working Group Report

There's quite a bit about proxies in the AARC blueprint architecture docs.
https://aarc-community.org/architecture/

There's lots of other docs out there. There are also proxies out there to provide access to things like HPC clusters, but I suspect that is more out of scope than SAML/OIDC proxies are. E.g. SAML->x509 for SSH access. (https://www.cilogon.org/)

A presentation from 2023 TechEx about proxying azure:
https://internet2.edu/wp-content/uploads/2023/09/techex23-azureadproxy-johnson.pdf

2022 presentation from TechEx (middlethings, e.g. proxies)
https://internet2.edu/wp-content/uploads/2022/12/techex22-IAM-Rise-of-Middlethings-Wu.pdf

At least in R&E, proxies are here to stay especially given the lack of feature support in vended IdPs. This spills over into things like research hospitals, federal agencies (NIH, NSF, ...), and other sectors that one may not think of as having the same needs as R&E.

[ttripp]

The following could be a framework for describing the required behavior, and we could debate on SHOULD vs MUST.

How data is propagated from RP(s) to IDP(s) (Upstream)

When an RP initiates a login, it sends parameters that define the authentication requirements. The intermediary (IdP2) MUST interpret these parameters and propagate them upstream to IdP1 to ensure the original request is honored.

max_age: This parameter restricts the maximum allowable age of an authentication session.

Guidance: When IdP2 receives a request with max_age, it SHOULD forward the max_age parameter to IdP1. If IdP2 has its own active session with the user, it MUST first validate that its own session meets the max_age requirement before relying on it. If not, it MUST treat the request as if a re-authentication is required from IdP1.

prompt: This parameter requests a specific user interaction.

Guidance: If the RP sends prompt=login, IdP2 MUST ensure a fresh authentication occurs. It SHOULD propagate prompt=login to IdP1 to force a new login there. If the RP sends prompt=none, IdP2 MUST return an error if it cannot fulfill the request without user interaction. It should propagate prompt=none to IdP1 when checking for an existing session.

How data is propagated from IdP(s) to RP(s) (Downstream)

After the user authenticates at IdP1, IdP2 receives an identity assertion. IdP2 then constructs a new assertion to send to the RP. It is responsible for setting the claims in this new assertion correctly.

auth_time: This claim specifies when the authentication occurred.

Guidance: The auth_time claim sent to the RP MUST reflect the timestamp of the most recent authentication event in the entire chain that was performed for the current transaction.

If IdP1 authenticates the user at T1, and IdP2 performs a step-up authentication at T2, the final auth_time SHOULD be T2.

If IdP2 relies solely on the session established at IdP1 at time T1, the final auth_time SHOULD be T1.

amr (Authentication Methods References): This claim lists the methods used for authentication.

Guidance: The amr array in the final assertion SHOULD be a union of the authentication methods performed across the entire chain. If IdP1 returns ["pwd"] and IdP2 performs a step-up using mfa, the amr array sent to the RP SHOULD contain both values (e.g., ["pwd", "mfa"]).

[canders3]

amr (Authentication Methods References): This claim lists the methods used for authentication.

Guidance: The amr array in the final assertion SHOULD be a union of the authentication methods performed across the entire chain. If IdP1 returns ["pwd"] and IdP2 performs a step-up using mfa, the amr array sent to the RP SHOULD contain both values (e.g., ["pwd", "mfa"]).

While I fully agree with the premise here, I wonder where the line ends and if we should ask IdPs to be more specific / transparent on how the authentication event actually occurred. In your example the RP is meant to assume that ["pwd", "mfa"] occurred at the IdP they know about (IdP1 for example), though in reality it was likely something more like this: ["pwd", "federated-mfa"]; which indicates that the "mfa" method was not done by IdP1 but instead by a third party federated IdP (IdP2).

In my opinion, at least for now, your guidance is probably the right guidance, and this nuance likely goes beyond IPSIE. However, your example made me question just how far one should be asked to go? Is a union enough? Maybe, probably. Is it truly transparent and truthful yes, well, to a degree. The real question becomes, how transparent does an SP/RP care / should care to know? That I don't know.