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

Compare with Current View Page History

« Previous Version 36 Next »

ACOnet publishes several SAML 2.0 Metadata documents, some of which are documented below.

Signature Validation required for any Metadata consumption

All use of SAML Metadata published by ACOnet requires verification of the cryptographic signature (xmldsig) on that metadata against the published Metadata Signing Key. Trust in any information contained in SAML Metadata published by ACOnet should only be derived from a valid signature with that key, not based on the URL the metadata is downloaded from.

Production

Service Providers only providing services to ACOnet participants can use this limited Metadata document, which only contains entities registered with ACOnet (i.e., those accounted for by formal ACOnet Identity Federation members who are bound by the ACOnet Identity Federation Policy):

Entities registered with ACOnet

https://eduid.at/md/aconet-registered.xml

Federation members who should use this limited Metadata document:

  • Service Providers registering individually with every Identity Federation, such as internationally acting e-resource providers
  • Service Providers which (by the "nature" of their service; e.g. target market or legal status) are limited to subjects from eduID.at member institutions.


All other Federation members will want to make use of the Interfederation-enabled Metadata document, which contains all eduID.at member institutions as well as any SAML entities known via Interfederation agreements, such as eduGAIN. Those interfederated entities are bound by the policies of their respective Registrars or Home Federations.

Entities registered with ACOnet plus Interfederation Entities

https://eduid.at/md/aconet-interfed.xml

Federation members who should use this Metadata document include:

Legacy

All eduID.at production metadata is signed with RSA SHA-2. In case broken implementations incapable of verifying such metadada need to be supported ACOnet still makes available copies of its production metadata signed with RSA SHA-1. The content and intended usage of these legacy metadata documents is otherwise identical to the production metadata described above.

Please notify ACOnet if any of your deployed systems depend on this legacy metadata. ACOnet explictly intends to stop publication of these legacy metadata documents as soon as practically possible. Only registering your need with the eduID.at Operations Team can ensure your dependency on these legacy documents can be taken into consideration.

The URLs to the legacy metadata documents are identical to the respective production metadata with the exception of the /legacy  component in the path:

Legacy copies of the eduID.at metadata

https://eduid.at/md/legacy/aconet-registered.xml

https://eduid.at/md/legacy/aconet-interfed.xml

Metadata validity and refresh

Currently eduID.at Metadata is being signed daily (or more often) and validity (validUntil) is being set to +14 days in the future each time. That means consumers of this metadata will need to refresh (download and evaluate signature) eduID.at metadata at least every 14 days, which a correctly configured software should do automatically. (Note that this validity window may be shortened further in the future without prior notice.)

Consumers of eduID.at Metadata, i.e., SAML IDPs and SPs (and potentially SAML IDP Discovery Services) should refresh eduID.at metadata at least once a day, but may do so more often. The example Metadata Providers in this documentation are set to a 4-hour refresh (i.e., re-downloading and evaluating the eduID.at SAML metadata 6 times a day – or less often if it can be established that the metadata hasn't changed on the HTTP layer, cf. conditional HTTP GET), shortening the time it takes for the software to learn of new, changed or removed entities.

The example Metadata Filters in this set of documentation are using a maximum validity of 28 days, i.e., software configured that way would reject SAML metadata that (a) does not have any upper limit in its validity, and (b) where validity exceeds 28 days in the future. This allows metadata consumers to protect themselfs from overly large "windows of opportunity".

  • No labels