Page Comparison

...

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

Test

...

Case eGov2-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

...

eGov2-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

...

eGov2-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.

It may be necessary to bypass, or incorporate a limited amount of, metadata verification functionality in order for metadata import to be tested.

Publication

Scope

• Publication (and maintenance) of metadata via Well-Known-Location resolution profile.

Preconditions

• An http/https entityID defined that is suitable for dereferencing
• Appropriate configuration of that entityID is completed
• Multiple details of configuration are available to tester (location of a profile endpoint, a key descriptor, etc.)
• Any pre-publishing step required is completed

Test Sequence

1. Access published metadata

The entityID is

Test Case eGov2-4 - Publication

Scope

• Publication (and maintenance) of metadata via Well-Known-Location resolution profile.

Preconditions

• An http/https entityID defined that is suitable for dereferencing
• Appropriate configuration of that entityID is completed
• Multiple details of configuration are available to tester (location of a profile endpoint, a key descriptor, etc.)
• Any pre-publishing step required is completed

Test Sequence

1. Access published metadata

The entityID is dereferenced to obtain the metadata document.

...

CONFIRM: As in (1), but also that the implementation did not require a restart or disruption of service.

Test Case eGov2-5 - Import from File

Scope

• Metadata consumption via local file
• Ability to detect and ignore invalid metadata
• Support for batches (md:EntitiesDescriptor)
• Ability to update from a changed source without disruption
• Maintenance of valid operation after a change that renders a source invalid.

...

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.

Test Case eGov2-6 - Import from URL

Scope

• Metadata consumption via multiple http and https sources
• Ability to detect and ignore invalid or unavailable metadata
• Support for caching
• Ability to update via a changed source without disruption
• Maintenance of valid operation after a change that renders a source invalid.

...

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.

Verification by Known Key

Scope

• Test verification of root level signature via a known key.

Preconditions

Test Case eGov2-7 - Verification by Known Key

Scope

• Test verification of root level signature via a known key.

Preconditions

• Any MTI signature algorithm may be used.
• Valid metadata signed by a known key is available at an http or https URL.
• Valid metadata with an invalid signature is available via a different URL.
• The key should not be present inside the signature of the metadata document.
• Appropriate configuration for the use of the URLs and verification with the key is applied.
• No configuration of the information supplied via metadata is in place prior to import

...

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

Test Case eGov2-8 - Verification by Certificate Validation

Scope

• Test verificiation of root level signature via path validation of a signing certificate.

...

The implementation is directed in whatever manner is required to import or make use of the metadata signed with the invalid certificate. A set of SAML interactions is then attempted between the implementation and the metadata subject. A basic test of SP-initiated SSO is sufficient.

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

Section 4: Name Identifiers (Paul Madsen - paulmadsen@rogers.com)

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 "CONFIRM: Import and/or interaction with the metadata subject is unsuccessful.

Test Case eGov2-9 - Confirm support for 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" on element <samlp:AuthnRequest>Repeat above test sequence for ''
CONFIRM: SP offers capability for specifying name identifier format of "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.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>

3. Authenticate to IDP using test account
3 4. Observe response message
CONFIRM: NameID supplied according to NameIDPolicy specified in AuthnRequest

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

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

...

specified in AuthnRequest

Repeat above test sequence for 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'

Test Case eGov2-10 - IDP Discovery

Scope:

• Verify that during web-based SSO that a SP is able to establish an IDP associated with the user.

Preconditions:

• Exchange and import metadata for SP (including extension element for the discovery