...
Section 4: Name Identifiers (Paul Madsen - paulmadsen@rogers.com)
The tests will confirm that IdP and SP properly implement support for the Name Identifier formats of
- urn:oasis:names:tc:SAML:2.0:nameid-format:transient
- urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
Such support will consiste of proper handling of the
- AuthnRequest's NameIDPolicy
- NameID in the returned Response.
PaulM: The existing SAML test plan 3.2.2 would appear to cover the necessary tests for 'persistent', but testing for 'transient' is far more limited, ie only in Test Case J and only in the case of an unsolicited Response. Should this be more symmetrical?
...
Confirm Service Provider support for AuthnRequest NameIDPolicy of 'persistent' & 'transient'
...
Scope:
...
- Verify SP possibility to specify values of 'persistent' & 'transient' for the NameIDPolicy element in an AuthnRequest
...
Preconditions:
...
- Metadata exchanged and imported
- SP and IDP configured to use HTTP-Redirect binding for AuthnRequest
...
Test sequence:
...
1. Trigger SP-initiated single sign-on using the HTTP-Redirect binding, specifying at SP that the returned identifier be 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent'
CONFIRM: SP offers capability for specifying name identifier format of "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
2. Observe HTTP redirect parameters and decode the SAMLRequest value using the DEFLATE algorithm reversal
CONFIRM: presence of element "NameIDPolicy" with value "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" on element <samlp:AuthnRequest>
Repeat above test sequence for 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'
Confirm Identity Provider support for dealing with AuthnRequest NameIDPolicy
...
Scope:
...
- Verify IDP handling of AuthnRequest child element NameIDPolicy
...
Preconditions:
...
- Metadata exchanged and imported
- Service provider capable of sending AuthnRequest messages with <saml2p:NameIDPolicy>
- Valid and known account that can be authenticated using an available authentication method on IDP
...
Test sequence:
...
1. Trigger SP-initiated single sign-on specifying NameIDPolicy
2. Authenticate to IDP using test account
3. Observe response message
CONFIRM: NameID supplied according to NameIDPolicy specified in AuthnRequest
Section 5: Attributes (Denny Prvu - Denny.Prvu@ca.com)
...
Testing that the HTTP-Redirect binding for AuthnRequest messages is supported can be performed through metadata analysis or by verifying that the AuthnRequest is accepted when triggering SP-initiated SSO. The latter is used for this test as a more accurate indication of actual support.
...
Scope:
...
- Confirm that a valid AuthnRequest transmitted to the IDP is accepted and acted upon.
...
Preconditions:
...
- Metadata exchanged and imported
- No current user session on IDP
- Any authentication method configured on IDP side
- Test performed with NameID setting supported by both IDP and SP
...
Test sequence:
...
1. Trigger SP-initiated single sign-on with valid parameters
2. Observe IDP handling of the request
CONFIRM: IDP authentication is triggered without error.
...
This involves verifying that an AuthnRequest can be generated with signatures on the SP side by
triggering such a message and examining the information transmitted to the IDP using the
HTTP-Redirect binding. The correct creation of signatures is not tested in this case.
...
Scope:
...
- Test for the presence of a signature for AuthnRequest when transmitting to IDP.
...
Preconditions:
...
- Metadata exchanged and imported
- Signing key created and configured on the SP side
- SP configured to sign authentication requests
- SP and IDP configured to use HTTP-Redirect binding for AuthnRequest
- A signature algorithm supported by both IDP and SP is used for the test
...
Test sequence:
...
1. Trigger SP-initiated single sign-on using the HTTP-Redirect binding
2. Observe parameters of the HTTP redirect
CONFIRM: presence of the SigAlg and Signature parameters
...
This case checks that an IDP can receive a signed AuthnRequest and act approriately according to the validity of the signature.
...
Scope:
...
- Test consumption of a signed AuthnRequest with and without error according to validity.
...
Preconditions:
...
- Metadata exchanged and imported
- Signing keys created, exchanged and configured
- SP configured to sign authentication requests
- SP and IDP configured to use HTTP-Redirect binding for AuthnRequest
- A signature algorithm supported by both IDP and SP is used for the test
...
Test sequence:
...
1. Trigger SP-initiated single sign-on using the HTTP-Redirect binding
2. Observe IDP handling of the request
CONFIRM: IDP accepts AuthnRequest message without error
3. Remove signature public key from IDP
4. Trigger SP-initiated single sign-on using the HTTP-Redirect binding
5. Observer IDP handling of the request
CONFIRM: IDP rejects AuthnRequest due to invalidity of the signature
...
Confirm Service Provider support for AuthnRequest child elements <saml2p:RequestedAuthnContext> and <saml2p:NameIDPolicy>
...
Scope:
...
- Verify possibility to specify, and presence of, the AuthnRequest child elements
<saml2p:RequestedAuthnContext> and <saml2p:NameIDPolicy>
...
Preconditions:
...
- Metadata exchanged and imported
- Service provider metadata contains multiple indexed AttributeConsumingService entries
- SP and IDP configured to use HTTP-Redirect binding for AuthnRequest
...
Test sequence:
...
1. Configure SP to specify one or more authentication contexts
CONFIRM: SP offers administrative capability to specify authentication contexts in the request
2. Configure SP to specify a NameIDPolicy for one or all authentication requests
CONFIRM: SP offers administrative capability to specify a NameIDPolicy in the request
3. Trigger SP-initiated single sign-on using the HTTP-Redirect binding
4. Observe HTTP redirect parameters and decode the SAMLRequest value using the DEFLATE algorithm reversal
CONFIRM: presence of element <saml2p:RequestedAuthnContext> as a child of AuthnRequest element
CONFIRM: presence of element <saml2p:NameIDPolicy> as a child of AuthnRequest element
Confirm Service Provider support for AuthnRequest attributes ForceAuthn and IsPassive
...
Scope:
...
- Verify possibility to specify, and presence of, the AuthnRequest attributes ForceAuthn and IsPassive
...
Preconditions:
...
- Metadata exchanged and imported
- SP and IDP configured to use HTTP-Redirect binding for AuthnRequest
...
Test sequence:
...
1. Trigger SP-initiated single sign-on using the HTTP-Redirect binding, specifying that authentication should be forced
CONFIRM: SP offers capability for specifying whether authentication should be forced or not
2. Observe HTTP redirect parameters and decode the SAMLRequest value using the DEFLATE algorithm reversal
CONFIRM: presence of attribute "ForceAuthn" with value "true" on element <samlp:AuthnRequest>
...
Confirm Service Provider support for AuthnRequest attributes AssertionConsumerServiceURL, ProtocolBinding, and AttributeConsumingServiceIndex
...
Scope:
...
- Verify possibility to specify, and presence of, the AuthnRequest attributes AssertionConsumerServiceURL, ProtocolBinding, and AttributeConsumingServiceIndex
...
Preconditions:
...
- Metadata exchanged and imported
- Service provider metadata contains indexed AssertionConsumerService entries
- Service provider metadata contains indexed AttributeConsumingService entries
- SP and IDP configured to use HTTP-Redirect binding for AuthnRequest
...
Test sequence:
...
1. Trigger SP-initiated single sign-on using the HTTP-Redirect binding, specifying that a particular AssertionConsumerServiceURL be called using a specified ProtocolBinding
CONFIRM: SP offers capability for specifying the AssertionConsumerService URL
CONFIRM: SP offers capability for specifying the ProtocolBinding to be used
2. Observe HTTP redirect parameters and decode the SAMLRequest value using the DEFLATE algorithm reversal
CONFIRM: presence of attribute "AssertionConsumerServiceURL" with the URL specified in step 1 as value, on element <samlp:AuthnRequest>
CONFIRM: presence of attribute "ProtocolBinding" with the URL specified in step 1 as value, on element <samlp:AuthnRequest>
...
Confirm Identity Provider support for AuthnRequest child elements and attributes that should be accepted
...
Scope:
...
- Verify IDP handling of AuthnRequest child elements <saml:Subject>, <NameIDPolicy>, <saml:Conditions>, <RequestedAuthnContext>, <Scoping>, and attributes AssertionConsumerServiceIndex and ProviderName
...
Preconditions:
...
- Metadata exchanged and imported
- Service provider configured to send AuthnRequest messages with Subject, NameIDPolicy, Conditions, RequestedAuthnContext, Scoping, AssertionConsumerServiceIndex and ProviderName
- Service provider metadata contains indexed AssertionConsumerService entries
- SP and IDP configured to use HTTP-Redirect binding for AuthnRequest
...
Test sequence:
...
1. Trigger SP-initiated single sign-on using the HTTP-Redirect binding (note prerequisites)
2. Observe HTTP redirect parameters and decode the SAMLRequest value using the DEFLATE algorithm reversal
CONFIRM: presence of attributes and child elements outlined above, in element <samlp:AuthnRequest>
3. Observe IDP handling of AuthnRequest
CONFIRM: IDP accepts AuthnRequest without error, or returns apprioriate error messages
Confirm Identity Provider support for AuthnRequest child elements and attributes that should be utilized
...
Scope:
...
- Verify IDP handling of AuthnRequest child element <saml2p:NameIDPolicy>, and attributes ProtocolBinding, ForceAuthn, IsPassive, AttributeConsumingServiceIndex.
...
Preconditions:
...
- Metadata exchanged and imported
- Service provider capable of sending AuthnRequest messages with <saml2p:NameIDPolicy>, ForceAuthn, IsPassive, and AttributeConsumingServiceIndex.
- Service provider metadata contains indexed AttributeConsumingService entries
- IDP configured to provide attribute response
- Valid and known account that can be authenticated using an available authentication method on IDP
...
Test sequence:
...
1. Trigger SP-initiated single sign-on specifying NameIDPolicy and AttributeConsumingServiceIndex
2. Authenticate to IDP using test account
3. Observe response message 
CONFIRM: attributes sent according to AttributeConsumingServiceIndex
CONFIRM: NameID supplied according to NameIDPolicy specified
...
Confirm Identity Provider verification of AssertionConsumerServiceURL value
...
Scope:
...
- Verify IDP handling of AuthnRequest attributes AssertionConsumerServiceURL and ProtocolBinding
...
Preconditions:
...
- Metadata exchanged and imported
- Service provider capable of sending AuthnRequest messages with AssertionConsumerServiceURL and ProtocolBinding attributes
- Service provider metadata contains AssertionConsumerService entries
- IDP configured to provide attribute response
- Valid and known account that can be authenticated using an available authentication method on IDP
...
Test sequence:
...
1. Trigger SP-initiated single sign-on specifying an AssertionConsumerServiceURL and ProtocolBinding that matches values in SP metadata
2. Observe IDP behaviour
CONFIRM: IDP accepts AuthnRequest without error
...