Page Comparison

...

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

Note the default for “saml1.namespace” above. If your desired inbound or outbound syntax does not include the AttributeName 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 saml1.nameFromMetadata property set to true. The rule may or may not also contain the default saml1.name (and saml1.namespace) properties as a fallback.

If in use, all SAML 1 transcoders will check for an extension Attribute/tag of the name “http://shibboleth.net/ns/attributes/naming/saml1” whose values contain a space-delimited tuple of the form “id name namespace”. All three values MUST be present. A tag may contain multiple values, but only the first value containing the matching attribute ID will be applied.

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 saml1.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/saml1"
          NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <!-- Three overridden naming rules. -->  
        <saml:AttributeValue>mail email unspecified</saml:AttributeValue>
        <saml:AttributeValue>givenName first_name unspecified</saml:AttributeValue>
        <saml:AttributeValue>sn first_name unspecified</saml:AttributeValue>
        
      </saml:Attribute>
      
    </mdattr:EntityAttributes>
  </Extensions>
...
</EntityDescriptor>

The AttributeNamespace value in the rules in the example is arbitrary as this is not a real world example and the use of that field in SAML 1 was essentially unspecified, so other than our default, no other values really have ever been defined anywhere, and our default only applies to the use of URI naming.

Transcoder Types

There are 4 built-in subtypes of SAML 1 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.

...