Date: Fri, 29 Mar 2024 11:21:57 +0000 (UTC)
Message-ID: <2103499172.7885.1711711317491@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_7884_1313441918.1711711317489"
------=_Part_7884_1313441918.1711711317489
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
InCommon TAC Meeting Minutes - July 17, 2014
Minutes
Attending: Steve Carmody, Tom Barton, David Walker, Scott Canto=
r, Jim Jokl, Ian Young, Steve Olshansky
With: Nate Klingenstein=
, Tom Scavo, John Krienke
Action Items
AI: TomS will provide an outline of a multifactor deployment plan and a =
timeline.
AI: TomS will provide sequence diagrams and other documentation for the mu=
ltifactor migration.
AI: Scott, David, and TomB will reformulate the text in section 7.2 o=
f the FOPP. The group will also look at the text in section 9 in light=
of the Google Gateway and eduGAIN but that may be deemed out of scope init=
ially.
AI: Steve will rev the Metadata Annotation WG document.
Phase 1 Impl=
ementation Plan
- TomS reports the fallback aggregate was synced with the production aggr=
egate on July 1, 2014. This implies that all metadata=
aggregates are now signed using the SHA-256 digest algorithm. Thus the Pha=
se 1 Implementation Plan of the Metadata Distribution WG is now comple=
te.
- No user feedback was received, neither positive nor negative. (One user=
reported a metadata outage since June 9 but that seems to be unrelate=
d.)
- Note: The redirect from the legacy metadata aggregate (which no longer =
exists) to the fallback aggregate will remain in place indefinitely.
Multifactor update<=
/h4>
- John Krienke reports that persistent discussions with Comodo have resul=
ted in a cost effective business agreement and a corresponding technical pl=
an to federate the CM login interface. Overall, Comodo appears to be comfor=
table with mobile-based multifactor authentication.
- A staging instance of the CM with a federated login interface was teste=
d last year. The next phase of the project will allow MRAOs to log into the=
production CM with two factors, a federated password and a mobile device. =
Comodo claims they can complete this work in less than two months.
- Recall that the InCommon RAs have been logging into the FM with two fac=
tors since March 26, 2014 (which is when the Multifactor IdP Proxy was=
moved to production). The MRAOs will leverage the same infrastructure that=
the RAs are using today.
- A Statement of Work with Cirrus Identity for the next version of the MF=
IdP Proxy has been in the hands of the lawyers for over two months. Once t=
he SOW has been blessed by legal, work can begin, which will take approxima=
tely two months.
- The next version of the MF IdP Proxy will allow us to begin migrating S=
ite Admins to multifactor. RAOs will follow almost immediately since the en=
rollment process for Site Admins and RAOs is exactly the same.
- Q: Will the deployment leverage multifactor at the campus IdP if it exi=
sts? A: Initially, the second mobile-based factor will be situated at the M=
F IdP Proxy, but yes, eventually multifactor at the campus will be supporte=
d.
- Q: Is identity proofing (ala Silver) required? A: No, identity proofing=
at the campus is not required. InCommon Operations vets all Site Admins an=
d RAOs but not in the sense of Silver. In particular, the real name of a Si=
te Admin or RAO is of no consequence.
- AI: TomS will provide an outline of a multifactor deployment plan and a=
timeline.
- AI: TomS will provide sequence diagrams and other documentation for the=
multifactor migration.
Changes to the FOPP<=
/h4>
- Steve Carmody started a discussion on the mailing list regarding propos=
ed changes to the FOPP. Scott, David, and TomB responded to the email. The =
focus of the discussion is on section 7 (especially 7.2) and section&n=
bsp;9 of the FOPP.
- There is consensus that the text in section 7 needs to change to r=
eflect current practice in the Federation.
- There is some concern about making statements only about the IdP while =
avoiding statements about the underlying IdM system. OTOH, the IdP is all w=
e control; we don=E2=80=99t control the underlying IdM system.
- Q: Is there a difference between technical control and policy control?<=
/li>
- Q: Is it okay for a participant to authenticate guests with Google? A: =
Yes, that=E2=80=99s why the text needs to change.
- Even though the text suggests otherwise, we shouldn=E2=80=99t dictate t=
o participants how they manage their IdM infrastructure. Today the POP is u=
sed to communicate how a participant=E2=80=99s IdM system functions.
- AI: Scott, David, and TomB will reformulate the text in section 7.=
2 of the FOPP. The group will also look at the text in section 9 in li=
ght of the Google Gateway and eduGAIN but that may be deemed out of scope i=
nitially.
Operationaliz=
ing eduGAIN
- TomS, IJ, and Ian have been meeting regularly.
- IJ created a mini-aggregate containing three LIGO SP entity descriptors=
, which has been ready to go for a couple of weeks now. John and Ann are wo=
rking on the policy implications of exporting the mini-aggregate to eduGAIN=
and interfederation in general.
- At the same, Ian was working on a long-term technical solution.
- The UKf metadata aggregation tooling has been published at GitHub for s=
ome time now. Ian forked the GitHub repository and customized it for this p=
articular use case. The forked repository is now mature enough to be deploy=
ed to production if and when the policy issues are resolved.
- There are links in the agenda to two versions of the mini-aggregate: 1)=
a snapshot of the three LIGO SP entity descriptors manually produced =
by IJ, and 2) the output of Ian=E2=80=99s new process, which runs agai=
nst the InCommon production aggregate. The former is signed using the trust=
ed InCommon metadata signing key while the latter is signed using a test ke=
y. Once Ian=E2=80=99s new infrastructure has been integrated with InCommon =
production infrastructure, the output of the latter will be signed with the=
trusted InCommon metadata signing key.
- Ian=E2=80=99s process operates on the basis of a whitelist of entities.=
It translates InCommon R&S entity attribute values to REFEDS R&S e=
ntity attribute values. That is a temporary measure. There is considerable =
policy work to do before we can export the mini-aggregate to eduGAIN.
- John reported on the status of our policy efforts. Full steering met re=
cently to discuss the policy implications of interfederation. Ann and John =
laid some groundwork at that meeting. Some changes to the Participation Agr=
eement are required, which will take some time.
- The fact that we have a concrete, production mini-aggregate ready to go=
is helping the policy discussion. The question is how to export the mini-a=
ggregate quickly without getting bogged down in a lengthy policy discussion=
. Essentially the question is how to become more agile.
- Q: Do the FOPP changes required for eduGAIN have anything to do with th=
e changes to the FOPP proposed above?
- Ian has also developed infrastructure to produce per-entity metadata, a=
gain built on top of the Shibboleth Metadata Aggregator. As a demo, click t=
he link in the agenda to receive the OSU IdP entity descriptor signed with =
a new key generated specifically for this purpose. This works for all InCom=
mon IdPs (just include the IdP entityID in the URL path as in the example).=
The infrastructure still has some bugs that need to be addressed but it is=
nearly operational.
- Note that the implementation has caching built in and does lazy signing=
. The metadata server (that supports the md-query protocol) is new.
- Next steps: Deploy the per-entity metadata infrastructure on AWS.
- Q: What about per-entity SP metadata, is that on the roadmap? A: No, th=
e focus is on IdP metadata primarily because the Shibboleth SP is the only =
known software that can take advantage of per-entity metadata.
REFEDS R&S=
Migration
This topic has been deferred until a later time.
- The suggestion to annotate metadata enters the conversation quite often=
, so maybe this is the time for a WG to try to address this more generally?=
- Steven has floated a WG proposal.
- The consensus is that folks still don=E2=80=99t have a crisp idea of wh=
at the goals of this WG are. Could the deliverables be more clearly defined=
?
- As an example, InCommon participation should be called out in metadata,=
either directly or indirectly, since some IdP operators base their attribu=
te release policy on the privacy considerations in section 9 of the Pa=
rticipation Agreement.
- Suggestion: focus on the relationships and facts that need to be repres=
ented in metadata (not the technical mechanisms).
- AI: Steve will rev the Metadata Annotation WG document.
No files shared here yet.
------=_Part_7884_1313441918.1711711317489--