Shibboleth makes heavy use of the <mdattr:EntityAttributes>extension in SAML metadata to attach "tags" to metadata either directly or via metadata filter and use the tags to drive configuration or many other use cases within the software. It is potentially useful to extend this approach to many local use cases that are outside the direct scope of the software. For example, one might wish to use tags to attach other pieces of information to SP metadata in order to perform access control functions or customize the user interface in unexpected ways.
This example deals with how to conveniently access custom tags for more “unanticipated” purposes, rather than any of the usual features of the software that already know how to operate based on tags. Two obvious cases are using them in view templates or in scripts.
Note that all of these examples assume the use of URI-based naming; that is, they assume the underlying SAML <Attribute>NameFormat value is set to urn:oasis:names:tc:SAML:2.0:attrname-format:URI
The basis of both use cases is to define a Spring bean (or beans) to pull the tags desired out of the metadata and expose them. There are already classes able to do this as part of the implementation of the https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199508127 feature and there are parent beans defined to make use of them to insulate the deployer from those classes.
There are different classes defined to handle different data types. By far the most likely need is for String data, or multiple String values in a Set or List. Pick the parent bean needed based on the data type you wish to expose from the tag. The hyperlinks reference the underlying class documentation describing the options supported. These parent beans expose a single String, Boolean, Integer, Long, Double, or Duration:
The explicitPropertyName setting is necessary to allow reuse of these classes without triggering their built-in behavior that looks for tags using special prefixes for the https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199508127 feature. Turning off caching is usually advisable because that feature was designed to optimize multiple lookups of the same tag as would be common when accessing configuration settings. For most one-off use cases, the caching isn’t needed and probably costs more in time than it’s worth, but it could be used.
The same example, but handling multiple <AttributeValue> elements in the metadata and exposing them all as a Set<String>: