| Version: | 2014-06-06 |
|---|---|
| Author: | Peter Brand |
| Organization: | ACOnet |
| Contact: | eduID.at <eduid@aco.net> |
| Latest Version: | https://eduid.at/policy/mdrps/ |
This document describes the SAML metadata registration practices within the ACOnet Identity Federation. In case of contradiction the rules from the Federation Policy prevail.
Referenced SAML Metadata Specifications, by XML namespace declaration used:
Terms
1. The Federation will generally only register SAML entities on behalf of members of the Federation, i.e., legal entities who have agreed in writing to be bound by the Federation Policy.
2. The FOP may chose to register SAML entities during (i.e., before the completion of) the formal joining process in good faith that a signed formal agreement will be recieved from the prospective member within a reasonable time. This is to avoid having dependencies between technical and non-technical issues delay the joining process unduly. After that the entity will either be formally registered (as in 1.1) or removed.
3. The FOP may also chose to sponsor the registration of SAML entities in the exceptional case where a service is considered to be of value to federation members but the party responsible for the SAML entity is not currently willing or able to formally join the Federation at that time.
1. ACOnet participants may register SAML entities in any role and join the Federation by signing a supplemental agreement.
2. Organizations which are not regular ACOnet participants may only register SAML entities in the Service Provider or Attribute Authority role and join the Federation by signing the SP-Agreement.
1. Any request for entity addition, change or removal from (prospective) Federation members needs to be communicated from or confirmed by their respective registered representatives (once established), i.e.
2. Communication of change happens via E-Mail to the FOP (at <eduid@aco.net>), with signed email (S/MIME, OpenPGP) strongly preferred.
The FOP may amend or modify the Federation metadata at any time in order to, for example, but not limited to
The FOP will ensure that any entity registered satisfies the following criteria, that
- values and ownership of any referenced namespaces (DNS names, URIs, etc.) are appropriate, e.g. in md:EntityDescriptor/@entityID or protocol endpoint URLs,
- any shibmd:Scope extension elements represent security domains of the organization, or authorization from the owner of the security domain has been presented (if applicable),
- any text content (e.g. in md:Organization, md:ServiceName or mdui:Description elements) properly represents the organization or service(s) concerned,
- requested attributes (expressed as md:RequestedAttribute elements) are not excessive or unreasonable, in consultation with the organization requesting the attributes (if applicable),
- any contained mdattr:EntityAttributes extension elements are defined to be freely self-asserted, and otherwise either remove them or perform appropriate review prior to registering them.
The FOP will also review any request for entity addition or change with regard to whether
- specified URLs are technically reachable,
- protocol endpoints are properly protected with TLS/SSL certificates,
- TLS/SSL certificates on user-facing protocol endpoints are trusted by selected HTTP User Agents (or Operating Systems' Trust Stores),
- TLS/SSL certificates on non-user-facing protocol endpoints match the entity's trust fabric keys published in SAML metadata (if applicable).