Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of Contents
maxLevel4

...

Section 1: Metadata Profiles (IOP, Scott Cantor - cantor.2@osu.edu; PKIX, Terry McBride)

Test the ability of an implementation to produce and consume metadata in accordance with the two mandatory profiles identified, and to support the "Metadata Extension for Entity Attributes" profile.

Test Case 1.1 - Production of IOP-compliant Metadata

Scope
  • Verify the ability to produce metadata conformant to the Metadata IOP.

...

CONFIRM: The content(s) of the md:KeyDescriptor element(s) matches the expected output.

Test Case 1.2 - Consumption of IOP-compliant Metadata

Testing is best accomplished with a fixed implementation to test against, as the purpose is not to test actual protocol correctness, but use of the metadata itself.

...

CONFIRM: The SSO operations are unsuccessful.

Test Case 1.3 - Support for "Metadata Extension for Entity Attributes" Profile

Scope
  • Test SP acceptance of SSO based on IdP metadata extension content

...

CONFIRM: SSO is unsuccessful based on the policy requiring the tag.

Section 2

...

: Metadata Exchange (Scott Cantor - cantor.2@osu.edu)

Test the ability of an implementation to publish and consume metadata documents, and maintain the information in real time. Testing import and verification is best accomplished with a fixed set of "sources" to import and test against, as the purpose is not to test actual protocol correctness, but use of the metadata itself.

...

CONFIRM: The interactions remain successful in accordance with the metadata that existed prior to the change. No restart or other service interruption was required to accomodate the change.

...

Section 3: Metadata Verification (Scott Cantor - cantor.2@osu.edu)

Test the ability of an implementation to verify metadata before importing/accepting it for use. The focus is on import of remote sources, since local file sources can naturally undergo checking outside of the import process before being made available.

...

CONFIRM: Import and/or interaction with the metadata subject is unsuccessful.

...

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

...

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.

...

Section 5: Attributes (Denny Prvu - Denny.Prvu@ca.com)

[What should be CONFIRMED through testing from this section?]

...

Section 6: Identity Provider Discovery (Andrew Lindsay-Stewart - alindsay-stewart@fugensolutions.com)

To confirm:

  • SP is able to determine appropriate IdP using a discovery service with user interaction
  • User experience when no IdP selected e.g. discovery service down.

...

Section 7: Authentication Requests Binding and Security Requirements (Jonathan Scudder - Jonathan.Scudder@forgerock.com)

Confirm support for the HTTP-Redirect binding for transmitting AuthnRequest messages

...

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

...

Section 8: Authentication Requests Message Content (Jonathan Scudder - Jonathan.Scudder@forgerock.com)

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.

...

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

...

Section 9: Responses Binding and Security Requirements (Diego Lopez - diego.lopez@rediris.es)

Confirm...

+ Availability of both Artifact and POST bindings to issue <saml2:Response> at IdPs
+ Consumption (SP) and production (IdP) of unsolicited <saml2:Response>
+ IdP error reporting via a <saml2:Response> unless no endpoint is available
+ Issuance (IdP) and acceptance (SP) of signed <saml2:Assertion>
+ Issuance (IdP) and acceptance (SP) of <saml2:EnctyptedAssertion>

...

SP CONFIRM: IdP returns SAML Response indicating authentication error.

...

Section 10: Responses Message Content (Diego Lopez - diego.lopez@rediris.es)

Confirm...

+ IdP able to limit the number of <saml2:Assertion>, <saml2:AuthnStatement>, and <saml2:AttributeStatement> to one
+ IdP able to include a Consent attribute in <samlp:Response> IdP able
+ to include a SessionIndex attribute in <saml2:AuthnStatement>

...

Section 11: Artifact Resolution Requests (Andrew Lindsay-Stewart - alindsay-stewart@fugensolutions.com)

To confirm:

  • Requestor (SP) able to dereference artifact to be able to determine issuer
  • Able to check artifact has not used been before
  • Acceptance of signed SOAP request message

...

Section 12: Artifact Resolution Responses(Andrew Lindsay-Stewart - alindsay-stewart@fugensolutions.com)

To confirm:

  • Responder (IdP) able to confirm validity of artifact
  • Able to check artifact has not been used before
  • Acceptance of signed SOAP response message with and without corresponding SAML assertion

...

Section 13: SAML 2.0 Proxying Authentication Requests/Responses (Bob Sunday - Robert.Sunday@tbs-sct.gc.ca)

The objective is to test the ability of an implementation to be configured to provide the mapping options required by the eGov2.0 profile. The eGov requirements for 2.7.1 Proxying Authentication Requests and 2.7.2 Proxying Responses can be combined into a single set of test cases.

...