We're running a CA Access Gateway as the Federation Gateway and
SiteMinder acts as the Service Provider (SP) and we've 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 it 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 ?
How can we configure all SAML tags to use namespaces and prefixes in
SiteMinder ?
Release : 12.8.03
Component : SITEMINDER FEDERATION SECURITY SERVICES
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, you were expecting the prefix saml2p at the
first stage, a prefix which is valid but referenced nowhere in the
OASIS documentation.
In order to get implemented the possibility to set the prefixes of
your needs, and get an already formated one as per the sample I gave
you, we invite you to open an Enhancement Request (Idea) on the
Security page :
1. Go to the "All Ideas" page :
https://community.broadcom.com/ideation/allideas
2. Click on the "Add" button.
3. In the "Select categories...", select "Layer7 Access Management".
4. Write a title in the "title" box.
5. Write a complete description of the Enahcement Request or
Certification you'd like to post.
6. Click on "Save" to get the Idea submitted
Looking a each element definition from OASIS, none of the elements has
a mandatory prefix.
3.4 Authentication Request Protocol
at least one assertion MUST contain at least one authentication
statement.
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]
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