AttributeFilterPolicy for IdP initiated SSO

[Cantor, Scott]

> The flow is being tested by calling the unsolicited SSO URL in the IdP along
> with the providerId="https://kod.musc.edu".  Instead of only releasing the 2
> attributes above, my IdP is releasing all of the attributes that are mapped in
> my generic "basic:ANY" policy, and sent to the location of the
> AssertionConsumerService in my metadata.

That would happen anyway, that's what ANY means. There's no meaningful difference between IdP initiated SSO and any other unsigned request.

> Is it possible to setup an AttributeFilterPolicy based on the value of the
> providerID from an unsolicited SSO?  My thought was the providerID would
> translate into the value of the AttributeRequesterString in the
> AttributeFilterPolicy, but that doesn't appear to be the case.

Yes, it is. Your policy won't work because your default applies also. All of your SPs are receiving the same superset already.

-- Scott