Episode 02 -InCommon Federation -Metadata Service
The trust and communication between entities participate in the InCommon Federation are based on the metadata of each entity. During the registration process, an organization should submit the metadata related to its Identity Providers and Service Providers to the federation manager. Then Incommon registrar aggregates metadata related to SAML entities, validates and signed them to download by the consumers of the federation.
InCommon Federation is a multilateral federation because an entity shares its metadata with different other entities. InCommon Federation has a proper procedure to manage and maintain metadata of entities. It posses metadata of all the participants and metadata from the eduGAIN global inter-federation.
As I mentioned in my previous blog Introduction to the InCommon, SP needs metadata of the user’s IdP when it needs to send the authentication request to the relevant IdP and IdP needs metadata of the SP before authenticating the user.
But how the SPs and IdPs acquire metadata of other entities? At present InCommon use two different methods.
- Metadata Aggregates: Legacy Metadata Distribution Process
- Per Entity Metadata Distribution Service
I am going to talk about the aggregate-based metadata service from this blog.
Metadata Aggregates
All entity metadata distributed by InCommon is in the form of signed SAML metadata aggregates. InCommon creates different types of aggregates based on different usages.
Preview aggregate — Preview aggregate is used to introduce new changes to the Incommon metadata before adding them to the main aggregate. (http://md.incommon.org/InCommon/InCommon-metadata-preview.xml)
Main aggregate — Deployments refresh metadata from the main aggregate. (http://md.incommon.org/InCommon/InCommon-metadata.xml)
Fallback aggregate — Fallback aggregate is used when a change in the main aggregate breaks the downstream process. (http://md.incommon.org/InCommon/InCommon-metadata-fallback.xml)
IdP-only aggregate — IdP-only aggregate contains metadata related to IdPs. (http://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml)
Metadata consumers can download aggregate files from an HTTP server operated directly by InCommon and housed in an Internet2 data centre. There is a disaster recovery server also. An entity (SP or IdP)should first select an aggregate and download a copy of the metadata signing certificate. After downloading an aggregate through the main aggregate URL it can create other SPs and IdPs after validating the signature and last modified date. So when an entity needs to access another entity we do not have to worry. We have already validated and configured the entity. To refresh metadata it can use HTTP Conditional GET and needs to validate the expiration date and signature.
With this process, entities cannot download metadata specific to an entity. They need to download the whole aggregate and use when they want metadata of a specific entity. But Incommon strictly specifies that all the entities should refresh metadata daily and encouraged to do it frequently as possible.
With the registration of many organizations in InCommon federation, it led to creating many problems in the federation process because aggregates started to expand. They introduced “Per Entity Metadata Distribution Service” as a solution to this problem.
If you want to know about the PEMD service you can go to my next blog.
References
