pysaml2: pysaml2 should not try to convert attribute Names to attribute FriendlyNames.
Expected Behavior
Attributes should be untouched and specified by their Name (which is a required attribute). As FriendlyName is an optional attribute, one cannot rely on that and must-not as specified by the specification.
Section 2.7.3.1, § FriendlyName, line 1271 This attribute’s value MUST NOT be used as a basis for formally identifying SAML attributes
Convertion from Name to FriendlyName should be explicit and handled by the user.
Current Behavior
Internally pysaml2 converts attribute names to friendly names and uses the latter for most operations, like filtering, metadata generation (RequestedAttributes element), creation of class members, etc. This is achieved through the AttributeConverter class, the helper functions defined in attribute_converter module and the attributemaps files. These allows for some control over the conversion process.
Possible Solution
Only depend on attribute Name. It is the only way to guarantee robustness and is required to be in line with the specification. This questions the value of attribute_converter module; whether it is needed at all. The user of the library (the application) should be responsible for such a conversion, which most probably would be used to present an interface where friendly-names could be used in place of the non-descriptive name identifiers.
About this issue
- Original URL
- State: open
- Created 6 years ago
- Comments: 18 (18 by maintainers)
It is not always an option to just send additional attributes in the SAML assertion to an SP. This breaks some vendor/cloud SP SAML stacks. SATOSA needs to be capable of being customized to send any conformant SAML assertion to a particular SP that needs a specific combination of NameFormat and Name for an attribute.
Not all attribute names are globally unique, especially when integrating with cloud/vendor SPs. When the format is basic or unspecified SATOSA still needs to be able to take internal attributes and map them to non-globally unique attribute names that can differ from SP to SP.
For example, a deployment may have the internal name i_given_name and need for one SP to send the value with name=“given” and format unspecified, but for another SP it needs to send the value with name=“given_name” and format unspecified.