SP-side attribute filtering based on IdP EntityID

[Cantor, Scott]

On 6/29/15, 12:10 PM, "users on behalf of Izz Abdullah" <users-bounces at shibboleth.net on behalf of izz.abdullah at wepanow.com> wrote:

>Good Morning:
>We are running Shibboleth 2.5.4 and purely as an SP.  I was looking to filter which attributes to process based on a specific IdP entityID using something similar to the Attribute Filters in which an IdP would send to a given SP, in a “simpler” manner than using post-processing hooks.  Can this be achieved with rules by attribute-policy or similar?

It's not common, but yes.

>Use Case:
>5 IdPs send the same format for the same urn:oid, but one’s format needs to be filtered (let’s say sAMAccountName may have an undesired underscore).

If by "filtered", you mean throw away, then yes, that can be done with a filter rule. You can't transform anything that way.

>That same value without the underscore is in a different urn:oid sent by said IdP.
>Unfortunately, that OID is used throughout the application for other reasons and would like to only map this attribute to an environment variable on the SP if IdP entityID = X

Your application shouldn't need to be using any OIDs, that's all handled by the SP mappings. You can map an given Attribute to any number of different names, and you can map multiple Attributes to the same name. Usually that's enough to work around whatever it is that's happening.

> 
>I haven’t looked a lot at post processing hooks and what is involved and was hoping something simple such as the IdP form of attribute-filter would be available in SP.

Filters aren't conditional mappings. They're rules for throwing attributes away, that's about it. But if that's the requirement, you can do that. There are no docs, it's the same language as the IdP uses. Rule types such as AttributeIssuerString typically are used to throw something away (or accept something) based on the IdP.

-- Scott