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.


The Problem

          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.”





The Problem

          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 – )

          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.



Metadata Distribution


The Problem

          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


Attribute management

The Problem

          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



Metadata Admin


The Problems

          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)


The Solutions

          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



Supporting Net+


The Goal

          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

The Problem

          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


Potential Solutions

          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


The Problem:

  • 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


The Solution:

          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



InCommon Updates



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)




Community Topics/Comments

  • 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.”