Authentication - Current Limitations and Future Direction

Authentication and authorization goal: Loose coupling between REs, BSP and back-end services

The Bamboo ecosystem is by design a heterogeneous collection of loosely coupled components. In such an environment, user access control (authentication and authorization) are challenging.  There is a tradeoff between user convenience (such as single sign-on) and appropriate control over the release of user information.  In a federated identity environment such as research and higher education it is vital that the institutional identity providers (IdPs) that authenticate their members and assert information about them to online services know the endpoints with which that information is being shared.

If the Research Environments or other clients that authenticate a user were to simply pass along the IdP-provided information about an authenticated user to the Bamboo Services Platform or other remote services and external tools, the IdP would no longer know and be able to express policy about which endpoints were receiving this information.  SAML provides a profile, the Enhanced Client or Proxy (ECP) profile, that allows the institutional IdP to establish direct connections with back end services even if they are behind other Bamboo components. Reliance on ECP is thus the preferred direction for Bamboo authentication and authorization practices.  However, ECP is not widely enough supported as of April 2013 to make this a practical solution for Phase One of the Bamboo Technology Project.

The limitations that required an interim solution be adopted for BTP Phase One

Unfortunately, ECP is not yet widely supported by SAML IdPs.  The IdM team within CIC, a consortium of the Big 10 schools plus the University of Chicago, has made increased support for ECP a goal for its members.  That support is, as of April 2013, still limited to roughly half of those institutions. The primary barrier is that CIOs do not yet see the real drivers for adoption and their IAM staff members tend to be fully committed to supporting existing functionality and its enhancement.  This situation will likely change over time, but not quickly.

The nature of the Phase One interim solution

For phase one, the information that will be passed to back-end tools and services will be limited to identification of the authenticated user's institutional affiliation (i.e. the user's chosen IdP). The limitations of this interim solution are mitigated to some extent by the fact that many of the access policies for Bamboo services and resources will be based on membership in Bamboo groups, and this information is available via Bamboo Group Services, without reliance on the institutional IdP.

(It may be worth noting that a user identifier, unique to the chosen IdP, is derived from the user identifier passed by the IdP, but that this identifier is encrypted with a one-way hash function before it is shared beyond the authenticating Research Environment or other client; that is, the identifier itself is not shared.)

Absent the ability ECP would provide for remote services (including those hosted on the BSP) to verify a user's authentication, remove services must trust the authenticating Research Environment or other client to provide accurate assertions about the user's identity and roles. In the "interim solution," a Research Environment that authenticates a user is able to obtain the user's Bamboo Person Identifier (BPId) via a special-case call to the Person Service hosted on the Bamboo Services Platform, and is expected to assert that identifier in subsequent calls to the BSP. Roles may also be asserted. Details and context are provided in the wiki page Identity and Access Management - Authentication and Authorization.

This trust between the authenticating Research Environment and the Bamboo Services Platform implies close contractual or organizational coupling noted in the next section of this document.

Legal or organizational considerations

Services deployed on the Bamboo Services Platform rely on trusted client applications (e.g., Research Environments) to authenticate users and assert true information about their identities. This is a high level of trust. It implies strong contractual obligations on the part of the client to assert a user's identity honestly, and within an agreed set of definitions about the currency of the user's authentication (e.g., that she authenticated within the client's current user-session; with agreed-upon limits on expiry of that authentication after a period of inactivity).

Practically speaking, this high level of trust implies either strong contractual obligations between independent organizations; or the need for the trusted client to be run by the same organization running the trusting Bamboo Services Platform, so that the established trust can be vetted and obligations enforced within the organization's internal structures for holding system administrators and users to account.