Skip to end of metadata
Go to start of metadata

The PEER software and the REEP service were developed to provide a single point of registry for SAML entities.  In most current identity federations, the federation runs its own registry locally and expects each entity to be able to prepare and deposit entity metadata with that registry.  For some entities this is challenging, particularly where the entity is a member of multiple federations and is then required to maintain and keep up-to-date information on each of those entities in multiple places.  The MET tool can be used to highlight this.  The entity https://met.refeds.org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.com/ is in 24 different federations and the metadata maintained at each is different.  

A short FAQ is available. 

PEER Software

The PEER software is intended to provide a lightweight registry service that relies on domain validation only to assess whether a service can register any given entity.  The software is available for general use and can be "skinned" for different service appearance.  The software is currently available on Github and is maintained by Emergya under contract with REFEDS. Documentation on how to use the service is available

REEP Service

The REEP Service is an instance of PEER managed by REFEDS for use by the REFEDS community as a testbed for the concept of using an external registry for federations.  It runs under the current lightweight policy.

SP Registration Problems

The problem of registering Service Providers with federations is being looked at by both GN4 (Enabling Users) and the AARC project.  Federations can be confusing to join, typically for the following reasons:

  • Requirement to sign legal documents and meet certain criteria.
  • Unclear where a "home" federation for the SP is in a global operation environment.
  • Recommendations to join federations that do not fit normal portfolio for the SP (i.e. different languages etc.). 

There are some solutions looking a supporting these requirements, such as the GrIDP Identity Pool federation set up in Italy.   It is unlikely that a service like REEP would ever be able to provide a complete solution to these issues with the absence of policy documentation within REEP - eduGAIN for example requires registering federations to have clear policy and does not register SPs directly without the trust framework of the federation policy - but REEP could form part of a solution to alleviate the burden.  It may be sensible for the community of identity federations to consider appointing a role to help act as Service Manager for SPs (and indeed IdPs) with the challenges of joining federations. 

 

 

 

 

  • No labels