Germany SAML Detailed Analysis - RUB-NDS/FutureTrust GitHub Wiki

According to Section 4.1 of (BSI TR-03130-1, 2016)^[1], the basis for the SAML profile which is implemented by the eID-Service must be the Web browser Single Sign-On profile. The HTTP Redirect binding shall be implemented.

In the following we show the general structure of AuthnRequest and Response according to Section 4.7 of (BSI TR-03130-1, 2016)^[1]. We show only required elements and required attributes. Furthermore we only explain differences to normal SAML messages as specified in (SAML 2.0, 2005)^[2].

<AuthnRequest Version="2.0" ID="ID" IssueInstant="Instant" Destination="URL_eID-Service" <!-- ProtocolBinding="urn:oasis:names:tc:
  SAML:2.0:bindings:HTTP-Redirect" optional --> <!-- AssertionConsumerServiceURL="URL_eService_Consumer" (optional if default URL is registered at eID-Service) --> ProviderName="Provider"
  <Issuer/>
  <Extensions>
    <EncryptedAuthnRequestExtension>
      <EncryptedData>…</EncryptedData>
    </EncryptedAuthnRequestExtension>
  </Extensions>
</AuthnRequest>

AuthnRequest contains an Extension element which contains an EncryptedAuthnRequestExtension element.

ProtocolBinding is optional, if it is present it must have the value “urn:oasis:names:tc:SAML:2.0:bindings:HTTP Redirect”. If it is missing, this value is assumed.

AssertionConsumerServiceURL can be left out, if a default URL for the eService is registered at the eID-Server.

<AuthnRequestExtension Version="2">
  <RequestedAttributes>
    <Attribute Name="attribute" RequiredAttribute="true/false">
      <AttributeValue/>
    </Attribute>
    ...
    <Attribute Name="attributeN" RequiredAttribute="true/false">
      <AttributeValue/>
    </Attribute>
  </RequestedAttributes>
</AuthnRequestExtension>

AuthnRequestExtension has an attribute Version with the value “2”, and contains a RequestedAttributes element which contains Attribute elements. The Attribute elements have a Name attribute and an optional RequiredAttribute which signals the eID-Server if the attribute is required or not. The Name attributes only allow specific values, which can be seen in Table 1.

Table 1: SAML request attributes^[1]

<Response Version="2.0" ID="ID" InResponseTo="request_ID" IssueInstant="timestamp" Destination="URL_Destination">
  <Issuer/>
  <Status>
    <StatusCode Value="StatusCode"/>
  </Status>
  <EncryptedAssertion>
    <EncryptedData/>
  </EncryptedAssertion>
</Response>

The Response contains an EncryptedAssertion element.

<Assertion Version="2.0" ID="ID" IssueInstant="timestamp">
  <Issuer/>
  <Subject>
    <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">random ID</NameID>
    <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <SubjectConfirmationData Address="IP_eID_Client" InResponseTo="ID_request" NotOnOrAfter="timestamp+5min" Recipient="URL_Consumer"/>
    </SubjectConfirmation>
  </Subject>
  <Conditions>
    <AudienceRestriction>
      <Audience>URL_Request_Issuer</Audience>
      <OneTimeUse/>
    </AudienceRestriction>
  </Conditions>
  <AuthnStatement AuthnInstant="timestamp_Assertion_Creation">
    <AuthnContext>
      <AuthnContextDeclRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI
      </AuthnContextDeclRef>
    </AuthnContext>
  </AuthnStatement>
  <AttributeStatement>
    <Attribute Name="attribute" AttributeNotOnChip="true/false">
      <AttributeValue xsi:type see List />
    </Attribute>
    ...
    <Attribute Name="attributeN" AttributeNotOnChip="true/false">
      <AttributeValue xsi:type see List />
    </Attribute>
    <Attribute Name="DocumentValidity">
      <AttributeValue xsi:type="eid:DocumentValidityResultType" Version="1">
        <ReferenceDate>exact Date of Verification</ReferenceDate>
        <Status>valid/failed</Status>
      </AttributeValue>
    </Attribute>
  </AttributeStatement>
</Assertion>

The following rules apply to the elements contained in an Assertion element:

• The Format attribute of NameID shall be “urn:oasis:names:tc:SAML:2.0:nameid-format:transient”.
• The Address attribute of SubjectConfirmationData must contain the IP address of the eID-Client.
• The NotOnOrAfter attribute must not be longer than 5 minutes after the creation of the assertion.
• AuthnContextDeclRef must contain “urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI”.
• AttributeStatement contains an Attribute element for each requested attribute in the AuthnRequestExtension.
• Attribute has a Name attribute. It also has an optional AttributeNotOnChip attribute, which defaults to “false” if not present and shows if the reading of an attribute was supported by the eID-Document. Attribute contains an AttributeValue element.
• AttributeValue contains the value of the requested attribute. The xsi:type is defined according to the Name attribute of the Attribute element.
• One Attribute element must have the attribute Name=“DocumentValidity”. It contains one AttributeValue element. This element must have an attribute xsi:type="eid:DocumentValidityResultType" and an attribute Version=“1”. It contains one ReferenceDate and one Status element.
• ReferenceDate must contain the exact date when the eID-Document has been verified.
• Status must contain the values “valid” or “failed”. Optionally “expired”, “revoked” and “notAuthentic” are possible as well.

Table 2: SAML response attributes^[1]

1. ^ ^ ^ ^ BSI TR-03130-1. (2016, November 16). Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI). eID-Server Part 1: Functional Specification. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03130/TR-03130_TR-eID-Server_Part1.pdf?__blob=publicationFile: Technical Guideline 03130-1, Version 2.0.2.
2. ^ SAML 2.0. (2005, March 15). OASIS Standard. Retrieved from Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0: http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf