Add support for renaming SAML attributes and filtering attribute values

[rb12345]

At present, the php-saml library reports the attribute names in an assertion to the caller as specified by the IdP. In some cases, applications using the php-saml library expect different attribute names to those in the assertion. For example, an application may expect to see a "mail" attribute, but the IdP may use the OID form "1.3.6.1.7". In this case, it is very useful useful to rename or "map" these names to a more friendly form. It can also be useful to filter out known-bad or unwanted values from the returned attribute values, such as eduPersonScopedAffiliation values with an invalid scope.

This pull request adds two new parameters to the SP configuration block: "attributeMap" and "attributePolicy". These perform the same basic roles as the similarly attribute-map.xml and attribute-policy.xml files used in the Shibboleth SP software.

The attributeMap parameter is an associative array of 'source'=>'destination' attribute name mappings. This also supports the merging of many source attributes into a single destination attribute. If an attribute name is not present as a key, the attribute is passed through as-is.

The attributePolicy parameter is an associative array of filtering functions where the keys are the "destination" attribute names defined in attributeMap. These take a sole argument of an array of values and return a filtered array of values. If an attribute name is not present, the values are passed through unfiltered.

[pitbulk]

Hi @rb12345

I knew about attribute-map.xml and attribute-policy.xml from shibboleth, and also about Processing Filters from simpleSAMLphp.

But I think that those functionalities belong to the main php app, that knows what attribute expects and with what app attribute link it.

For example, on that SAML plugin of Wordpress, there is a section where the attribute mapping is defined:

and those mappings are later applied to attributes retrieved by php-saml

I want to keep the toolkit simple, and add extra functionalities is not my goal...maybe an option to convert all OID names in normal attributes makes sense.. but nowadays, most of the IdPs are able to configure how publish its attributes per SP.