Logging Into Bamboo - Authentication Use Cases

Created by SM
Last updated: Apr 18, 2013 by Former user (Deleted)Version comment
7 min read

Introduction

As I mentioned in a prior post, UW-Madison and UC-Berkeley IAM Collaboration, a group of Project Bamboo technical staff got together in late August to frame Identity and Access Management function and infrastructure for the Project Bamboo Ecosystem. By "Project Bamboo Ecosystem" we mean, in the near-term, the constellation of services and applications that will make up the Phase One deliverables of the Bamboo Technology Project. Notes, whiteboard photos, and an evolving set of diagrams make up the artifacts of the face-to-face meeting in Madison, and are available on this wiki page: Madison IAM F2F - August 2011 - Notes.

For a broad overview of how IAM will work in the Ecosystem we're building out in BTP Phase One, you might want to review a blog post of 20 June 2011, Identity and Access Management in the Bamboo Ecosystem. As I mention below, in the More to follow section, in the future I will circle back through this post's topics in a somewhat less general and less technical mode. The Implications section of this post will probably be the most helpful for less-technical readers.

In this post, I'll describe the five authentication use cases (scenarios) that we discussed at the Madison face-to-face, and which we intend to support with infrastructure built and deployed in Phase One. I will also discuss some implications of our choice to support these use cases as we have defined them; these are likely to be of interest to BTP teams and other technically-inclined observers.

Stated succinctly, the five authentication use cases are these:

  • (1) Unauthenticated User makes request through Registered App
  • (2) Unauthenticated User makes request through Unregistered App
  • (3) Authenticated User makes request through Registered App
  • (4) Authenticated User makes request through Unregistered App
  • (5) Authenticated User makes request directly to a BSP-hosted service

Definitions and Assumptions

These statements call for a few definitions:

Authenticated - By "authenticated" we mean a user who has proven her identity to an Identity Provider (IdP) that is part of a "Bamboo Trust Federation" – a set of IdP's that has been vetted and is considered trustworthy to vouch for the identities of a group of users. For example, the CalNet IdP run by the UC Berkeley campus will be trusted to vouch for the identities of Berkeley faculty, students, and staff; whereas a Social Media IdP like Google will be trusted to vouch for the identity of otherwise-unverified people who have established a Google account by completing an on-line process.

Registered App - A Registered Application is one that is known to Project Bamboo, whose operator(s) have entered into a contractual arrangement regarding permitted usage and access to resources in the ecosystem, and whose identity can be verified via standard mechanisms such as exchange of public keys and signed metadata.

Request - A request in these use case statements is a request in the HTTP sense: a web browser or other HTTP client makes a request for some resource, and in turn receives a response. A simple example: a request for the web page defined by the URL https://wiki.projectbamboo.org/display/BTECH/Technology+Wiki+-+Home yields the home page of the Confluence wiki space where this blog post is published.

Some important assumptions are made about these simple-seeming use cases:

  1. Authentication may only be performed for users who access the Project Bamboo Ecosystem via a Registered application. Unregistered applications (including individual web browsers) are not allowed to participate in the Bamboo Trust Federation that underlies all Authentication in the ecosystem.
  2. Authentication is described in the vocabulary of SAML assertions. Applications and other components built by Project Bamboo will run Shibboleth Service Provider (SP) instances to effect this requirement.

There are a number of technology components that participate in Authentication and Authorization. The diagrams included below, which illustrate the five use cases, include references to components that participate in both Authentication and Authorization. The latter will be the topic of a future blog post, but because these components appear in the diagrams I'll define them here:

  • The term "RHS" means a Resource Hosting Server which hosts a RESTFul service
  • The term "IDP" means an Identity Provider that authenticates a user and returns a SAML assertion
  • The term "SP" means an Service Provider that speaks SAML and maintains a security context for an authenticated user
  • The term "BPR" means the datastore containing the Bamboo Person Registry
  • The term "GRPM" means the Group, Role, and Privilege management tool
  • The term "BSP" means the singleton (in Phase I) production platform which is composed of: the RHS; an SP; the BPR; the GRPM
  • The term "SRA" means the self-registration application that allows a user to enter data about themselves
  • A "PPPG" service is one of Person, Profile, Contact, Policy, and Group services which provide an API for use in AuthN and AuthZ use cases

Illustrating AuthN Use Cases

Here are diagrams that illustrate the five use cases enumerated above (click to enlarge):

(1) Unauthenticated User makes request through Registered App; & (2) Unauthenticated User makes request through Unregistered App

In each of these use cases, no privileges (permissions / authorization) may be granted on the basis of a user's identity. The user is, effectively, anonymous. Privileges may only be elevated beyond "anonymous access" to the degree that a registered (known and trusted) application is granted elevated privileges.

(3) Authenticated User makes request through Registered App

A trusted SAML SP endpoint must be available to an application in order to authenticate a user to the Project Bamboo Ecosystem. SAML SP endpoints are only trusted if they are implemented by registered applications.

(4) Authenticated User makes request through Unregistered App

Because only registered applications are trusted to authenticate users to the Project Bamboo Ecosystem, users of unregistered apps are always treated as unauthenticated and anonymous – even if the end-user has authenticated within the unregistered application's local context.

(5) Authenticated User makes request directly to a BSP-hosted service

It is possible for users to authenticate directly to the BSP (which runs an instance of Shib SP, and may be considered a "registered application" within the framework of the definitions that undergird these use cases). Based on defined policies, the BSP may then expose protected URLs to such directly-authenticated users.

Implications

Application requirements: to become a "registered application"

The owner of a registered application must successfully complete a business process in which the operator of the application agrees to comply with a set of responsibilities (to be defined) regarding user authentication and authorization, as well as other requirements regarding data access, data publication, and request throughput / bandwidth.

A registered application need not be capable of authenticating users to the Project Bamboo Ecosystem; this is Use Case #1, above.

Application requirements: to authenticate users

Repeating from Use Case #3, above: A trusted SAML SP endpoint must be available to an application in order to authenticate a user to the Project Bamboo Ecosystem. SAML SP endpoints are only trusted if they are implemented by registered applications.

A registered application may be capable of authenticating users but may choose not to, or may choose to anonymize users. Anonymizing users may involve asserting attributes such as institutional affiliation stripped of personally-identifying information (PII); this is a use case frequently seen in library applications.

Calling services directly from an HTTP client

An HTTP client may be a web browser, curl, wget, or a web browser plugin such as Poster.

Cf. Use Case #5, above. In these, as in any use cases, policies may limit access to protected resources. Some resources may be accessible only if they are requested via a registered application. This is a policy choice/limit; the technology infrastructure will enable declaration and enforcement of policies of these types, but does not presuppose that particular policies must be defined.

More to follow...

Whereas the post Identity and Access Management in the Bamboo Ecosystem, of 20 June 2011, was a very general overview, this one contains quite a few acronyms and abstractions. In a future post, I'll circle back through the topics raised here with a more narrow and concrete focus on the clients (Work Spaces) and services (Collections Interoperability connectors and scholar-focused analytic services) that are in-scope for BTP Phase One. The diagram(s) in that post will have more familiar-looking labels to those engaged in areas of work beyond the core IAM implementation, and these will speak more clearly to team members who are less technically-focused.

Also, I'm going to cover at least two other related items in future posts. Reserving the option to tweak the post titles, they'll include:

  • Asking for Permission - Authorization in the Project Bamboo Ecosystem
  • The Project Bamboo Trust Federation - What it is and Why it's needed