Date: Thu, 28 Mar 2024 11:09:20 +0000 (UTC) Message-ID: <854896811.6191.1711624160731@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6190_1107466419.1711624160730" ------=_Part_6190_1107466419.1711624160730 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
On this page, the members of the Interfederation TAC Subgroup are documenting les= sons learned, recommendations, and potential future work areas/items for In= Common to consider on the topic of interfederation. This page is a companio= n to our Interfe= deration Use Cases page.
This is a work in progress. Feel free to edit.
We observe five practical approaches to interoperability of federated id= entities across federation boundaries:
Entity-to-entity metadata exchange: In this method, ent= ities (IdPs and SPs) exchange metadata directly with each other to enable i= nteroperability that is not constrained by federation boundaries. This meth= od avoids federation boundaries by avoiding federations, thereby sacrificin= g the many benefits of federations (scalability, community practice, etc.).= Therefore this is not "true interfederation". Examples include 1) Google A= pps and 2) LIGO's exchange of metadata with the KAGRA IdP in Japan.
Entity joining multiple federations: In this method, an= entity (IdP or SP) joins multiple federations to enable interoperability. = This also falls short of "true interfederation" because interoperability is= achieved only at the entity level and not the federation level. As one exa= mple, LIGO (an InCommon member) is also joining the Italian Identity Federa= tion (IDEM) to enable authentication from Italian IdPs to LIGO SPs.
Bilateral interfederation: In this method, two federati= ons form a bilateral arrangement that enables interoperability across their= combined membership. Each entity need only join its "home" federation. Sca= lability is improved over per-entity methods, though there is still a combi= natorial cost if each federation negotiates separate agreements with every = other federation. Examples include 1) UK Access Management Interfederation tria= ls with Edugate and 2) InCommon and UK Interfederation.
Multilateral interfederation: In this method, multiple = federations join together under a common technical infrastructure and/or po= licy framework to enable interoperability across their combined membership.= Examples include e= duGAIN and Kalmar Union.
Hierarchical federation: In this method, "smaller" fede= rations join "larger" federations to enable interoperability across the par= ticipants in the "larger" federation. Examples include 1) the UT System federation= joining InCommon and 2) regional network providers joining InCommon as= envisioned in the Quilt / InCommon Federation activity.
When an entity joins multiple federations, legal and policy issues (incl= uding signed contracts and fees) often dwarf technical issues. That said, a= global metadata registration service (such as REEP) would ease the pain of joining m= ultiple federations. Then federations would have to devise processes that c= onsume metadata managed at the central service.
Like ADFS which masks entities from the federation
Like IdP Proxies which potentially shift problems/responsibilities = around to different owners and may save, or may not save costs. (SP Proxies= have similar issues).
Interfederating gateways lean toward taking all entities behind it which= may not always be desirable or have entities behind the gateway comply wit= h policies it should.
Virtual organizations or research projects may be unable to sign contrac= ts/agreements with federations which pose a challenge.
The group has found that the Shibboleth Metadata Aggre= gator works well for producing metadata aggregates for interfederation.= We used it to produce aggregates containing InCommon and UK entities for a= n interfederation pilot project with a LIGO wiki SP.
A SAML metadata aggregator written in python by Leif Johansson is also= available.
Given the potential for InCommon to participate in multiple bilateral an= d multilateral interfederation agreements, the group recommends that InComm= on provide a single "interfederation" metadata aggregate to InCommon member= s that includes all external entities, rather than requiring InCommon membe= rs to keep track of different metadata aggregates for different agreements.=
As InCommon adopts interfederation agreements, which InCommon entities (= IdPs, SPs) should be included in the "export" aggregate for consumption by = members of other federations? Requiring entities to opt-in to interfederati= on is a conservative approach that will limit adoption. Enabling interfeder= ation for all entities by default and supporting some form of opt-out is th= e recommended long-term approach. For comparison, the UK federation is doin= g opt-in in the short-term and moving to opt-out in the long-term.
The issues around opt-in and opt-out are vastly different for IdPs and S= Ps. We see no support issues around exposing non-federated SPs to IdPs in o= ther federations, because each SP controls (via the SP's discovery interfac= e) what IdPs are offered to the SP's users. Exposing IdPs to SPs in other f= ederations can introduce new support costs and raise attribute release issu= es (i.e., SPs outside InCommon are not bound by InCommon's Participation Ag= reement). Rather than defining new opt-in or opt-out tags for IdPs, the exi= sting R&S tag could serve as a good interfederation opt-in indicator in= the short term, and in the long-term, a "non-discoverable" tag could serve= to indicate that IdPs should not be used by SPs both internal and external= to InCommon.
Metadata scaling issues should not drive adoption of opt-out or opt-in m= echanisms. Metadata scaling issues should be addressed directly by the fede= ration and its participants and should not be used as an excuse to hinder a= doption of interfederation.
Trust is a core federation concern that applies also to interfederation.= Both technical trust (ex. domain ownership) and behavioral trust (ex. priv= acy policy) are important. The federation's signature over metadata enables= participants to believe in the veracity of the information contained in th= e metadata when making connections with business partners. Metadata tags (s= uch as R&S) can provide trust qualifiers in metadata, indicating for exam= ple levels of assurance and categories of entities.
Regarding behavioral trust, the InCommon participation agreement places = constraints on use of attributes by SPs.
Certificates in metadata are a troublesome technical issue for federatio= ns that insist on the PKIX trust model rather than self-signed certificates= .
InCommon and UK federations have similar entity registration procedures = that include validation of DNS ownership of entityIDs and entity = scope as well as validation of a "canonical name" of each entity for us= e when locating entities in metadata (i.e., finding your business partner's= entities) and displaying IdPs in discovery interfaces.
Registrar validation of IdP OrganizationDisplayName and mdui:DisplayName= is important because SPs show these strings in discovery interfaces. When = importing names from multiple sources, name conflicts may not always be sol= vable at the source (for example, Tsinghua University in different national= federations), and metadata aggregators and/or SPs need to be prepared to a= ddress this through name mapping.
As is well known, sharing of metadata is not sufficient to enable multil= ateral federation. Privacy concerns rooted in FERPA or EU privacy laws inhi= bit the release of attributes and make it difficult to realize "federation = that just works." The same is true of interfederation.
The InCommon Research and Scholarship Category helps to scale attribute re= lease within a federation. Working through REFEDS to agree on categories ac= ross federations could help with attribute release for interfederation.
The Code of Conduct approach relies on a self-asserted metadata tag that= SPs use to indicate conformance to the policy. IDPs could conclude that th= eir liability is sufficiently low if they release attributes that meet the = "necessary for the legitimate interests legal grounds" to = an SP that is asserting conformance to the CoC. This is a good approa= ch in general to scaling attribute release across federations, related to I= nCommon's R&S tag.
The Code of Conduct currently does not apply outsid= e EU, but this is a future work item for REFEDS. EU privacy laws are a chal= lenge for US higher ed entities, which are not eligible for Safe Harbor. Th= ere has been some conversation with the Brussels-based lawyer who helped to= develop the CoC, and he has made some recommendations on how to proceed wi= th extending the CoC.
The Interfede= ration Use Cases page documents interfederation use cases of interest t= o InCommon participants. Currently it seems interfederation is not a high p= riority for most InCommon participants. Of the 60 attendees of the November= 2012 InCommon TAC Priorities Webinar, only 14 voted for interfederation as= a priority "most helpful for you/your institution", making it the second l= owest ranked, ahead only of improved metadata administration. The group's i= nterfed email list has 32 subscribers as of April 2013.
InCommon support for <mdrpi:PublicationInfo> and <mdrpi= :RegistrationInfo> in metadata: Addition of <mdrpi:Publicati= onInfo> to InCommon metadata is now planned. Assuming that goes well, ad= ding <mdrpi:RegistrationInfo> to each entity in InCommon metadata wil= l happen later. This will help with metadata aggregation by clearly identif= ying the registrationAuthority and publisher for each entity. When an aggre= gator publishes metadata, the registrationAuthority won't change but the pu= blisher will identify the aggregator.
Documentation of InCommon registration practices: Build= ing on InCommon FOPP, document InCommon registration = practices to a level similar to UK Federation Technical Specifications. Thi= s documentation will be useful as input to eduGAIN. REFEDS may develop a te= mplate for registration practice statements, and if/when that happens, InCo= mmon should conform to the template. In terms of priority, this work item i= s good to do but is not blocking interfederation work.
InCommon support for hierarchical federation: For examp= le, automated publishing of UT metadata aggregate as input to InCommon meta= data. Starting step could be: Paul logs in to InCommon and gives metadata U= RL. Register certificate that signed it. Related to XML submission. Or dyna= mic referral - InCommon delegates lookups to UT? Also support REEP? Doing t= his helps prepare InCommon for working with regional federations (via Quilt= ). NCTrust is another federation that could pilot hierarchical interfederat= ion capabilities.
InCommon support for bilateral interfederation: InCommo= n could publish metadata aggregate containing InCommon and UK entities for = InCommon a= nd UK Interfederation. This work could serve as a technology prot= otype for work towards eduGAIN, see below.
InCommon joining eduGAIN: First step is to review curre= nt eduGAIN policy framework documents at http://edugain.org/policy.
InCommon providing a production interfederation metadata aggrega= te for its members: As discussed above, a single InCommon "interfe= deration" metadata aggregate would provide a stable source of entity metada= ta for consumption by InCommon members wishing to interfederate with extern= al entities based on current bilateral, hierarchical, and multilateral inte= rfederation agreements.
InCommon enabling the export of a subset of the InCommon metadat= a to be consumed by eduGAIN: To enable federation and interoperabi= lity InCommon entities need to be consumed by eduGAIN after such time that = InCommon joins eduGAIN. Initially InCommon entities could "opt-in" but for = the future an "opt-out" policy would promote more interoperability and supp= ort for international virtual organizations or VOs. A possible first approa= ch is to export InCommon entities in the Research and Scholarship category.=
InCommon support for additional entity tags: As REFEDS = and other groups develop standard entity tags, indicating (for example) whe= ther an IdP should be included in discovery interfaces or indicating an SP'= s privacy policy, InCommon should provide the ability for InCommon entities= to self-assert these tags.
InCommon support for a version of the Code of Conduct that exten= ds beyond the EU: There is a DRAFT of an extension to the CoC that= would allow EU-based IDPs to release attributes to SPs that are InCommon m= embers if those SPs were to assert compliance. This draft should be forward= ed to the InCommon lawyers for review.
See also: June 2013 Recommendations to TAC