<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

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

    ignorance publicly:<br>

    <br>

    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.<br>

    <br>

    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?<br>

    <br>

    I found a 2015 email describing that as a solution:<br>

    <br>

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

><i> On 9/25/15, 1:05 PM, "users on behalf of Cathy Scott" <

</i>><i> <a href="http://shibboleth.net/mailman/listinfo/users">users-bounces at shibboleth.net</a> on behalf of <a href="http://shibboleth.net/mailman/listinfo/users">cathystill at gmail.com</a>> wrote:

</i>><i>

</i>><i> >Yes, changing the decoder back to ScopedAttributeDecoder resolved the

</i>><i> issue.  This is a dedicated environment and will never have any other IdP

> authenticating in the environment. I do want to employ best practice.

</i>><i>

</i>><i> The best practice is to stick to standardized attribute (not EPPN

</i>><i> necessarily, but there are in fact no standard identifier attributes in the

</i>><i> world except for the ones we defined). But that would imply not creating

> mappings in the SP for any proprietary attributes from ADFS.

</i>><i>

</i>><i> Since you did that, you're basically creating work on both ends. You added

</i>><i> the mappings, and they apparently mapped the claim name into an EPPN. I'm

</i>><i> saying pick one option, basically. Either they send standard stuff, or you

> map non-standard stuff.

</i>><i>

</i>><i> Also, the better practice is not to just delete the scope checking. You

</i>><i> can alter the metadata supplied by ADFS that you load to add in the Scope

</i>><i> extension that authorizes the scoped values. That assumes the metadata

</i>><i> isn't coming from a federation that's already curating the metadata and

</i>><i> already provides the Scope extension, which is the actual best practice.</i></pre>

    <br>

    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.<br>

    Thanks, Allan<br>

    <br>

  </body>

</html>