Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Section numbers correspond to the eGov 2.0 draft profile.

2.2.1 Metadata Profiles

IOP (Scott Cantor - cantor.2@osu.edu)
PKIX (Terry McBride)

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

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

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: The metadata is available, and correctly reflects the entityID accessed, and is returned with the correct MIME type (application/xml+samlmetadata). The configuration details expected are found in the metadata.

2. Alter metadata and republish

Alter the configuration (changing an endpoint, a key descriptor, etc.) and republish, then repeat the first test.

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

Import from File

Preconditions
  • Valid metadata is available to the implementation via a local filesystem path
  • The valid metadata contains at least two md:EntityDescriptor elements inside an md:EntitiesDescriptor element
  • Invalid metadata is available to the implementation via a (different) local filesystem path
  • Appropriate configuration for the use of those paths is applied
  • No configuration of the information supplied via metadata is in place prior to import
Test Sequence

1. Import valid metadata

The implementation is directed in whatever manner is required to import or make use of the valid metadata. 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: Operation of a defined set of SAML interactions with the metadata subject is successful based on the content of the metadata (correct endpoints used, keys used in accordance with one of the supported metadata profiles, etc.).

2. Import invalid metadata

The implementation is directed in whatever manner is required to import or make use of the invalid metadata. 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.

3. Update valid metadata

The valid metadata is modified in some manner that is detectable via the interactions used to confirm successful import (changing an endpoint, a key descriptor, etc.), but remains valid. If the implementation requires manual intervention to recognize the change, this is done. The SAML interactions are repeated.

CONFIRM: The interactions remain successful but cognizant of the change(s). No restart or other service interruption was required to accomodate the change.

4. Update valid metadata with invalid change.

The valid metadata is modified in some manner that renders it invalid. If the implementation requires manual intervention to recognize the change, this is done. The SAML interactions are repeated.

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.

Import from URL

Preconditions
  • Valid metadata is available to the implementation via at least two URLs (one http, one https)
  • Invalid metadata is available to the implementation via a different, possibly unavailable, URL
  • Appropriate configuration for the use of those URLs is applied
  • No configuration of the information supplied via metadata is in place prior to import
Test Sequence

1. Import valid metadata

The implementation is directed in whatever manner is required to import or make use of the valid metadata. A set of SAML interactions is then attempted between the implementation and the metadata subjects (at least two, one for each source of metadata). A basic test of SP-initiated SSO is sufficient.

CONFIRM: Operation of a defined set of SAML interactions with the metadata subjects is successful based on the content of the metadata (correct endpoints used, keys used in accordance with one of the supported metadata profiles, etc.).

2. Import invalid metadata

The implementation is directed in whatever manner is required to import or make use of the invalid metadata source. 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.

3. Re-import unchanged metadata

The implementation is directed in whatever manner is required to re-import/refresh the valid source of metadata, with the source maintaining the same caching indicator(s). The SAML interactions are repeated.

CONFIRM: The import resulted in no exchange of the metadata document across the network, and the interactions remain successful in accordance with the metadata that existed prior to the re-import.

4. Re-import changed metadata

The valid metadata is modified in some manner that is detectable via the interactions used to confirm successful import (changing an endpoint, a key descriptor, etc.), but remains valid. The implementation is directed in whatever manner is required to re-import/refresh the valid source of metadata. The SAML interactions are repeated.

CONFIRM: The interactions remain successful but cognizant of the change(s). No restart or other service interruption was required to accomodate the change.

5. Update valid metadata with invalid change.

The valid metadata is modified in some manner that renders it invalid. The implementation is directed in whatever manner is required to re-import/refresh the now-invalid source of metadata. The SAML interactions are repeated.

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.

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 '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?

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 Logout Requests

2.8.1.1 Logout Requests Binding and Security Requirements (Fulup Ar Foll - fulup@sun.com)

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

2.8.1.2 Logout Requests User Interface Behavior (Fulup Ar Foll - fulup@sun.com)

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

2.8.2 Logout Responses

2.8.2.1 Logout Responses Binding and Security Requirements (Fulup Ar Foll - fulup@sun.com)

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

3.1.1 Signature and Encryption Algorithms (John Bradley - ve7jtb@ve7jtb.com)

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

Bob Sunday's example test case

Responses to Authentication Failure

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.

  • No labels