WORK IN PROGRESS

 

See tracking information in the GÉANT Harmonisation task: 1.1 Entity Categories.

Purpose

This document aims at presenting a status of the adoption of entity categories within the eduGAIN inter-federation. Thus, it will focus on trans-border service providers (SP) that are republished in eduGAIN metadata. Studying the current adoption of categories and policies of those SP will help identify the successful uses or the remaining challenges for upcoming SPs. Are the categories or policies adopted and used in practice and what could be the obstacles of further deployments. This document tries to give a current view of the remaining challenges for scalable policies that would make federated services more accessible through research communities.

Challenges

            Attribute release and trust among providers in identity federations are the key element for a successful collaboration. Trust is settled through the federation's legal framework on which providers agree. The attribute release on the other hand is a more complex problem, technically and legally (data protection).

To overcome this, several attempts to categorise service providers had emerged in the recent years. Some categorisation involves data minimisation and purpose limitation on attributes release when others try to group service providers based on their business profile and common attributes requirements.

The most significant efforts in the policies area are the "GÉANT Data Protection Code of Conduct" (CoCo)[1] in its European version or in its coming international form and the "REFEDS Research and Scholarship" category[2]. Other categories are already being considered or in an advanced discussion (Academia, library...). Even if the GÉANT CoCo is more than just a SP category, on the metadata level, service providers and the agreeing identity providers are tagged as a SAML 2.0 Entity Category.

Tools

In order to find the informations, we use the tools that eduGAIN is offering now:

This study is bounded to the publicly available informations on eduGAIN tools reading the aggregated metadata.

Status on Categories Use

Using the latter tool, we can easily extract the entities that have endorsed the R&S category or the GÉANT CoCo. The figures are edifying, only 190 (without sorting out the duplications) entities on 2385 entities announce the Category/Policy support.

GÉANT (EU/EEA) Data Protection Code of Conduct:

  • 105 entities in total
    • 42 IdP
    • 63 SP

REFEDS Research & Scholarship Category:

  • 85 entities in total
    • 39 IdP
    • 47 SP

The GÉANT CoCo and the REFEDS R&S are finalised for about a year, we notice that the adoption is slow among the community.

The two documents are yet short and clear, but the national federations operators should help their deployment by:

  • Advertise them toward the SPs;
  • Possibly translate them in the country's language;
  • Implement a way of tagging the entities that support categories during the entity's recording (federation registry).

In practice, the IdPs have to technically be able to release the necessary attributes to the categorized SPs, when these have to be legally reliable on processing those attributes.

The two categories above are not covering all the types of SPs (commercial, business models...) or the communities that are running them (Physics, libraries...). Others categories are surely needed but an effective way of presenting them and help the right SP to find its right category.

Some federation have already put in place national categories to help IdP managers to easily scale their attributes release mechanisms. The way to group SPs is the way to go to avoid per SP attribute filtering. Such categorisation needs clear definitions and federations' operators should be in charge of advertising and implement at the federation registry level the categories. Indeed, categorizing SPs should also lead to common attribute requirements uses. These attributes subset must be negotiated with SPs managers to lower at maximum the mandatory attributes and tag the possible others as optional.

The Federation Éducation-Recherche experience (FR)

The French academic federation introduced SPs categories 4 years ago (2011). For each category, they distributed a set of attributes filters that automated the attribute release at the IdP level. They noticed that IdPs managers are generally not keen to regularly update their IdP configurations. Indeed, there is always a risk of breaking the service. A vast majority started to simply use the filters containing all the categories even is it is not a satisfying use, privacy wise.

Because the Shibboleth software is based on SAML2 specifications, that implementation allows dynamic attribute release "negotiation", i.e. exploiting <md:requestedAttribute> elements[3]. The French federation's administrators will progressively abandon the automated filters distribution and rely more and more on that feature. But even with this feature, IdPs managers and data privacy officers want to have a way to distinguish between SPs. GÉANT EU/EEA CoCo is a way to scale effectively in attribute release. Federation operators should, in the first place, the adoption of this policy.

Remark: Other feedbacks from the academic federations running categories for a significant time would be enlightening.

The DFN-AAI Experience (DE)

The Identity Federation operated by the German Research and Education Network (DFN) introduced Entity Categories (both for SPs and IdPs) in 2012 in order to support so-called "Virtual Sub-Federations". The setup is based on a whitelist maintained by a specific project or community and which is hooked up with the metadata registry. The project-specific EC is only available for entities listed on such a whitelist - a nightly check removes the EC automatically if an entity disappears from the respective whitelist. Using such an EC, (Shibboleth) SPs are able to select all project-related IdPs from the federation metadata and ignore the rest, while IdPs only have to set up one Attribute Filter Policy in order to release Attributes to a dynamic number of project-related SPs. This concept turned out to be quite popular, meanwhile (2015) three of these ECs are in use, a fourth one has been requested recently.

The CoCo EC was introduced in July 2013, R&S in 2015.  While many SPs registered with the DFN-AAI committed especially to the Code of Conduct, the acceptance by German IdPs is still improvable. One reason for the reluctance of German IdP admins to support the CoCo and R&S ECs is the strictness and complexity of data protection laws and regulations in Germany, cf. http://dariah-aai.daasi.de/attribute-release_and_legal-stuff_wp.pdf

The Greek Federation experience (GR)

The Greek Federation, operated by GRNET has introduced Entity Groups in the published metadata, utilizing multiple EntitiesDescriptor elements. The groups match SPs with different trust levels in the federation ( GRNET's own Services SPs, Microsoft services for higher educational institutes, others ) but are not formally defined. Since GRNET operates the majority of the IdPs of the Universities participating in the federation, respective attribute release policies have been deployed in the Identity Providers, utilizing AttributeRequesterInEntityGroup type rules for matching the SP and releasing the necessary attributes.

As this set up is neither optimal nor well maintainable, the Greek federation is in the process of introducing a number of national Entity Categories (both for SPs and IdPs) in the federation. The main drivers for the change are:

  • Simplicity in the federation metadata aggregation and publication
  • Formal definition of Trust Levels
  • Enhanced granularity
  • The introduction of new Identity Providers ( Hospitals ) in the federation that have stricter requirements for attribute release. 

The work is ongoing and the preliminary plan is to introduce the Entity Categories in 2016. No decision has been made yet as to whether eduGAIN defined Entity Categories ( GÉANT CoCo , R&S ) will be used. 

The attributes values issue

Some community SPs, like libraries or research communities[4], need the provision (release) of a certain attribute (e.g. affiliation, entitlement, isMemberOf...) plus a certain value often tailored to those SPs. This scenario is the most complex. Indeed, it forces the IdP manager to intervene and update the values in the IdP back-end (affiliations) or to dynamically generate a new value (entitlements) for a given new SP.

Defining categories on attributes values should also be considered to ease the deployment at IdP level. These categories would restrict or make use of common attributes and values for a given group of SPs or rely during the authorisation process on Attribute Authorities (community IdPs) additional (custom) attributes.

Conclusion

Defining what makes a category or a policy a good and scalable "framework" would be necessary. In the mean time, actions of instruction and accompanying should be taken within national federations and followed at the eduGAIN level. Community SPs and their requirements should be well defined and categorized before exchanging with IdPs managers.

  • No labels

8 Comments

    • Advertise them toward the SPs;

    and IdP/Home Organisations

  1. Implement

    Not just help tagging entities in the upstream metadata but also help the peer entities to properly consume the Entity Category tags in the downstream metadata. How this is done depends much on the federation; hub&spoke is much different from a full-mesh federation, SimpleSAMLphp is diferent from Shibboleth etc. Some full-mesh federations (like SWITCHaai and Haka) provide web-based tools for configuring the consumption of ECs in metadata, some federations(like SWAMID and UKfed) just scripting.

  2. Attribute release

    Is encouraging IdPs to release attributes the only use case for Entity Categories in this document? I could imagine that we in the LoA task could use ECs to indicate an IdP's cabability to offer a certain LoA level and the Sirtfi people may want to use ECs to indicate that an IdP is committed to follow certain Incident response practices?

    1. Indeed Mikael, using entity categories for regrouping same LoA IdPs is something that should be done. It is tagging IdPs to give SP's admins more control to whom they're providing their services. But the most challenging part is not connecting providers but make IdPs send the right attributes with the right value (entitlements) or trust (quality provisioning).

  3. all the types of SPs (commercial, business models...) or the communities that are running them (Physics, libraries...).

    The GEANT CoCo covers all types of SPs. It's limitation is currently that the SP-organization must be established in EU/EEA, the EC whitelist of countries or the US safe harbor.

  4. The Federation Éducation-Recherche experience (FR)

    I'm not sure if your plan was to list all federations who have domestic entity categories, but SWAMID has them too: https://portal.nordu.net/display/SWAMID/Entity+Categories

    1. Not list them all, but have some feedbacks from some federations that are using EC for quite some time (more than 2 years) and see how far the adoption has gone and if it really solved scaling problems.

  5. complex

    Indeed, asking IdP admins to populate specific attributes for individual SPs is an order of magnitude more difficult than asking IdP admins to configure attribute release for a small number of Entity Categories. Therefore, I wouldn't count on it.