SAML Attribute Requesting

This section describes how DirX Access, acting as a SAML Identity Provider (IdP), determines which SAML attributes are requested for a given Service Provider (SP) and included in the issued saml:Assertion.

Sources of Requested Attributes

DirX Access combines requested attributes from two independent sources:

  • AuthnRequest Extensions — a feature specific to the SuisseID/eIAM profile of SAML 2.0. The requesting SP declares the attributes it wants as Extensions child elements of the samlp:AuthnRequest, including a required marker per attribute.

  • <RequestedAttribute> entries in the SP’s SAML metadata — the peer SP’s metadata <md:AttributeConsumingService> (child of SPSSODescriptor) declares the attributes it wants, per the SAML 2.0 Metadata specification, each optionally marked with isRequired.

Both sources can be present at the same time; DirX Access merges them (see Merging and Precedence).

AttributeConsumingService Selection

When the peer’s SP metadata declares more than one <md:AttributeConsumingService>, DirX Access selects the one referenced by the AttributeConsumingServiceIndex attribute of the incoming samlp:AuthnRequest. If the AuthnRequest does not carry this index, or the index cannot be resolved against the peer’s metadata, the <md:AttributeConsumingService> marked isDefault="true" is used instead.

<md:SPSSODescriptor ...>
  <md:AttributeConsumingService index="0" isDefault="true">
    <md:ServiceName xml:lang="en">My Service</md:ServiceName>
    <md:RequestedAttribute Name="urn:oid:0.9.2342.19200300.100.1.3"
                            FriendlyName="mail"
                            isRequired="true"/>
    <md:RequestedAttribute Name="urn:oid:2.5.4.4"
                            FriendlyName="sn"
                            isRequired="false"/>
  </md:AttributeConsumingService>
</md:SPSSODescriptor>

Merging and Precedence

The two sources are merged into a single list of requested attributes, de-duplicated by attribute name:

  • Attributes requested via AuthnRequest Extensions are always kept.

  • Attributes declared in the SP metadata <RequestedAttribute> are added only if no attribute with the same name was already requested via an Extension.

  • On a name collision, the Extension-derived entry wins, since it is the more specific, per-request declaration.

Introducing metadata-driven attribute requesting changes existing runtime behavior for SPs whose metadata already declares an <md:AttributeConsumingService>: previously, <RequestedAttribute> entries were not evaluated at all, so this declaration had no effect on which attributes were included in the assertion (see Default Behavior (No Requested Attributes)).

Now, if the SP’s metadata declares an <md:AttributeConsumingService> (or the AuthnRequest carries Extensions), only the requested attributes are considered — the attribute set is effectively filtered down to what the SP asked for.

Review peer SP metadata before upgrading if SPs rely on receiving attributes that are not declared in their own <md:AttributeConsumingService>.

Default Behavior (No Requested Attributes)

If neither source yields any requested attribute — no AuthnRequest Extensions, and either no <md:AttributeConsumingService> in the SP’s metadata or one that declares no <RequestedAttribute> entries — DirX Access includes every attribute configured in the SAML attribute statement construction template referenced by the SAML Assertion Construction Template in use is included in the assertion.

Attribute Resolution

A requested attribute (from either source) is only included in the assertion if it can be resolved to an actual value. Resolution matches the requested attribute’s Name/NameFormat against the Name/NameFormat configured on a SamlAttributeTemplate referenced by the SAML attribute statement construction template in use; <RequestedAttribute> does not introduce a new attribute value mapping by itself.

If a requested attribute cannot be matched to any configured SamlAttributeTemplate, or a value cannot be resolved for a match, the attribute is omitted from the assertion.

Handling of isRequired

The isRequired flag of an unresolved <RequestedAttribute> (or the equivalent required marker of an AuthnRequest Extension) controls how the unresolved case is handled:

  • If the attribute was requested as required and no value could be resolved:

    • If SAML Assertion Construction Template's failOnMissingRequiredAttribute is enabled, assertion creation fails.

    • Otherwise, a warning is logged and the attribute is silently omitted.

  • If the attribute was requested as optional (isRequired="false", or not marked) and no value could be resolved, a debug message is logged and the attribute is silently omitted; assertion creation is never affected by unresolved optional attributes.