InCommon Steering Committee Minutes - February 3, 2020


Attending: Ann West, Dee Childs, Ted Hanss, Michael Berman, Sean Reynolds, Laura Paglione, Brad Christ, Dave Robinson, Marc Wallman, Chris Sedore

With: David Bantz, Von Welch, Tom Barton, Steve Zoppi, Jessica Coltrin, Janemarie Duh, Kevin Morooney

Informational Items

Vice-Chair Election

Laura Paglione left the call for this discussion.

Mike Erickson has resigned from InCommon Steering, as he is now the Associate Vice President for Community Engagement at Internet2. This has created an opening for the Steering vice-chair. As he was vice-chair of Steering. 

It was moved, seconded and unanimously approved to elect Laura Paglione as vice-chair of InCommon Steering.

Steering will not immediately fill Mike’s slot. 

Laura rejoined the call.

(AI) Ted will send email soliciting interest in the secretary role. The secretary is part of the executive committee, so has an additional one-hour meeting for agenda-setting, and also services on the PAG, which is an additional one-hour meeting.  

Research Engagement

Tom Barton joined the call. Tom splits his time between the University of Chicago (working with research projects and research labs in the area of security) and Internet2, where he focuses on moving forward InCommon’s support for research infrastructure.

Tom discussed how InCommon and federated identity and access management relates to enabling research.

Gateways and proxies have been developed to connect the world of federation with the research infrastructure world. We aren’t talking about working with individual researchers, but campus IT and/or operations that support research.

Some examples:

  • These can be portals like XSEDE
  • There are almost 600 science gateways. Not all use federation, but some do
  • Research computing centers on campus might have a gateway or a bridge to federation
  • Some individual research labs might have a gateway or proxy
  • Cloud access portals
  • An academic dept might stand up a website to share with colleagues from a couple of other campuses

Why do these projects want to incorporate what we do into their work?

  • Minimize time they need to invest in user credentials (outsource all that to us)
  • Federation can ensure that user login information is trustworthy and accurate
  • Services like the Research & Scholarship category
  • Assertions - are the assertions accurate? Say, when you say a person is a faculty member, are they really?
  • Consistency - all of the information passed along is the same from every organization. So don’t have to code in a bunch of exceptions.
  • Reliability of characteristics over time

When we created the federation, we assumed everything that might benefit from it would also belong to it. But that’s not the case. Gateways and proxies are, in many cases, between the research application and the federation. Two examples are CILogon and GlobusAuth. 

  • CILogon has close to 100 service providers behind it that are not registered for InCommon or another federation. It is a gateway. Might be research computing centers. Cloud access portals. 
  • GlobusAuth - The Globus Data Transfer Node passes huge amounts of data all around the planet. They use GlobusAuth, which in turn relies on CILogon to enable people to log into GlobusAuth through federation.
  • More than 1,000 places rely on GlobusAuth - none of which belong to any federation. This represents more organizations than any federation globally other than InCommon and the UK Federation. 
  • InCommon has no direct connection to many of these services. This is important when thinking about sustainability and business models and fee models

These research services weren’t designed to integrate with federation, and may have pre-dated the federation, but their mission is to do science. The proxy model allows them to benefit from federation without having to know anything about it. There is one point of integration (the proxy) for all of the organizations that are part of the research/science gateway.

These proxies have to have business logic to deal with exceptions since not all users come from a campus with an identity provider. Through federation, the proxies and gateways are looking for us to make things work consistently and reliably across all identity providers. 

Baseline Expectations was a huge step in doing this and there is no more important thing we’re doing now to sustain value for research collaborations. It makes everything consistent. 

The current work on Identity Provider as a Service is also very important. If a campus either can’t or doesn’t want to run a Shibboleth Identity Provider, they still need a way to connect. As we ratchet up the bar for Baseline Expectations, many of the potential requirements (like multifactor authentication and releasing the R&S attributes) only work well with Shibboleth We need another option.

When the IdPaaS working group completes its work, the next step will likely be to determine how to provide the service (should InCommon run it? Should we enter into partnerships with commercial partners?). Steering will be a big part of that. 

Trusted CI

Von Welch discussed his work with research organizations. Von is the principal investigator and director of two relevant projects. One is Trusted CI,  the NSF Cybercsecurity Center of Excellence. The other is the Research Security OPerations Center. 

TrustedCI does consultations and support and a significant part of their work is about federated identity. The challenge for many research projects is their short lifespan - they need to ramp-up quickly and need an architecture for access control.

A related project is the CyberInfrastructure Center of Excellence NSF pilot - federated identity is the thing that TrustedCI is doing in collaboration with the pilot. 

Von also mentioned:

  • Incident response and the overlap with federated identity is an area of interest
  • Researchers don’t know the language of federation, so aren’t in a position to have a discussion. They just want their collaborations to work. It might be just GDoc and email lists, or it may be a virtual organization with some infrastructure
  • There is a lack of a feedback loop for researchers when encountering problems. CILogon and Globus have both spent time diagnosing common problems that occur

What can InCommon do to make the biggest impact?

  • Ubiquitous support for R&S attribute release
  • Error debugging
  • Lowering the barriers - eduroam is the gold standard. We want this to work for science and research just like eduroam works

David Bantz, chair of the Community Trust and Assurance Board (CTAB) said the upcoming additions to Baseline Expectations are not scheduled to include support for R&S. Ann mentioned that there are SAML implementations that can’t support R&S (like Microsoft ADFS). A working group is looking at ways around this, such as offering a gateway for IdPs. 

Next Meeting

Monday, March 2, 2020 - 4 pm ET / 3 pm CT / 2 pm MT / 1 pm PT


  • No labels