Un-scoped Microsoft IdPs and ePPN

[Allan West]

My searches aren't finding a current document, so I'll display my 
ignorance publicly:

We federate several of our SPs with other institutions, some of which 
use Microsoft Active Directory (on-prem or cloud) as their IdP. The 
Microsoft IdPs' metadata seem to universally lack the Scope attribute, 
asserting what domain(s) they are authoritative for. This means that 
shibboleth SP software will fail to accept eduPersonPrincipalName or any 
other scoped attribute from them, because they didn't assert a scope 
that includes the domain for the user.

Other than maintaining a separate, scoped copy of the remote IdP's 
metadata, is there a programmatic way to assert a scope on behalf of 
these IdPs?

I found a 2015 email describing that as a solution:

On Fri, Sep 25, 2015 at 10:30 AM, Cantor, Scott <cantor.2 at osu.edu <http://shibboleth.net/mailman/listinfo/users>> wrote:

>/On 9/25/15, 1:05 PM, "users on behalf of Cathy Scott" < />/users-bounces at shibboleth.net 
<http://shibboleth.net/mailman/listinfo/users> on behalf of cathystill 
at gmail.com <http://shibboleth.net/mailman/listinfo/users>> wrote: />//>/>Yes, changing the decoder back to ScopedAttributeDecoder resolved the />/issue. This is a dedicated environment and will never have any other IdP />/authenticating in the environment. I do want to employ best practice. />//>/The best practice is to stick to standardized attribute (not EPPN />/necessarily, but there are in fact no standard identifier attributes in 
the />/world except for the ones we defined). But that would imply not creating />/mappings in the SP for any proprietary attributes from ADFS. />//>/Since you did that, you're basically creating work on both ends. You added />/the mappings, and they apparently mapped the claim name into an EPPN. I'm />/saying pick one option, basically. Either they send standard stuff, or you />/map non-standard stuff. />//>/Also, the better practice is not to just delete the scope checking. You />/can alter the metadata supplied by ADFS that you load to add in the Scope />/extension that authorizes the scoped values. That assumes the metadata />/isn't coming from a federation that's already curating the metadata and />/already provides the Scope extension, which is the actual best practice./


I was aware of that, which is why we haven been maintaining scoped 
copies of some partners' IdP metadata. I'm hoping the shibboleth 
community has a more sustainable mechanism for interacting with these 
Microsoft IdPs.
Thanks, Allan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20260120/027a2555/attachment.htm>