InCommon needs enthusiastic volunteers to bring their unique expertise to the InCommon Technical Advisory Committee (TAC), an advisory body to the InCommon Steering Committee. We invite you to nominate such people for membership on the InCommon TAC, including self nomination.
TAC works best when its members span a variety of perspectives, including (but not limited to):
- universities and colleges of all sorts and sizes
- research organizations, traditional and virtual
- regional R&E network providers
- sponsored partners
- trust and identity solution providers
- international partners
TAC supports InCommon’s mission "to create and support a common framework for trustworthy shared management of access to online resources." Specific duties include:
- review and advise on InCommon's operations, technology choices, and the impact of policies on technical concerns
- review and advise on InCommon service offerings, and make recommendations for new service development and service retirement
- work with InCommon staff to ensure secure, robust, and reliable operation of InCommon services
- engage with the trust and identity community to ensure that InCommon technology meets the needs of the participants
- attend biweekly conference calls and the face-to-face meeting at the annual Internet2 Technology Exchange
The InCommon Steering Committee appoints TAC members to three-year terms. Individuals should have the necessary technical expertise, experience in the education and research community, and a track record of participation in that community.
Please send TAC member nominations to nominations@incommon.org by Tuesday, October 11, 2016. Self-nominations are welcome. Please include some information describing the strengths and experience the individual would bring to the TAC, and the constituencies they are familiar with. Please distribute this invitation to all interested parties.
See http://www.incommon.org/docs/policies/TACcharter.html for the TAC charter (revised December 2015); see http://www.incommon.org/about.html for the current TAC membership. New members would assume their membership in early February. Send questions and comments to Steven Carmody (steven_carmody AT brown.edu), InCommon TAC Chair.
InCommon is conducting a proof of concept for SIRTFI (Security Incident Response Trust Framework for Federated Identity). This is the first step toward supporting a global incident response system for research and education trust federations.
With the ever-increasing and evolving cybersecurity threats, and our increasingly interconnectedness through eduGAIN, federation operators need a way to quickly collaborate in the face of a security incident. One compromised account at an institution can provide access to a multitude of service around the world. SIRTFI provides a framework for an effective coordinated response in the event of an incident.
SIRTFI stipulates preventative measures and identifies organizations that are capable of participating in a coordinated incident response. Federation participants that comply with SIRTFI are marked in the federation’s metadata, raising the bar in operational security across the federation. A very good explanation is available at https://refeds.org/wp-content/uploads/2016/02/Why_Sirtfi.pdf .
InCommon’s proof of concept involves three participants (University of Chicago, LIGO, and the National Center for Supercomputing Applications) that agree to the SIRTFI framework and have the entity attribute added to their metadata. But there are also more than 100 identity providers from other federations with the SIRTFI attribute, and InCommon participants will also see these in metadata.
Once the proof of concept has been evaluated, we anticipate encouraging all InCommon participants to adopt the SIRTFI framework. In the future, we expect this will become a requirement for federation participation.
What can you do right now? One SIRTFI requirement is to have security contacts in metadata. It is a simple process, with your site administrator logging into the Federation manager and adding a security contact. This is useful information to include, independent of the adoption of SIRTFI.
This blog post is from Klara Jelinkova, VP and CIO at Rice University and chair of the InCommon Steering Committee
To the InCommon Community:
Over the summer, Internet2 Vice President for Trust and Identity Kevin Morooney convened several small leadership groups to discuss the two significant services in his portfolio -- InCommon and TIER (Trust and Identity in Education and Research). These “paths forward” meetings identified the top priority areas and associated costs for both InCommon and TIER, and resulted in a set of strategic recommendations.
Before moving to the specifics about InCommon, I want to briefly touch on the relationship of InCommon and TIER. TIER has been established to integrate, modernize and professionalize the trust and identity software stack, with Shibboleth, Grouper, and COmanage as the three main components. Just as important as the software, TIER will also work to standardize campus practices in key areas of trust and identity. One example is committing to always operating with supported versions of the software. Another is to adopt the recommendations of community working groups as they are rolled into TIER (such as baseline practices currently under development).
In our discussions about InCommon, it became clear that the InCommon Federation has become critical infrastructure for our campuses and is increasingly important for national and global research collaborations. Many campuses rely on federated identity management to support integration with mission-critical cloud services. The capacity for urgency, responsiveness, and quick action on the part of the Federation operator has become an absolute necessity.
Of the many areas we discussed, two priorities related to InCommon stand out:
- Assure the continued maintenance of software, focusing on shoring up components that either support existing services we rely on (such as the InCommon Federation) or software broadly deployed on campuses.
- Address risks to Federation operations. The InCommon Federation does not currently have the resources to operate at the quality and security levels required and expected by those who rely on this critical service.
For InCommon, the key shoring up of software means support for Shibboleth. Approximately 90 percent of InCommon participants rely on Shibboleth, but development of the software is severely underfunded. Internet2 is a key member of the Shibboleth Consortium; we and our partners in the Consortium must develop a model that provides the necessary resources to sustain and evolve the software, including such significant enhancements as support for OpenID Connect.
We also identified a number of risks to the federation; most fit in the category of hardening and sustaining operations. We need to achieve an acceptable risk profile reflective of participant dependency on the federation, including disaster recovery, business continuity, an up-to-date support ticketing system, software quality assurance processes, and scheduled security reviews.
We must also scale the Federation operations and infrastructure for the future to address critical items such as metadata exchange and delivery and adoption of campus requested services such as OpenID Connect. Adding services requested by the community also puts a strain on Federation operations (such as integration with the eduGAIN global interfederation service, the Steward Program for K-14, and support for other initiatives). All of this must be factored in to our planning (and, frankly, to our fee structure).
Another risk, as we aim for scalability and growth, is the need for participants to adhere to standards of interoperability, security, and trust practices. The value for vendors decreases when research and education participants don’t all support common baseline standards. Likewise, when vendors fail to fully support standards, the value for education and research participants decreases. As we approach 1,000 participants, common standards and practices becomes paramount.
What does all of this mean for you as an InCommon participant? One is that the InCommon Federation operator must commit to (and be funded for) establishing business and technical operations that ensure superior service, support, and enhancements. The other is that, as InCommon participants, we must commit to common interoperability, security, and trust practices. And finally, we all need to understand the costs of providing a mission-critical service, and how the fee structure will need to change to support such a service.
In two weeks at the 2016 Internet2 Technology Exchange, the InCommon Steering Committee will continue the discussion about the gaps between expectations and resources, and how the fee structure might change to provide the necessary support. We will report back to you about those discussions and plans for community conversations and feedback.