Generalized management assertions for IAP section 4.2.7 (IAP version 1.1)

4.2.7 Assertion Content

The IdPO (management) has processes in place to ensure that information about a Subject's identity conveyed in an Assertion of identity to an SP is from an authoritative source.

See below for specific information about the documentation of IdPO practices which meet the requirements for each sub-section.

4.2.7.1 Identity Attributes

Our institution supports the following list of eduPerson and other inetOrgPerson attributes as defined in the InCommon Attribute Summary:

(List attributes here)

Our institutional schema documentation defines the business rules for population of these attributes, and can be found here:

(Link to schema documentation for IAM system here, or alternatively, copy and paste definitions for your buisness rules for populating these attribute here)

Our business rules populate the attributes in alignment with the eduPerson and inetOrgPerson object classes, which are linked from the InCommon attribute summary page:

http://www.incommonfederation.org/attributesummary.html

4.2.7.2 Identity Assertion Qualifier

We have not been qualified by InCommon to assert any identity qualifiers (IAQs) as of the time of writing of this documentation, and we currently do not release any IAQs for any Subjects.

We will store our IAQs as attribute values in (X) data store, but they are currently (not populated, DACL'ed off from access by the IdP's service ID, etc.)

We will not release any IAQ we have not been certified to release, in the future, using the same method.

4.2.7.3 Cryptographic Security

The assertion content is protected via use of a TLS channel between the IdP and the SP for both the artifact resolution/attribute service (port (8443, etc)) and the SSO (port 443) endpoints.

We do not list any non-TLS protected endpoints in InCommon metadata, and our IdP does not respond to requests in the clear.

The certificate used by our IdP for signing and encryption of assertion content is listed in InCommon metadata, and we can sign and encrypt assertion content on request.

The InCommon metadata (http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml) lists the endpoints of our IdP.  Additionally, the IdP's relying-party.xml file lists configured endpoints for sets of entityIDs.

Use of OpenSSL to query and verify the certificates used on ports (443, 8443, etc.) of our IdP is possible.

  • No labels