The Network Startup Resource Center (NSRC) has developed a series of videos that will take you through the policies and technologies of identity management on a local level, as well as how identity federations like InCommon are of value. There are 10 videos that cover the topics below. You will find background information at the NSRC's website. The NSRC produced the videos in partnership with GEANT (the pan-European network and a fundamental part of Europe's e-infrastructure).
Here is a list (and links) of the videos.
Campus Identity
- eduroam and Identity Services
- Introduction to Identity on Campus
- Identity and the Campus Network
- Identity and Cloud Services
- Defining Users
Federated Identity
- Introduction to Identity Federations
- Identity and Access Management for Researchers
- Identity Federation for Service Providers
Identity and Business Models
Internet2 has started deployment of a new service desk, ServiceNow. As of March 27, all email sent to our support address (admin@incommon.org) will create a ticket in ServiceNow, which will generate an automated email response The same set of InCommon/Internet2 people will respond to requests through the new service desk system. We will continue to use admin@incommon.org for support requests from participants and certificate service subscribers.
Over the last three years, we have seen significant increases in the volume of mail to admin@incommon.org. ServiceNow will help us organize and respond to your requests in a more efficient and timely manner. We hope you find this change helpful, and we're always open to your feedback (email admin@incommon.org). Increased maturity in both service delivery and operations are among InCommon’s main work areas for 2017, and this move to ServiceNow is critical to achieving those goals.
March 22 TAC Work Plan Webinar
Wednesday, March 22, 2017
2 pm ET | 1 pm CT | Noon MT | 11 am PT
https://internet2.adobeconnect.com/iam-online
The InCommon Technical Advisory Committee (TAC) will present its draft 2017 work plan during this webinar, March 22, at 2 pm ET. The TAC provides recommendations related to the technical operation and management of InCommon. The work plan outlines the proposed technical priorities, particularly for the InCommon Federation.
This webinar is intended to gather community feedback on the work plan. This year’s draft plan includes these topics (among others):
- Support for OAuth/OpenID Connect
- Improving IdP discovery (Discovery 2.0)
- Less restrictive attribute release policies
- Improve Service Provider onboarding processes
Please plan to join us to learn about the 2017 plans and provide feedback and suggestions.
The OpenID Connect Survey Working Group, chartered by the InCommon Technical Advisory Committee (TAC), recently conducted a study to understand the community’s interest and use of OIDC/OAuth protocols. The survey also asked how InCommon and Internet2 may help campuses in the adoption of these protocols.
The results are in. The survey working group has compiled a report summarizing the survey findings and the working group's recommendations. You are invited to review the report and provide feedback. The deadline for comments is March 24, 2017.
Shibboleth Installation Workshop - June 13-14, 2017 - Denver, Colorado
InCommon Shibboleth Installation Workshop
June 13-14, 2017
University of Denver
Denver, Colorado
Registration: www.incommon.org/shibtraining
Denver details: https://spaces.at.internet2.edu/x/rIKTBg
Registration is open for the an InCommon Shibboleth Installation Workshop June 13-14, at the University of Denver. The two-day training sessions cover both the Identity Provider and Service Provider software, as well as some integration issues. The workshops focus on installing and deploying IdPv3 and the Shibboleth Service Provider. Here is what you can expect:
• A two-day, directed self-paced workshop
• Hands-on installation of the identity provider and service provider software
• Experienced trainers providing overviews and one-on-one help
• Discussions on configuration and suggested practices for federation
• Attendance is limited to 40
The workshops will offer the chance to:
• Install a prototype Shibboleth identity or service provider in a virtual machine environment
• Discuss how to configure and running the software in production
• Learn about integration with other identity management components such as LDAP and selected service providers
Knowledge of identity management concepts and related implementation experience is strongly recommended. Organizations are encouraged to send one or two attendees who best represent the following functions:
• System install, integration, and ongoing support staff
• Campus technology architects
To learn more about Shibboleth, see the Shibboleth wiki (wiki.shibboleth.net). More information on federated identity can be found at www.incommon.org.
InCommon Shibboleth Installation Workshop
April 4-5, 2017
University of Michigan (Arbor Lakes Dome)
Ann Arbor, Michigan
www.incommon.org/shibtraining
Registration is open for the first InCommon Shibboleth Installation Workshop of 2017, April 4-5, at the University of Michigan in Ann Arbor. This two-day training session covers both the Identity Provider and Service Provider software, as well as some integration issues. The IdP portion of the workshop is based on IdPv3.
We will focus the training sessions on people who wish to learn about and deploy IdPv3. Here is what you can expect:
- A two-day, directed self-paced workshop
- Hands-on installation of the identity provider and service provider software
- Experienced trainers providing overviews and one-on-one help
- Discussions on configuration and suggested practices for federation
- Attendance is limited to 40
- Registration closes March 17
The workshops will offer the chance to:
- Install a prototype Shibboleth identity or service provider in a virtual machine environment
- Discuss how to configure and running the software in production
- Learn about integration with other identity management components such as LDAP and selected service providers
Knowledge of identity management concepts and related implementation experience is strongly recommended. Organizations are encouraged to send one or two attendees who best represent the following functions:
- System install, integration, and ongoing support staff
- Campus technology architects
For more information and a link to register, go to https://spaces.at.internet2.edu/x/9wJ-Bg
To learn more about Shibboleth, see the Shibboleth wiki (wiki.shibboleth.net). More information on federated identity can be found at www.incommon.org.
Nominations are open for the instantiation of CACTI, the Community Architecture Committee for Trust and Identity. This new committee will provide technical guidance and inform the strategic direction for Internet2's Trust and Identity (T&I) services. CACTI membership must comprise and connect a range of perspectives and experiences, established and rising community technical leaders, and national and international backgrounds.
Nominations for membership, including self-nominations, may be made using this nomination form. Nominations will be accepted through midnight (EST), March 8, 2017. The goal is for the first meeting of CACTI to occur online shortly before the upcoming Internet2 Global Summit, April 23-26 in Washington DC.
CACTI's charter describes its duties, membership, and other details, and its role in the ecosystem of T&I related Internet2-sponsored community guidance is described in https://internet2.box.com/v/commarchguideI2TI.
Over the years, the Internet2 community together with national and international partners has helped to shape the research and education identity and trust landscape. Going forward, CACTI will play a large part in continuing this important work.
At the request of the InCommon Certificate Service community, Comodo has created a new system that will greatly streamline the issuance of EV (extended validation) certificates. This new system is called “Anchor Certificates.” Cert Service subscribers can now request an Anchor Certificate, and apply it to all of their domains, then go through the industry-mandated EV process once for all of the domains, which will streamline future EV certificate requests. This will not actually create a new certificate, but uses the same validation process as with EV certificate requests. Once the Anchor Certificate is set, EV cert requests are treated just like any other cert, without going through the EV validation process again for 13 months. Under the current process, each EV cert request went through the entire validation process.
In conjunction with Comodo, we have published a wiki page that details the process of ordering an anchor certificate.
The InCommon Certificate Service Working Group surveyed certificate subscribers last year and had a number of recommendations. This is one step toward improving the EV documentation and process. Survey results and the 2017 work plan will be detailed over the next few weeks.
Once again this year, we intend to schedule four Shibboleth Installation Workshops at campus locations in various regions. These are two-day workshops best described as directed self-paced workshops that cover both the IdP and SP software, as well as some integration issues. This year we also intend to offer material about the TIER software package (of which Shibboleth is a part).
I’m looking for campuses interested in hosting one of the 2017 trainings. The campus responsibility is to provide a room that will comfortably hold 44 people with laptops, pads of paper and cups of coffee. The campus also provides a robust wireless network and arranges for catering for said coffee, as well as lunch and refreshment breaks. InCommon provides the trainers and will handle the registration process. In return for hosting, we provide two complimentary registrations for the campus.
A couple of the considerations in selecting locations are:
- Region (we try to spread these around to make travel easier for attendees)
- Relative ease of travel (such as proximity to Interstates and at least a medium-size airport)
You can see our host outline for details: https://goo.gl/0o3YdL
If you are interested in at least exploring hosting one of these events, please send me email (woodbeck@internet2.edu).
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.
If you are new to federated identity management and plan to attend the Technology Exchange in Miami (Sept. 25-29), consider registering for Base CAMP (Sunday afternoon, Sept. 25). Base CAMP will:
- Provide an overview of the InCommon Federation and the identity and access management professional field
- Cover the basics of federation, including the trust framework, metadata, attribute release, and international interfederation
- Introduce software and supporting technologies, including Shibboleth and TIER (Trust and Identity in Education and Research)
- Include information on related and emerging issues (like multifactor authentication and alternative IdPs)
You will then be ready to dive into the rest of the Technology Exchange, including a day-and-a-half of track sessions (CAMP), an afternoon of working group meetings, and the unconference Advance CAMP (ACAMP), including discussions of community-wide issues and proposed solutions. ACAMP concludes Thursday (Sept. 29) at noon. You will find the full schedule for the 2016 Technology Exchange, along with registration and hotel information, at https://meetings.internet2.edu/2016-technology-exchange/
With InCommon interconnected to the global federation community, participants now have the opportunity to take part in and support policies and standards being developed internationally. One of the most promising collaborations in this area is the Security Incident Response Trust Framework for Federated Identity (Sirtfi). Developed by a working group comprising international research, campus, and federation operator community members, this framework and related entity tags for IdPs and SPs serves as a first iteration of a global federated incident response approach.
Very shortly, InCommon will begin a proof of concept to support the federation role of the Sirtfi framework for three InCommon identity providers (and a few SPs to be identified) to enable international experimentation with and further refinement of the Sirtfi framework and to continue the community’s work to increase trust within and across our federations. This proof of concept will affect our trust registry/metadata aggregate, but should have no impact on any operations.
This proof of concept will include very scoped support for Sirtfi including:
- Importing the Sirtfi entity attribute for those international IdPs and SPs that have chosen to adhere to the specification along with importing the REFEDS Security Contact metadata into InCommon metadata from eduGAIN.
- Adding to the InCommon aggregate and exporting to eduGAIN the REFEDS security contact and the Sirtfi entity attribute on the entity descriptors of the following IdPs:
- NCSA
- LIGO
- The University of Chicago
- Adding the Sirtif tag to several LIGO SPs
Given the Sirtfi federation operator obligations have not been finalized, InCommon is working to confirm with these IdP operators and their executive contacts that they comply with the framework by having them self assert to the requirements.
InCommon Shibboleth Installation Workshop
October 27-28, 2016
California State University Office of the Chancellor
Long Beach, California
www.incommon.org/shibtraining
Registration is open for the final InCommon Shibboleth Installation Workshop of 2016. This two-day training session covers both the Identity Provider and Service Provider software, as well as some integration issues. The IdP portion of the workshop is based on IdPv3.
We will focus the training sessions on people who wish to learn about and deploy IdPv3. Those interested in upgrading from v2.x will also find value, but we will mainly cover IdPv3 as an independent topic to ensure we deliver the clearest content possible. Here is what you can expect:
- A two-day, directed self-paced workshop
- Hands-on installation of the identity provider and service provider software
- Experienced trainers providing overviews and one-on-one help
- Discussions on configuration and suggested practices for federation
- Attendance is limited to 35
- Registration closes October 10
The workshops will offer the chance to:
- Install a prototype Shibboleth identity or service provider in a virtual machine environment
- Discuss how to configure and running the software in production
- Learn about integration with other identity management components such as LDAP and selected service providers
Knowledge of identity management concepts and related implementation experience is strongly recommended. Organizations are encouraged to send one or two attendees who best represent the following functions:
- System install, integration, and ongoing support staff
- Campus technology architects
For more information and a link to register, go to https://spaces.at.internet2.edu/x/p4AQBg
To learn more about Shibboleth, see the Shibboleth wiki (wiki.shibboleth.net). More information on federated identity can be found at www.incommon.org.