Add support for renaming SAML attributes and filtering attribute values #208
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
At present, the php-saml library reports the attribute names as specified by the IdP to the caller. In some cases, it is necessary or useful to rename, or "map", these names to a more friendly form. For example, an IdP may use OIDs in place of "mail" or "eduPersonPrincipalName". It can also be useful to filter out known-bad or unwanted values from the returned attribute values. This patch adds two new parameters to the SP configuration block: "attributeMap" and "attributePolicy". These perform the same basic roles as the similarly named XML files in the Shibboleth SP software. The attributeMap parameter is an associative array of 'source'=>'destination' attribute name mappings. This 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.
… mark as protected
…ng and testAttributePolicy tests
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.