The Project Bamboo Trust Federation

The Project Bamboo Trust Federation: Defined

What do we mean when we talk about The Project Bamboo Trust Federation?

Most simply, we mean:

• a set of installed applications or other technologies – such as Work Space and Bamboo Service Platform instances – that are registered such that
• a set of institutional Identity Providers (IdP's) can be used to effect user Authentication (AuthN); where,
• at the time of authentication the institution transmits information (user attributes) that are used to authorize access to services and content.

The Project Bamboo Trust Federation, then, is a group of institutions and applications that agree to provide authorized access to services in exchange for relevant user information – some of which is "Personally Identifiable Information" (PII), and therefore of a type that may not be publicly available, in compliance with institutional policy and/or applicable laws. These agreements are initially effected by negotiation between individuals, and are implemented in a technology ecosystem by the exchange between parties of certain metadata that enables applications and Identify Providers to conduct trusted interactions during a user's login process.

Our purpose in exchanging information between applications and institutions is to identify a user who wishes to access Project Bamboo services and the content to which those services provide access. In some cases, knowing the identity of the user isn't enough to gain access to services or content. For example, where content is restricted to those with access to institutional subscriptions, content may only be available to certain affiliates of an institution (e.g., library patrons of a university). In these cases, successful authentication must be coupled with transfer of information that asserts the user's current institutional affiliation. Evaluating and enforcing policy that governs access to services or content is known as Authorization (AuthZ).

I discussed Authentication in a blog post of 8 September, Logging Into Bamboo - Authentication Use Cases. I covered some key elements of Authorization on 16 September, in Asking for Permission - Authorization in the Project Bamboo Ecosystem.

Who can join the Federation, and why would they want to?

In the near term, Bamboo Technology Project (BTP) partner institutions and affiliates are welcome to join the Project Bamboo Trust Federation. In fact, those institutions are strongly urged to do so. One purpose of this post is to explain the whats, whys, and wherefores in order to set that process in motion among the BTP partners and affiliates.

As mentioned above, membership in the Project Bamboo Trust Federation will be required to gain access to services and content that are restricted on the basis of institutional affiliation. Content to which Project Bamboo mediates access via the Collection Interoperability Hub (CI Hub) and its adapters will, in some cases, be restricted in this way. For example, content from Hathi Trust and from the TCP will almost certainly require that institutional affiliation be proven in the current login session before Project Bamboo can mediate access on a user's behalf.

Thus, any BTP Partner whose members will want to obtain the fullest possible access to services and content hosted and mediated by Project Bamboo will want to join the project's trust federation.

Membership in the Project Bamboo Trust Federation will not be required to log into Work Spaces or to use some of the services hosted by the Bamboo Services Platform (BSP). Users may also log in via IdP's run by Social Media companies, such as Google. Social Media companies like Google offer accounts anyone may obtain. However, they do not prove any institutional affiliation, and so cannot be used as a proof of such affiliation when it comes to complying with Authorization policy in the Project Bamboo ecosystem. Permissions granted to a user who has logged in via Google are therefore likely to be more restricted than those granted to a user who has logged in via the IdP run by a Bamboo Partner or Affiliate institution.

It's worth mentioning here that there is no extant Federation of Trust that includes all BTP partners and affiliates, nor one that establishes trust between service providers and both Social Media and institutional IdPs. That is, there is no convenient 'super organization' – like InCommon, which is a trust federation to which many U.S. higher ed institutions belong – of which the Project Bamboo Trust Federation is a natural subset.

What are the technical and policy requirements for joining the Federation? What if an institution can't meet them?

For an institutional Identity Provider (IdP) to participate in the Project Bamboo Trust Federation, the institution must run an IdP that fully implements the SAML 2.0 specification. (Shibboleth 2 is the likely candidate for most Higher Ed institutions). The institution in question must permit participation in the Project Bamboo Trust Federation – a question of policy, which will be particular to each institution.

The mechanics of participation in the Federation involves:

1. An exchange of metadata exemplified by the nascent trust document at http://trust.projectbamboo.org/metadata/ProjectBambooSaml2Metadata.xml. (This document is also under version control at a location likely to change.)
2. Configuration that governs how the institutional IdP will present information about users ("identity attributes") to the Project Bamboo ecosystem. For Shibboleth installations, the mechanism and process for this configuration is documented on Shib's IdPMetadataProvider page.

As suggested above, institutions unable to meet these requirements may direct users to use one of several Social Media IdPs (TBD) to authenticate to the Bamboo Ecosystem. This capability is on-track for implementation in Q1 2012.

What "identity attributes" will Bamboo require of institutional identity providers?

Identity attributes are information about a user. From the InCommon Federation Attribute Overview: These attributes might include a unique identifier (traditionally a "user ID") or other information such as organizational affiliation, status, email address, etc. (this information is also called "claims" in some products).  In many scenarios identity attributes are very useful to Service Providers for access control, personalization, and other purposes.

We are confident at this point that for Phase One, the attributes requested by Project Bamboo from an institutional identify provider will be limited to the eight attributes described on the InCommon Federation Attribute Summary page. We may request only a sub-set of these. Determining which prove necessary will depend on the access policies we need to enforce in Phase One. We are much more concerned with attributes for access control than for personalization; users in the Project Bamboo ecosystem will be invited to provide personalizing or identifying information (name, e-mail address, etc.) in the course of establishing an account, and may choose provide the identifying information they wish.

The configuration step mentioned above, in which the institutional IdP determines how identity attributes will be presented to Project Bamboo, involves configuration of an "attribute resolver." This resolver normalizes the diverse attribute values used by different institutions to a set that Project Bamboo will use as its standard. The attribute values we'll use as our standard will come from InCommon. For example, different universities may use widely differing data elements to convey the user's right to utilize campus libraries. Institutions will be asked to configure their IdP's attribute resolver (or equivalent mechanism) to convert from whatever value they use – "LIBRARY_OK" or "LIBRARY_USER" or any other string – to the common-lib-terms value defined by InCommon as urn:mace:dir:entitlement:common-lib-terms.

Should there arise cases in which an institution declines to release identity attributes needed by Project Bamboo to determine compliance with an access policy, users who log in through that institution's IdP may be restricted from some services and content to which they would have access if the institution released the identity attributes in question.

What's the process for joining the Federation, and when can institutions sign-up?

Each institution should designate a contact person to handle or mediate any necessary internal policy processes that must be completed; and then to exchange the necessary metadata and configure resolution of attributes, as briefly described above. This contact person should be in touch with the author of this blog post, Steve Masover, with any questions and to initiate the process of joining the Bamboo Trust Federation.

Institutions may begin this process as soon as they wish. However, it's important to understand that 'earlier adopters' are likely to need to engage in extra rounds of metadata exchange and attribute resolver configuration. This is because (a) earlier adopting institutions are likely to want to permit authentication to a dev or test instance of their IdP, requiring further metadata exchange and local configuration when Project Bamboo is permitted to authenticate users on the institution's production IdP; and, (b) the exact set of attributes that Project Bamboo will request from institutional IdPs and how institutional identity attributes ought to be mapped to attributes shared with Project Bamboo are not yet settled.

The benefit of joining the federation earlier is a chance to work out kinks in the process well in advance of opportunities to test-drive offerings for which institutional affiliation is required. QA instances of BTP service providers – work spaces and the BSP – will not be available until Q1 2012, so there's no rush, per se. However, users can already authenticate to the integration layer BSP using remote IdPs such as UC Berkeley's test instance of Shibboleth. The sole resource that currently requires authentication is a simple web page, but authenticated access proves integration of an institutional IdP with the ecosystem infrastructure. UW Madison's IdP will soon be integrated as well.

Meaningful ability to access services and content restricted based on a user's authentication will emerge in the Q1 2012 time frame.