...
2.5.2.2 Authentication Requests Message Content (Jonathan Scudder - Jonathan.Scudder@forgerock.com)
[What should be CONFIRMED through testing from this section?]These test cases check that the Service Provider is capable of including the child elements and attributes listed in the eGov 2.0 profile in an AuthnRequest message. The tests are carried out using the HTTP-Redirect binding on the assumption that support for child elements and attributes in the message is not affected by the choice of binding. The latter tests check that the Identity Provider handles these and other child elements and attributes in an appropriate way. The correct formation of these elements are not tested in these cases.
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>
3. Trigger SP-initiated single sign-on using the HTTP-Redirect binding, specifying that the request should be passive
CONFIRM: SP offers capability for specifying whether authentication request should be passive or not
4. Observe HTTP redirect parameters and decode the SAMLRequest value using the DEFLATE algorithm reversal
CONFIRM: presence of attribute "IsPassive" 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>
3. Trigger SP-initiated single sign-on using the HTTP-Redirect binding, specifying that a particular AttributeConsumingServiceIndex be called
CONFIRM: SP offers capability for specifying the AttributeConsumingServiceIndex value
4. Observe HTTP redirect parameters and decode the SAMLRequest value using the DEFLATE algorithm reversal
CONFIRM: presence of attribute "AttributeConsumingServiceIndex" with the index specified in step 3 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
4. Trigger SP-initiated single sign-on specifying forced authentication
5. Observe IDP behaviour
CONFIRM: user presented with authentication method on IDP
6. Terminate user sessions on IDP and SP
7. Trigger SP-initiated single sign-on specifying passive request
8. Observe IDP bevhaiour
CONFIRM: IDP returns control to SP without presenting the user with an authentication method
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
3. Trigger SP-initiated single sign-on specifying an AssertionConsumerServiceURL and ProtocolBinding that do not match values in SP metadata
4. Observe IDP behaviour
CONFIRM: IDP responds with appropriate error message
2.5.3.1 Responses Binding and Security Requirements (Diego Lopez - diego.lopez@rediris.es)
...