Use Namespaces and Prefixes in All SAML Tags

Products

CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On Agents (SiteMinder) CA Single Sign On Federation (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) SITEMINDER

Issue/Introduction

When running a CA Access Gateway as the Federation Gateway and
SiteMinder acts as the Service Provider (SP) and configured a
Federation Partnership with a third part IdentityProvider (IDP).

The IDP receives the following SAML Request from SiteMinder :

    <AuthnRequest
    AssertionConsumerServiceURL="---------------------------------"
    ProtocolBinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
    Destination="----------------------------"
    ID="----------------------"
    IssueInstant="-------------------------"
    Version="2.0"
    xmlns="urn:oasis:names:tc:SAML:2.0:protocol">

    <ns1:Issuer xmlns:ns1=urn:oasis:names:tc:SAML:2.0:assertion>-------------------</ns1:Issuer>
     <NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
     <RequestedAuthnContext Comparison="minimum">
      <ns2:AuthnContextClassRef xmlns:ns2=urn:oasis:names:tc:SAML:2.0:assertion>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</ns2:AuthnContextClassRef>
     </RequestedAuthnContext>
    </AuthnRequest>

However, the IDP expects all tags with namespace names in the SAML
Request like this sample :

    <saml2p:AuthnRequest
    AssertionConsumerServiceURL="---------------------------------"
    ProtocolBinding=urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
    Destination="----------------------------"
    ID="----------------------"
    IssueInstant="-------------------------"
    Version="2.0"
    xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
    <ns1:Issuer xmlns:ns1=urn:oasis:names:tc:SAML:2.0:assertion>-------------------</ns1:Issuer>
     <saml2p:NameIDPolicy xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
     <saml2p:RequestedAuthnContext xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="minimum">
      <ns2:AuthnContextClassRef xmlns:ns2=urn:oasis:names:tc:SAML:2.0:assertion>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</ns2:AuthnContextClassRef>
    </saml2p:RequestedAuthnContext>
    </saml2p:AuthnRequest>

Why SiteMinder doesn't generate SAML requests based on the IDP
requirement, with the following:

  1. All required namespace declarations in the base tag with
     namespace prefixes
  2. Qualifying all subsequent tags with namespace prefixes ?

Environment

CA Access Gateway (SPS) 12.8.03
Policy Server 12.8.03

Resolution

This is as such because the prefix are not mandatory in xml
document. As such, the partner shouldn't request them as mandatory as
mandatory neither. More, expecting the prefix saml2p at the first
stage, this is a prefix which is valid but referenced nowhere in the
OASIS documentation.

Looking a each element definition from OASIS, none of the elements has
a mandatory prefix (1)(2)(3).

Additional Information

(1)

    3.4 Authentication Request Protocol

      at least one assertion MUST contain at least one authentication
      statement.

    http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

(2)


    
    3.4.1 Element <AuthnRequest>

      To request that an identity provider issue an assertion with an
      authentication statement, a presenter authenticates to that
      identity provider (or relies on an existing security context)
      and sends it an <AuthnRequest> message that describes the
      properties that the resulting assertion needs to have to satisfy
      its purpose

      AssertionConsumerServiceURL [Optional]


      <saml:Subject> [Optional]

      <NameIDPolicy> [Optional]

      <RequestedAuthnContext> [Optional]

      AssertionConsumerServiceURL [Optional]

      Specifies by value the location to which the <Response> message
      MUST be returned to the requester. The responder MUST ensure by
      some means that the value specified is in fact associated with
      the requester. [SAMLMeta] provides one possible mechanism;
      signing the enclosing <AuthnRequest> message is another. This
      attribute is mutually exclusive with the
      AssertionConsumerServiceIndex attribute and is typically
      accompanied by the ProtocolBinding attribute.

      ProtocolBinding [Optional]

    http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

(3)


    
    3.4.1.1 Element <NameIDPolicy>

      Format [Optional]
      AllowCreate [Optional]

      Note that if the requester wishes to permit the identity
      provider to establish a new identifier for the principal if none
      exists, it MUST include this element with the AllowCreate
      attribute set to "true" This is primarily useful in conjunction
      with the urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
      Format value

    http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf