Section numbers correspond to the eGov 2.0 draft profile.
2.2.1 Metadata Profiles (Scott Cantor - cantor.2@osu.edu)
[What should be CONFIRMED through testing from this section?]
2.2.2 Metadata Exchange (Scott Cantor - cantor.2@osu.edu)
[What should be CONFIRMED through testing from this section?]
2.2.2.1 Metadata Verification (Scott Cantor - cantor.2@osu.edu)
[What should be CONFIRMED through testing from this section?]
2.3 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 'persisten', 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?
NB the SAML eGov 1.5 profile, in addition to defining name identifier formats of transient and persistent as MTI, also defined 'unspecified' as MTI. The corresponding tests in the SAML test plan 3.2.2 need be removed/softened.
2.4 Attributes (Denny Prvu - Denny.Prvu@ca.com)
[What should be CONFIRMED through testing from this section?]
2.5.1 Identity Provider Discovery (Andrew Lindsay-Stewart - alindsay-stewart@fugensolutions.com)
[What should be CONFIRMED through testing from this section?]
2.5.2.1 Authentication Requests Binding and Security Requirements (Jonathan Scudder - Jonathan.Scudder@forgerock.com)
[What should be CONFIRMED through testing from this section?]
2.5.2.2 Authentication Requests Message Content (Jonathan Scudder - Jonathan.Scudder@forgerock.com)
[What should be CONFIRMED through testing from this section?]
2.5.3.1 Responses Binding and Security Requirements
[What should be CONFIRMED through testing from this section?]
* See Bob Sunday's example test case below
2.5.3.2 Responses Message Content
[What should be CONFIRMED through testing from this section?]
2.5.4.1 Artifact Resolution Requests (Andrew Lindsay-Stewart - alindsay-stewart@fugensolutions.com)
[What should be CONFIRMED through testing from this section?]
2.5.4.2 Artifact Resolution Responses(Andrew Lindsay-Stewart - alindsay-stewart@fugensolutions.com)
[What should be CONFIRMED through testing from this section?]
2.7.1 Proxying Authentication Requests (Bob Sunday - Robert.Sunday@tbs-sct.gc.ca)
[What should be CONFIRMED through testing from this section?]
2.7.2 Proxying Responses (Bob Sunday - Robert.Sunday@tbs-sct.gc.ca)
[What should be CONFIRMED through testing from this section?]
2.8.1.1 Logout Requests Binding and Security Requirements
[What should be CONFIRMED through testing from this section?]
2.8.1.2 Logout Requests User Interface Behavior
[What should be CONFIRMED through testing from this section?]
2.8.2.1 Logout Responses Binding and Security Requirements
[What should be CONFIRMED through testing from this section?]
3.1.1 Signature and Encryption Algorithms
[What should be CONFIRMED through testing from this section?]
Bob Sunday's example test case
Responses to Authentication Failure
Description
To complete this Test Case, the IdP under test must receive an authentication request for a User it cannot or will not authenticate. The cause of this authentication failure is not relevant but is expected to be an event such as:
- The user chooses to cancel the authentication process.
- The user identity does not exist or the number of failed login attempts has been exceeded.
- The user forgets his/her password and must wait for an email containing the password.
Preconditions
- Metadata exchanged and loaded
- Encryption disabled
- User Identities Not Federated
Test Sequence
1. AuthnRequest from SP to IdP, Redirect Binding, Federate
User/SP attempts Single Sign-On with Persistent Name Identifier with AllowCreate set to true. SP communication to the IdP for the SAML request is through HTTP-Redirect binding. IdP does not recognize User and thus cannot authenticate user.
IdP CONFIRM: User is not authenticated.
2. Response Failure
Being unable to authenticate User, IdP returns SAML Response with error indicating AuthnRequest failed.
SP CONFIRM: IdP returns SAML Response indicating authentication error.