IAM Sessions at the EDUCAUSE Annual Conference
For those heading to the EDUCAUSE Annual Conference next week in Denver, we've created a web page with a list of the sessions related to identity and access management to help you with your planning. The list includes track sessions and poster sessions, as well as presentations planned in the booths of several InCommon Affiliates. We hope you find this to be a helpful resource.
www.incommon.org/educause.html
Also note that InCommon sessions include:
- a pre-conference seminar on implementing Bronze and Silver (Tues., Nov. 6, 12:30 pm)
- a session on the CommIT Project (a federated identity approach to rethinking the admissions process - includes a demo) (Thurs., Nov. 8, 8 am)
- supporting high-value, high-risk cloud services (through the InCommon Assurance program) (Thurs., Nov. 8, 9:10 am)
- scaling and expanding your federated presence through recommended practices (Thurs., Nov. 8, 5:30 pm)
Scaling the Federation
The federated approach to identity management is generally more usable and significantly more secure than the non-federated approach. On the other hand, federation is more difficult to deploy but perhaps not significantly so, especially if done with care. In any case, federation as a general phenomenon has seen only modest growth at best.
The reasons for the lackluster success of federation are varied and not well understood. Landau and Moore [1] offer a plausible explanation for the failure of federation on the open Internet. They conclude that there is little incentive for RPs to federate, especially since IdPs derive most of the benefit from an RP’s decision to participate in cross-domain federation.
Growth in the InCommon Federation
The number of entities (identity providers and service providers) in the InCommon Federation is apparently growing by leaps and bounds, but breaking this down, the number of service providers (SPs) is growing exponentially while the number of identity providers (IdPs) enjoys only a modest growth rate. Even though the number of SPs is actually underestimated (since some entity descriptors in metadata have literally dozens of distinct endpoints) we claim the number of SPs is not a good indicator of overall Federation growth. To understand the dynamics of the InCommon Federation, one should follow the growth of IdPs over time.
Why is this? Well, more and more organizations are introducing non-federated web applications into metadata (i.e., “non-federating” from a cross-domain point of view). In other words, the Federation Manager is becoming a software-as-a-service application that organizations use to manage their local SAML federation. We conclude from this that the number of SPs in metadata indicates that SAML Web Browser SSO is catching on in a big way, precisely because it does address cross-domain federation in addition to SSO. For most campuses, that translates into numerous (often hundreds of) local SAML deployments.
The upshot is that cross-domain web browser SSO currently enjoys only modest growth. This article exposes perceived barriers to growth and identifies potential solutions that purport to remove those barriers, thereby raising federation to a new level, that is, federation at scale.
The PAP Test
In what follows, we focus on three aspects of federation that figure prominently in an entity’s decision whether or not to federate:
- Penetration
- Assurance
- Privacy
We examine each of these concepts carefully, both in principle and in practice. In other words, we perform a kind of federation PAP test (where “PAP” of course refers to Penetration, Assurance, and Privacy) thus arriving at a health assessment of federation in the large.
Penetration
Penetration is the probability that an arbitrary user is able to provide an acceptable authentication context to the service provider (SP) on demand. Usually this just means that the user possesses a federated identity that the SP will accept in lieu of local authentication (which is basically what federation is all about). A phrase that captures this scenario is “Bring Your Own Identity” (BYOI). The implication of BYOI is that every time the user leverages an existing password, the world becomes just a little bit better place.
For the purposes of discussion, we define the following terms:
- penetration filter threshold: below this threshold, there are perceived barriers to federation
- penetration pump threshold: above this threshold, federation proceeds unhindered
AFAIK there is no available research that suggests what these threshold values might be in practice (but see the theory of Diffusion of Innovations). In any case, there’s absolutely no reason to believe that the filter threshold and the pump threshold are the same. What is more likely is that between these two threshold values, a federation waivers in a kind of “wait and see” mode, with no significant barriers or enhancers.
In the InCommon Federation, we have not yet reached the filter threshold; that is, there are barriers to Federation growth that RPs actually take into account when deciding whether or not to federate.
In contrast, on the open Internet, the pump threshold has already been exceeded. Yet federation still flounders on the open Internet, and we wonder why. Apparently there are other factors at play here, some of which are discussed by Landau and Moore. [1]
Assurance
By definition, federation introduces an untrusted third party, namely, the identity provider (IdP). Thus the service provider (SP) quite naturally wonders about the level of assurance (LoA) associated with the user’s IdP. Assurance requirements will vary from SP to SP of course, but whatever authentication context is required, it must be requested at runtime. Today the SP most likely does not care about LoA, either because the service itself is low risk (e.g., a wiki) or the transaction to be authorized simply does not require a high LoA.
In the InCommon Federation, IdPs are labeled as Bronze or Silver, indicating LoA-1 or LoA-2 (roughly). In principle, this satisfies the Federation’s need for assurance. In practice, however, Bronze and Silver are expensive, for both the IdP and the Federation Operator.
On the open Internet, assurance is still mostly an unsolved problem. There are a handful of FICAM approved IdPs on the open Internet (including Google, PayPal, and VeriSign), but in practice the LoA of an OpenID assertion is neither sought after nor consumed at the RP. Today, LoA on the open Internet is mostly a solution looking for a problem to solve.
Privacy
Privacy functions as a showstopper in nearly every federation in existence today. In the InCommon Federation, privacy concerns at the IdP (fueled by FERPA) lead to conservative attribute release policies whereby an unsolicited SP is initially denied the identity attributes it requires to function. This forces bilateral agreements to become the norm and detracts from the overall user experience.
In response to this unfortunate state of affairs, InCommon has launched the Research and Scholarship (R&S) category of service providers. In principle, an R&S SP is more trustworthy than an arbitrary SP chosen at random, and therefore the IdP is induced to release attributes to R&S SPs “sight unseen.” The mechanism for accomplishing this is attribute-based policy configuration at the IdP. The attributes used for this purpose are called entity attributes, which promise to dramatically reduce the configuration overhead associated with attribute release policy at the IdP.
R&S is a baby step in the right direction. Currently there are eight (8) R&S SPs while more than 30 IdPs have self-asserted their support of R&S. If R&S takes off, it could have a dramatic effect on attribute release (and hence on privacy) in the InCommon Federation.
The effect of service categories on other federations is unknown. In the EU, for example, privacy is so tightly controlled (via legislation), it’s doubtful an R&S-like scenario could take hold. There are, however, rumblings in the EU even as we speak, so only time will tell.
On the open Internet, privacy is the rallying cry for a large group of constituents poised to derail the NSTIC effort. A major challenge to NSTIC is how to embrace privacy with political and technical correctness. A prerequisite (it seems) is that the IdP should have zero knowledge of the service ultimately visited by the user. This appears to be a technical challenge since the lack of this knowledge at the IdP is itself a privacy concern. A practical solution to this apparent contradiction is unknown (to this author, at least). We look to the NSTIC process to propose a solution that solves the privacy problem at both ends of the federated transaction simultaneously.
Stimulating Growth
Clearly there are numerous barriers to successful federation at scale. In what follows, we make some relevant observations for the InCommon Federation only.
If every SAML-enabled SP in the InCommon Federation were also OpenID-enabled (specifically, OpenID 2.0), these SPs could leverage the OpenID IdPs on the open Internet. We claim there is a huge advantage in doing so. Not only would the penetration threshold significantly increase but users would be encouraged to BYOI. For students, parents, and friends of the university in particular, the benefits would be significant.
As mentioned earlier, not all SPs care about LoA. Those that do can deploy mobile-based two-factor authentication (2FA) at the service provider. The technology exists today to do this safely, easily, and at low cost per user. Combined with a “something you know” first factor at the IdP (i.e., a federated password credential), mobile-based 2FA can provide sufficiently strong LoA for the vast majority of high-risk SPs. In effect, the Federation could realize the benefits of Bronze and Silver without a corresponding high cost of deployment.
To OpenID-enable every cross-domain federated SP in the InCommon Federation, and to simultaneously 2FA-enable the high-risk SPs (federated or otherwise), is of course an expensive proposition. To mitigate this cost, a centralized gateway might be deployed (at the Federation level) to realize certain economies of scale. The gateway would, in effect, put the theory to the test. If sufficient benefits accrue (metrics to be determined), the technology would ultimately be pushed to the fringes of the Federation.
This strategy has been successfully deployed before, that is, deploying a centralized service that temporarily gives RPs the benefit of new technology without the corresponding high cost. As the technology proves itself (or not, as the case may be), the natural tendency of federation is to push the technology to the edges.
This brings us to the third and most challenging component of the “PAP” test: privacy. Unfortunately, AFAIK there is no “silver bullet” that addresses the privacy issue. It is critically important that we find such a solution, however.
The reader will have already observed that successful penetration and adequate assurance give rise to “universal, trusted authentication,” whereas privacy crosses squarely into the realm of authorization. Without privacy (or attribute release, depending on which side the coin falls), the overall federation problem is only half solved.
We believe intra-federation has a fighting chance with respect to privacy. In the InCommon Federation, for instance, service categories such as Research and Scholarship, in conjunction with standard SAML flows and generalized policy configuration based on entity attributes, will significantly improve the federated user experience, which in turn will increase the demand for federation.
There’s nothing special about SAML in this hypothetical scenario. An equivalent endgame could be realized using OAuth2 technology. Indeed, there is some very interesting work going on right now that leverages OAuth2 for user consent-based attribute release. The latter appears to be a prerequisite for inter-federation in particular since EU federations (for instance) require user consent for all intents and purposes.
Federation has many moving parts, with only partially understood dynamics. Periodic game changers are expected and invited. At this point in time, it seems the InCommon Federation might benefit from the following innovations:
- a centralized gateway that bridges the open Internet and provides ubiquitous strong authentication to SPs that need it
- usable service categories and attribute-based policy configurations at the IdP
- an improved user experience by virtue of all of the above and related efforts such as enhanced discovery and federated error handling
- a simplified user consent mechanism
Are we there yet? No, not quite.
References
[1] Susan Landau and Tyler Moore. Economic tussles in federated identity management. http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/4254/3340
InCommon Online Forum: Goals and Priorities of the InCommon Technical Advisory Committee
Thursday, November 1, 2012
2 pm EDT / 1 pm CDT / Noon MDT / 11 am PDT
----------
What does InCommon have planned for the next year, in terms of services and infrastructure? For the next three years? What changes might be coming to make things easier to federate? Are there barriers that need to be reduced to make your life easier? The InCommon TAC (Technical Advisory Committee) will address some of those issues – and ask for your input – during this online forum.
Join us Thursday, Nov. 1, at 2 pm ET as the TAC seeks community input on its goals and priorities. If you’d like a sneak preview, you can see the slides and notes from a recent session at the Internet2 Fall Member Meeting (https://spaces.at.internet2.edu/x/-wo).
----------
Host and Moderator:
Renee Shuey (Penn State), Co-Chair, InCommon TAC
Speakers:
Paul Caskey (University of Texas System), member, InCommon TAC
Michael Gettes (Carnegie Mellon), member, InCommon TAC
----------
CONNECTING
We will use Adobe Connect for slide sharing, audio, and questions (via chat). A phone bridge is available, as well, for audio and to participate in the discussion during parts of the meeting. Those who join the audio bridge will be on mute, but we plan to unmute everyone during parts of the session to allow for questions and comments.
Adobe Connect (slide sharing, chat, and audio): http://internet2.adobeconnect.com/incform
Phone bridge:
Dial-in numbers:
734-615-7474 or
866-411-0013 (toll-free in US and Canada)
Access code: 0101010#
----------
About the InCommon Online Forum
The InCommon Online Forum is a series of webinars that provide opportunities for presentations with the Steering Committee, the Technical Advisory Committee, collaboration groups, and topics of general interest to the community.
InCommon Certificate Service Welcomes 200th University
Ann Arbor, Mich. – October 17, 2012 – Internet2 today announced a new milestone, as the University of Maine System has become the 200th subscriber to the InCommon Certificate Service.
Internet2’s InCommon Certificate Service opened for business in mid-2010 with a unique proposition: higher education institutions can acquire unlimited numbers of certificates, which are necessary for trusted interactions between web servers and browsers, among other uses, for one fixed annual fee. The program includes all domains owned or controlled by the campus, including .edu, .com., .net, and all others.
“This program changed the playing field for higher education,” said Shelton Waggener, senior vice president of Internet2. “I know from my experience as chief information officer at the University of California Berkeley, the program paid for itself in less than a year. Campuses not only benefit from the ability to order unlimited numbers of certificates, but also in many cases can eliminate internal billing processes while dramatically increasing the use of these important tools. Everybody wins.”
The Certificate Service is one of the trust services offered by InCommon for the education and research communities, and their sponsored corporate partners and is part of the Internet2 NET+ portfolio that makes available services designed and delivered for the higher education community. InCommon also operates the identity management federation for U.S. research and education, and offers multifactor authentication solutions. The Certificate Service is available to higher education InCommon participants, with additional discounts for Internet2 members. For more information see cert.incommon.org.
About Internet2 and InCommon
Internet2 is a member-owned advanced technology community founded by the nation's leading higher education institutions in 1996. Internet2 provides a collaborative environment for U.S. research and education organizations to solve common technology challenges, and to develop innovative solutions in support of their educational, research, and community service missions. For more information, visit www.internet2.edu.
InCommon, operated by Internet2, serves the U.S. education and research communities, supporting a common framework of trust services, including the U.S. identity management trust federation for research and education, a community-driven Certificate Service, a multifactor authentication program, and an Assurance Program, offering higher levels of identity assurance. The InCommon Federation enables scalable, trusted collaborations among its community of participants. InCommon has more than 450 participants serving 6 million faculty, students, and staff at higher education institutions and research organizations, as well as their sponsored partners. For more information, see www.incommon.org.
Virginia Tech First To Reach Certified Online Trust Standards
Virginia Tech is the first university in the country to become a certified provider of greater assurance to online resource providers — federal agencies, universities, nonprofit organizations, and private companies alike — of the identity of those seeking access to financial and other sensitive information.
The university has qualified for Internet2’s InCommon Bronze and Silver Identity Assurance program. Internet2, a nonprofit higher education consortium, administers the certification program as part of its mission to provide secure and privacy-preserving trust services for its participants. Internet2 operates the InCommon identity federation, which allows individuals to use one user ID and password (also called credentials) to access protected online resources — both internal and external to their home institution.
Internet2’s InCommon Assurance Program allows campuses to certify that, for those using more-sensitive services, there is a stronger process for issuing credentials and granting access. There are two levels of this process — called Bronze and Silver. Bronze, comparable to the National Institute of Standards and Technology Assurance 1 level, has security that slightly exceeds the confidence associated with a common Internet identity. Silver, comparable to NIST’s level of Assurance 2, has security appropriate for financial transactions. Resources likely to become among the first to require Silver include those providing online grant administration or financial aid administration.
“Meeting the standards of the InCommon Identity Assurance program enhances security by helping to ensure that access to a resource is granted to, and only to, the intended individual,” said Mary Dunker, director of Secure Information Technology Initiatives at Virginia Tech. “In addition to enabling authorized Virginia Tech users to access applications that require InCommon Silver credentials, achieving this certification further strengthened the university’s identity management processes and technology infrastructure. Now we have a greater trust in the identities of those individuals who use InCommon Silver and Bronze credentials for internal university applications.”
“I applaud Virginia Tech for their pioneering effort,” said Jack Suess, chair of the InCommon Steering Committee and vice president and chief information officer at the University of Maryland Baltimore County. “They have not only become the first to meet these more-stringent standards, but have also helped us to refine the certification process. Given that some federal agencies plan to require InCommon Silver for certain applications, this will become more and more important for research universities and organizations.”
About Internet2 and InCommon
Internet2 is a member-owned advanced technology community founded by the nation's leading higher education institutions in 1996. Internet2 provides a collaborative environment for U.S. research and education organizations to solve common technology challenges, and to develop innovative solutions in support of their educational, research, and community service missions. For more information, visit www.internet2.edu.
InCommon, operated by Internet2, serves the U.S. education and research communities, supporting a common framework of trust services, including the U.S. identity management trust federation for research and education, a community-driven Certificate Service, and a multifactor authentication program. The InCommon Federation enables scalable, trusted collaborations among its community of participants. The Certificate Service offers unlimited certificates to the U.S. higher education community for one fixed annual fee. InCommon has more than 450 participants serving 6 million faculty, students, and staff at higher education institutions and research organizations, as well as their sponsored partners. For more information, see www.incommon.org.
For media assistance, contact woodbeck@internet2.edu or 734-352-7007.
With 99 people registered for 2012 Advance CAMP, there is a lot of excitement around this event, being held in Philadelphia, Oct. 4-5.
The overarching goal is about setting the direction for the community on what's next for identity in higher education.
According to Tom Barton, Advance CAMP program committee chair, "We are excited about the group of architects, developers and deployers who are participating in the 2012 Advance CAMP. The unconference format used at ACAMP allows participants to set the agenda at the start of the meeting, which means we can address the most current and most pressing issues."
Here are just a few of the topics getting a lot of buzz just prior to Advance CAMP: enterprise-cloud integration, identity issues around Net+ services, identity services for mobile applications, identity services for research and virtual organizations, and the CIFER project (http://www.ciferproject.org/).
Advance CAMP is sponsored by the InCommon Federation in cooperation with Internet2. Additional sponsors include the Internet Society, the Kuali Foundation and Unicon.
For more information, see https://spaces.at.internet2.edu/display/ACAMP2012/Home