SAML2AttributeTranscoderConfiguration

1 Overview
2 Common Properties
3 Metadata-Based Naming 5.1
- 3.1 Example
4 Transcoder Types

Overview

A set of built-in transcoders supporting SAML 2.0 <Attribute> and <md:RequestedAttribute> objects is provided that support the most frequently needed value types. Most of them support a common set of properties, documented below; a few other properties are defined for specific transcoder types. Since they largely all do the same thing in the same way, they're documented here together.

A particular property of the SAML schema is that <Attribute> and <md:RequestedAttribute> both carry zero or more <AttributeValue> children, so it's allowed in general for the transcoders to be asked to generate objects with no values in either direction but may be inappropriate and prevented in specific cases.

Note that <md:RequestedAttribute> elements can be mapped to and from IdPRequestedAttribute objects with the isRequired property correspondingly set.

Common Properties

In addition to the generic properties, all SAML 2 transcoders support the following:

Name	Type	Default	Description

Name	Type	Default	Description
saml2.name	String		The `<Attribute>` `Name` to map to and from
saml2.nameFormat	URI	urn:oasis:names:tc:SAML:2.0:attrname-format:uri	The `<Attribute>` `NameFormat` to map to and from
saml2.friendlyName		When encoding, the input IdPAttribute's ID	The `<Attribute>` `FriendlyName` to encode
saml2.encodeType	Boolean	true	Whether to encode values with an `xsi:type` attached
saml2.nameFromMetadata ^5.1	Boolean	false	Whether to check for a metadata extension tag for naming rules

Note the default for “saml2.nameFormat” above. If your desired inbound or outbound syntax does not include the NameFormat XML Attribute or relies on a different value, then you MUST set it explicitly in the rule.

Metadata-Based Naming ^5.1

The transcoders also support an option to rely on SAML metadata extension tags to provide SP-specific naming rules. This is an alternative to the use of the relyingParties approach of naming specific SPs in a rule to limit its use. This feature can be combined with “default” naming via a rule such that the metadata is checked for a per-SP name in preference to the default in a rule, with the default applying in the absence of a tag value applying.

Note that this approach only works for encoding into SAML, and does not support the decoding side because the “source name” of a SAML Attribute would then not be known to the system independently of a specific SP (the encoding direction works because the source name there is the internal attribute ID, which is required to be specified in the rule).

To use this feature, the rule must contain the saml2.nameFromMetadata property set to true. The rule may or may not also contain the default saml2.name (and saml2.nameFormat) properties as a fallback.

If in use, all SAML 2 transcoders will check for an extension Attribute/tag of the name “http://shibboleth.net/ns/attributes/naming/saml2” whose values contain a space-delimited pair or tuple of the form “id name format”. The “id” and “name” values MUST be present, and the “format” is optional. A tag may contain multiple values, but only the first value containing the matching attribute ID will be applied.

Notably, in the absence of a third value (the format), the encoded NameFormat will be absent/null, rather than defaulting to the URI format constant. This is because in most cases when using this feature, the SP in question is almost certainly broken enough to improperly ignore that value anyway. Leaving it out is usually advisable, unless testing indicates its needed.

Whether this approach is better for you really depends on how you manage and curate metadata and your ability to extend it, which is increasingly the key to most effectively operating the Shibboleth software.

Example

Consider an SP (let’s call it Sluck), that requires mail, givenName, and sn to be supplied using invented Attribute names, in contravention to the SAML standard. To enable metadata-based naming override, the saml2.nameFromMetadata property flag has to be added to each of the rules (all three in this case are in conf/attributes/inetOrgPerson.xml). The metadata for Sluck would then contain the following extension block:

<EntityDescriptor entityId="https://example.sluck.com" ...>
...
  <Extensions>
    <mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
    
      <!-- Note that the tag here MUST contain the proper NameFormat to be honored. -->
      <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
          Name="http://shibboleth.net/ns/attributes/naming/saml2"
          NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <!-- Three overridden naming rules. -->  
        <saml:AttributeValue>mail email</saml:AttributeValue>
        <saml:AttributeValue>givenName first_name</saml:AttributeValue>
        <saml:AttributeValue>sn first_name</saml:AttributeValue>
        
      </saml:Attribute>
      
    </mdattr:EntityAttributes>
  </Extensions>
...
</EntityDescriptor>

Transcoder Types

There are 5 built-in subtypes of SAML 2 transcoders, as follows. Each one is predefined as a Spring bean for use in rules using the "short" name of the class, as enumerated in the TranscodingRuleConfiguration reference section.

SAML2StringAttributeTranscoder

The simplest and most commonly used transcoder, it supports encoding and decoding internal values from and to the StringAttributeValue class. It supports no additional properties.

SAML2ScopedStringAttributeTranscoder

It supports encoding and decoding internal values from and to the ScopedStringAttributeValue class. It supports the following additional properties (all optional):

Name	Type	Default	Description

Name	Type	Default	Description
saml2.scopeType	"inline" or "attribute"	"inline"	The "style"/syntax with which to encode and decode the scope portion
saml2.scopeAttributeName	String	Scope	The name of the XML attribute to encode and decode the scope portion when saml2.scopeType is "attribute"
saml2.scopeDelimiter	String	@	The character(s) to use to separate the value and scope when saml2.scopeType is "inline"

SAML2DateTimeAttributeTranscoder

It supports encoding and decoding internal values from and to the DateTimeAttributeValue class. It supports the following additional properties (all optional):

Name	Type	Default	Description

Name	Type	Default	Description
saml2.epochUnits	“s“ or “ms”	“s”	When decoding, controls the handling of integer values (or strings in that form) when converting to an Instant. The default (“s”) is to handle the value as seconds, while “ms” means to handle as milliseconds. Java tends to deal in the latter but the traditional handling (e.g., C/C++) tend to be in seconds.

SAML2ByteAttributeTranscoder

It supports encoding and decoding internal values from and to the ByteAttributeValue class, with a base64 transform applied. It supports no additional properties.

SAML2XMLObjectAttributeTranscoder

It supports encoding and decoding internal values from and to the XMLObjectAttributeValue class. It supports the following additional properties (all optional):

Name	Type	Default	Description

Name	Type	Default	Description
saml2.includeAttributeValue	Boolean	false	When decoding, controls whether the decoded XMLObject is actually the `<AttributeValue>` element itself, or its child element