Page Comparison

...

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.

Production of IOP-compliant Metadata

Scope

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

IOP-conformant metadata has a different meaning from metadata intended to be evaluated in a PKIX environment, but syntactically should be identical based on the eGov profile language, so this should be sufficient to test production of metadata for both profiles.

Preconditions

• Implementation configured sufficiently to produce metadata identifying its signing, TLS, and encryption keys.
• Details of expected md:KeyDescriptor content available to tester

Test Sequence

1. Access published metadata

The metadata produced by the implementation is obtained.

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

Support for "Metadata Extension for Entity Attributes" Profile

Scope

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

...

<EntityDescriptor entityID="https://idp.example.org/SAML" ... >
   <Extensions>
      <attr:EntityAttributes xmlns:attr="urn:oasis:names:tc:SAML:metadata:attribute">
        <saml:Attribute
            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
            Name="urn:oasis:names:tc:SAML:attribute:assurance-certification">
          <saml:AttributeValue>
            http://foo.example.com/assurance/loa1
          </saml:AttributeValue>
        </saml:Attribute>
      </attr:EntityAttributes>
    </Extensions>
    <IDPSSODescriptor...> 
      ...
    </IDPSSODescriptor>	
</EntityDescriptor>

Preconditions

• SP configured with metadata for candidate IdP containing acceptable LOA "tag".
• SP configured with metadata for candidate IdP not containing acceptable LOA "tag".
• SP configured to require presence of "tag" in metadata for IdPs before it will accept SSO from them.

Test Sequence

1. Verify use of acceptable IdP

...

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

...

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

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.

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

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.

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.

...

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

Test Sequence

1. Import and verify valid metadata

...

Verification by Certificate Validation

Scope

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

Preconditions

• Any MTI signature algorithm may be used.
• Two certificates issued by a sample certificate authority are created, one valid, one expired.
• The certificate must be present inside the signature of the metadata document.
• Valid metadata signed by the key in the valid certificate is available at an http or https URL.
• Valid metadata signed by the key in the invalid certificate is available via a different URL.
• Appropriate configuration for the use of the URLs and verification with the issuing CA is applied.
• No configuration of the information supplied via metadata is in place prior to import

Test Sequence

1. Import and verify valid metadata

...

• 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

...