saml proxying scoped attributes...best practice

[Bobby Lawrence]

Thanks for this Scott.

Yes - I control the SPs.  I want them to be able to signal to the IdP that they will accept authentication via an upstream IdP (invoking the proxy behavior).  This will be handled via Extensions (either in metadata or AuthnRequests or both). If the Extension is set, the IdP will show a link or something on the login view which will allow the user to bypass the default authn/Password flow and instead go into the authn/SAML flow (and trigger discovery, etc).

Because I control the SPs, I can turn off the EPPN scoping check, but I'm thinking maybe this isn't a great idea now.  Perhaps I need to instead pass the upstream EPPN through as a different attribute and simply have the IdP not resolve an EPPN at all.  Then on the SP side, tell it to use either EPPN or this other attribute as the remote-user.  

You are correct in assuming that I'm producing the EPPN via the principal name.  I guess I need to change that so that its produced via some other attribute.  We do have an LDAP data connector so I can instead produce it via the LDAP uid.  To do this I will need to make the IdP resolve the "uid" attribute (urn:oid:0.9.2342.19200300.100.1.1) from the principal instead of from LDAP and change the SPs so that they will accept either an EPPN or a uid as the remote-user.

Do you think using uid/urn:oid:0.9.2342.19200300.100.1.1 in this manner is OK?

The only real issue I can see with this maybe something that isn't a big deal...
Our IdP is in InCommon and so it is encouraged to produce an EPPN (or eduPersonUniqueId/editPersonTargedID).  In this proxy scenario, my IdP wont produce any of these attributes.  I think I can control how/when this workflow is triggered (via metadata and AuthnRequest Extensions) so only the SPs I manage can trigger it.  I just don’t want an SP from InCommon to be able to signal it expect one of these missing attributes.


-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Thursday, November 07, 2024 8:19 PM
To: Shib Users <users at shibboleth.net>
Cc: Bobby Lawrence <robertl at jlab.org>
Subject: [EXTERNAL] Re: saml proxying scoped attributes...best practice

> For the most part, it seems like the InCommon community has 
> “standardized” on using eduPersonPrincipalName as the user identifier 
> but I’m not entirely sure how to handle this in a proxy scenario.

EPPN is pretty unstable in practice a lot of the time. It's ubiquitious, but so is email address, and neither are good identifiers in practice because they usually have to match for life not to be painful for the IdP.

The well-defined choices (subject-id, pairwise-id) are poorly supported. That's just how it is, I'm not sure it will ever change in the SAML world, we screwed up to start with and waited too long to produce a workable answer.

> So I guess my question is this…how should I be handling EPPN that 
> comes back from the upstream IdP?

To start with, you have to control all the SPs or they're going to reject a passthrough scoped value anyway (if using Shibboleth). You aren't authorized to assert all those scopes unless you specifically get them to accept metadata about your IdP saying so, or turn off the check. And you'd have to maintain that list of scopes in your metadata.

So I assume for practical purposes you do control that issue somehow.

> I’d like to send it downstream unmolested to the SP, which means I’d 
> actually like to NOT apply the IdP scope, but I DO want to apply that 
> scope for the non-proxying scenarios like when I build it via the 
> password principal.

I imagine the problem is you're producing the non-proxied one based on the principal name, which is there in proxied cases also (via EPPN, sounds like), so you need to ensure it's not produced in the proxy case.

Probably the most understandable way to do this would be to use a Script to build EPPN, and have it run against the Subject DataConnector as a dependency supplying the proxied EPPN (which you could apply a custom ID to via decoding so it's "separate").

The script could then detect if that separate ID were fed in and pass it along into EPPN, or build it the way it would normally get built.

> Should I transcode the upstream EPPN into a different attribute so 
> that its not scoped?

No, but decoding into a different name lets you isolate it when you feed it into a Scripted attribute definition so you can see if it's there or not and use that as the "was proxying done?" signal.

But honestly proxying is a boundary that's usually meant to map all those external IDs into something produced at the proxy as a façade, or get mapped in to some linked identifier managed in an IDM system.

I would say that's a lot more common since this sort of proxy really tends to be in service of a group of SPs and needs to meet their expectations. Trying to demand they all understand all those external identifiers, you could just as well federate the SPs directly.

When you talk about best practice....proxies to me are always about avoiding any need for standards of any sort. They hide the complex world from the apps so they can act like things are simple. But there are different sorts of proxies obviously.

-- Scott