InCommon Forum – Oct 3, 2012
Internet2 Fall Member Meeting
Overview – Renee Shuey
TAC has developed short- and long-term technical priorities for InCommon, which is the topic of the first part of this forum. These priorities support the long-term goals of InCommon:
• Increase participation by US R&HE organizations
• Interfederate with all other R&HE federations
• Improve user experience – make federated access seamless
• Provide tools that help organizations and users benefit from the federation
TAC Strategic Priorities – presented by various members of the TAC
The TAC strategic priorities are:
• Metadata Distribution
• Federated User Experience
• Metadata Administration
• Supporting NET+ Services
• Mobile/Federated Non-browser Applications
These were presented to the Forum in a lightning talk format, outlining the problems faced in each particular priority area, along with the proposed solutions.
Congratulations to Virginia Tech for becoming the first IdP certified for the Bronze and Silver assurance profiles.
• It's new. Only one SP supports it.
• It's difficult to adopt?
• It's new. Software support is nascent.
• IdP POPs don't help SPs
• What about other SP and technology requirements?
The Proposed Solutions
• Engage FICAM on agency adoption
• Work with other trust frameworks
• Roll out simplified Bronze
• Engage community
• Develop custom login handler
• Work with Affiliates
• Replace IdP POP with Bronze
- Assurance is a good “best practice” for your own on-campus applications – a way to get your auditors comfortable with what you are doing
- Auditors are very interested in the assurance information
- It would be helpful to provide boilerplate letters for IdM folks to send to auditors, HR directors, other stakeholders describing the importance of assurance
- “The risk management and security people on our campus want this.”
- “Some on our campus believe this is risky and I don’t understand why. Perhaps we need materials that better explain this to non-IdM people.”
• If you want your service to be accessible globally today, you need to join multiple federations
• The number of national federations is increasingly globally, as are federations that service regional interest or special groups (K-12, libraries, healthcare)
• There is little in the way of deployed tools and standards to help interfederation
The Proposed Solution
• Participate in existing efforts to understand and begin addressing these problems (REFEDS – www.terena.org/activites/refeds/ )
• Organizations adopt recommended federation practices
• Models to build toward to avoid re-inventing the wheel: DNS, BGP, other?
• Gap analysis and use cases among national (and intra-national) federations
- “Where I’m getting pressure is researchers – they work in teams and include people from all over the world. There is also the case of courses that include students from other countries. For the former, the policy bar is much lower because these faculty want their names on the work. For students, when you get grades involved, it gets stickier.
- “At LIGO, we’re not that interested in privacy; we just want to get data we’re sharing back and forth.
• The current method of metadata distribution is brittle and does not scale
• Batch delivery of metadata inhibits scaling and interfederation
The Proposed Solution - Per-entity metadata
• A DNS-like model that queries for an entity's metadata on demand
• More efficient
• Avoids brittleness of a single metadata aggregate
Other Neat New Features
• Per-organization metadata (in conjunction with delegated administration)
• User-defined metadata aggregates based on self-asserted entity attributes
• Support for JSON metadata format in addition to traditional XML
Federation User Experience
• No in-band mechanism for SP to communicate attribute requirements
• IdPs cautious on attribute release
• When SP receives insufficient attributes, user reaches dead-end
The Proposed Solution
• Attribute management automation
• Service categories
• Requested attributes in metadata
• User consent
• Federated error handling
IdP Discovery Solutions
• Deploy a new centralized DS that conforms to current best practices
• The new DS will derive its UI from MDUI elements in JSON metadata
• Support for entity attribute filtering
• Support for alternative discovery profiles
• Support for social IdPs
We have the Research and Scholarship category now. What is next? What categories would be usefule?
- Perhaps something related to student-facing services, which are being outsourced by a lot of campuses. Student life focused (discount-type sites, enrollment verification).
- In addition to adding categories, should also be promoting R&S to campus (and other) service providers
• Site admins don’t keep their metadata up to date
• Federation Manager (FM) application login not federated and overall UI lacking
• Some organizations have too many entities for one or two people to manage
• Too many manual processes
• Access to the FM is based on password alone (which can be phished)
• Delegated administration
• Two-factor for the FM (compliments of Duo Security)
• API for submitting SP metadata
• API for submitting low-risk metadata
• Automate administrative processes
• Mobile-based confirmations, notifications, and metadata submissions
- InCommon needs to do a better job of promoting new features (like MDUI)
- Perhaps schedule monthly/quarterly webinars on techniques for metadata management, and/or other topics.
- There really is no guide to “how to be an InCommon site admin.
- Perhaps a condition of membership should be annual certification or training, or perhaps just put out a series of vidoes
- Perhaps need something targeted at those one level up from the people running the infrastructure
• Large-scale NET+ adoption by the community: services just plug-in and work
• Supporting scale - minimal per-campus technical integration effort
• Use of InCommon and federated identity services: AuthN and attributes
• By and large, federated identity management is new to NET+ providers
• Implementation of federated IdM may be driven only by higher education
• How do we make the case for them to invest in the "little bit" of work we might need?
• Issues that are small for pilot schools might be large for the community in general
• Might vendors converge to fully support the federated model naturally?
• More education/information demonstrating the benefits in vendor terms?
• Assist early adopters when leverage it is at its peak during contract negotiations?
• Support for other technologies?
- Part of our challenge is explaining Net+ to ourselves. Not clear we’re all on the came page re: provisioning/deprovisioning, attribute release. Need normalization around this process in our own community. Most vendors think it is just authentication.
- Identifiers – at this point, if you want federation to work well, don’t want to reassign EPPNs. That identifier conversation is a great thing to get out to people. Why do/do not use this/that identifier
- We had pressure to get Box up and running. Had to use email address as EPPN. Now Box has made some changes and that no longer will be the case. So that’s good.
- The place to ask vendors for changes (and for such things as federation) is at the contract table – not after the fact. IdM people need to be at the contract table to have this conversation.
- TAC needs to lay out a roadmap – here’s where we need to be in 2-3 years. There is also the need for a roadmap as towhere vendors need to be (auto-provisioning/deprovisioning)
- Maybe as part of validation, the TAC and technical people should be formally involved. We should not rely on the community going out and discovering this stuff, rather Net+ should be proactively involving TAC and/or community.
Mobile/Federated Non-Web Applications
- SAML Web Browser Single Sign-On does not satisfy all the federation use cases in our community, such as:
• Research apps outside the browser
• Mobile apps
• Interoperability with social identities
• Encourage IdP operators to enable the SAML ECP (Enhanced Client and Proxy) support in Shibboleth
• Continue work of the Social2SAML Working Group to provide a translation service (non-SAML protocols to SAML assertions.
• Project Moonshot (Janet-led initiative in partnership with GEANT) to extend benefits of federated identity to non-web services.
• Track OAuth’s work toward solving this problem, with an eye toward discussing interoperability and standards at the appropriate time
- Jack Suess mentioned that he met with Microsoft about their Azure IdM system coming out. It has a lot of the non-web capability if you use ADFS. Need to talk with them about how to fit with InCommon. They are assuming everyone will be in the Azure cloud. It would be helpful to have some white papers about how Azure works and the potential benefits and pitfalls.
That ends the priorities discussion
National Strategy for Trusted Identities in Cyberspace (NSTIC)
Internet2/InCommon receives $1.8 million (per year for two years)
- Build a consistent and robust privacy infrastructure through federated identity management
- Help individuals preserve privacy build a scalable privacy infrastructure
- Ken Klingenstein, Principal Investigator
Update: Identity Ecosystem Steering Group Management Council
- Jack Suess – representative for Research, Development, Education & Innovation
Jack Suess commented that the NSTIC grant will provide resources for building out a privacy mechanism inside of InCommon for attribute release.
The ecosystem group will form some working groups.
InCommon Collaboration and Working Groups
• KAF (K-12 and Federation)
• Social2SAML - Paul Caskey has developed a test instance of a Social2SAML gateway that he will make available
• User Identities
• Research Agencies
• State & Regional Federations (with Educause)
- Some other federations already have some of additional features on the roadmap, so perhaps we could piggyback (Australian fed, for instance, has IdP-of-last-resort on a roadmap)
- How do we have input to the direction of the development of Shib (and other federating software)?
- Explanation of overall funding models. Understanding how we/InCommon/Internet2 contribute to projects like Shibboleth, CAS, CIFER, Grouper, etc.
Getting SPs to leverage campus IdPs is still thorny because of attribute release. We should be concerned that scientific research projects might set up their own federations.
- It is a challenge for research projects (outside of university campuses) to join InCommon (things like insurance requirements take some effort to overcome).
- On the SP side, the main problem is getting the attributes. R&S is the right approach.
- It seems that more vendors are using SAML, but not using federation. Are there too many rules? Is it too hard?
- General comment: “I’m not getting any more staff and more and more pressure to move things to the cloud.”