Blocking a service provider

[Peter Schober]

* Gary Walton <G.Walton at coventry.ac.uk> [2016-02-24 12:23]:
> I have a need to block a Service Provider and would like to know how.

The common approach is to only release data to the services you want,
and then only what they need. Of course if you start off with
releasing a whole set of data to "everyone" this causes more work for
the cases where you don't want that behaviour. (It also means you'd
have to watch out for new services all the time in case you'd need to
block release of attributes to those, too. That's not a good position
to be in, IMO.)

> I have tried the following with various attribute ID to no avail
> 
> <AttributeFilterPolicy id="DoNotReleaseToASP">
>     <PolicyRequirementRule xsi:type="basic:NOT">
>         <basic:Rule xsi:type="basic:AttributeRequesterString" value="entity ID" />
>     </PolicyRequirementRule>
>     <AttributeRule attributeID="transientId">
>         <PermitValueRule xsi:type="basic:ANY" />
>     </AttributeRule>
</AttributeFilterPolicy>

That will just add (*Permit*ValueRule) transientId to that SP (which
by default is released to anyone, anyway). I.e., it does nothing.
More specifically this does not suppress the release of any other
attributes /not/ referenced here, but released from other rules /also/
matching this SP (e.g. rules for "everyone").

So to avoid releasing attributes to that SP you'd have to enumerate
/all/ the attributes released to everyone (in some other rule/s) -- or
which are defined in the resolver at all, to be sure -- and add a
DenyValueRule for each one. (That's why unconditionally defaulting
release of attributes to everyone is not such a great idea.)

An alternative would be adding a custom relying party configuration
removing all profiles (such as SAML1 and SAML2) for that relying
party, effectively making this SP unusable with your IDP.

You fail to mention the IDP version this is for, but both the IDPv2
and the IDPv3 documentation cover both cover the latter method.
-peter