Handling Scope for AD as an IdP to linux shibboleth SPs

[Allan West]

Thank you everyone who commented! I should have mentioned that they want 
to authenticate with the attribute eduPersonPrincipalName, which is 
inherently scoped.

I looked for the script adfs2fed.py, that Alan recommended, but the 
GitHub repo Google linked to is gone.

Peter is correct that managing the AD IdP metadata sounds like a good 
job for a federation. As the largest member of our state's university 
system, that would likely fall on our shoulders. We're not staffed for 
that, so I will continue to manage scoped, local copies of the AD IdPs' 
metadata.

The specific site which the latest AD IdP wants to authenticate for is 
an InfoSec contest for statewide university students. We don't want that 
audience to use an exploitable hole like un-verified scoped attributes 
to help them win their game. >8^)

I appreciate your thoughtful responses, and I'm glad that I wasn't 
missing anything obvious.

Allan West
allan at ufl.edu


On 1/29/25 10:08, Cantor, Scott via users wrote:
> [External Email]
>
>> The issue or question is not whether the attribute values
>> being sent contain a scope (i.e., they're always
>> foo at example.edu) but about the fact that the attribute used
>> (we don't know which one, yet) is known by the Shib SP
>> software to be defined as "scoped" and hence scope
>> checking against the shibmd:Scope metadata extension is
>> performed.
> Of course that's ultimately a semantic distinction made by whoever configures the SP, you can apply the rule to any attribute provided it's decoded as Scoped.
>
> We didn't define mail that way because of how we expected mail to be used, but a MS principal name is probably something one should define that way, and the way mail is abused by many SPs is such that scoping it is probably also correct in a lot of cases.
>
> What matters is understanding why we did it and what the threat is, and I would have thought MS being bitten by giant impersonation breaks in their platform might have communicated that more widely.
>
> Your point about self-asserting it is on point of course, though the world believes metadata obtained over https is inviolate and so inherently trustworthy at least in so far as they think the right entity owns the URL to start with.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=05%7C02%7Callan%40ufl.edu%7C92ec3cb865cb49858fc808dd4076ecd5%7C0d4da0f84a314d76ace60a62331e1b84%7C0%7C0%7C638737601706476567%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rreqmvYTsZb4nYwdFGSZnomyimHSqPXqzSRm8Ut5mj0%3D&reserved=0
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net