Asking for Permission - Authorization in the Project Bamboo Ecosystem

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

Introduction

Continuing in the vein of my last blog post, Logging Into Bamboo - Authentication Use Cases, today I'm going to talk about the other major element of IAM: Authorization, or AuthZ as it's often called. This too was a topic of much discussion during the F2F at Madison last month (see notes), and further discussion since.

While Authentication (AuthN) is the business of assuring that a user of some software is properly identified, Authorization (AuthZ) is about determining what that user is permitted to do with the software.

AuthN gives us confidence that the user is indeed Professor Lee; AuthZ informs the system what Professor Lee is permitted to do (or not).

In this post I'll describe the core elements of Authorization, then describe how these elements interact with users and services in the Project Bamboo Ecosystem, using the use case that is most centrally in-mind to the BTP teams: fulfilling a scholar/user request to obtain digital content through the Collections Interoperability Hub (CI Hub). The CI Hub was a topic of a blog post in July by Jonathan Smith, The Collections Interoperability Hub.

In the future I will circle back through this post's topics in a somewhat less general and less technical mode.

Definitions and Assumptions

In a sentence, AuthZ can be described in terms of policies (rules) that must be retrieved, then decided on the basis of some variables (e.g., who is asking to do what), and then the policy decision must be enforced. In earlier discussions (documented in the depths of this wiki) we settled on the XACML model for discussing the components of Authorization.

We are currently using the following terms to describe components of the AuthZ 'machinery':

  • RR: Rules Repository – the store of policies or rules that pertain in the system
  • RM: Request Manager (or Request Context Manager) – a service that assembles and serves request-context attributes, such as the Subject (often a user) who is making a request
  • PDP: Policy Decision Point – a service that assembles the needed information to evaluate a policy with respect to a concrete request for which authorization is required, evaluates the policy, and boils the answer down to ALLOW or DENY (plus, optionally, some additional obligations)
  • PEP: Policy Enforcement Point – an element of the system that assures that the authorization decision determines whether or not (and, optionally, how) the system responds to the concrete request for which policy was decided

A discussion of XACML on Wikipedia that describes some of these elements (PDP and PEP). Because we are following the XACML 2.0 specification, we are using the term "Rules Repository" to refer to a store of policies or rules; the XACML 2.0 specification does not name a component to realize this role in an AuthZ implementation.

A "PIP" is also a component of XACML-compliant AuthZ machinery. A PIP (Policy Information Point) is "[t]he system entity that acts as a source of attribute values" (line 274 of the spec). For simplicity's sake at this point in our design process, the function of the PIP is represented as an aspect of Request Manager functionality.

Keith Hazelton recently updated the wiki page P-Gear-P to describe these elements in diagrams which may also help orient interested readers. These diagrams are drawn from the XACML 2.0 specification, and show one way to map the XACML model to the Bamboo Services Platform (BSP). (It's worth noting, in the context of assumptions described on the bottom of that page, that in BTP Phase One all authorization decisions will be performed by BSP-hosted services. This means that user attributes obtained from an IdP, such as a campus instance of Shibboleth, need not and will not be passed to a backing service. In the near term, this saves Project Bamboo an investment in much more complex legal arrangements involving institutional custodians of users' personally-identifying information.)

Authorization in a Project Bamboo Ecosystem use case

We chose a use case to discuss at the Madison F2F that represented the most complex AuthZ requirements expected to require support in BTP Phase One. This use case involves a scholar/user request to obtain digital content through the Collections Interoperability Hub (CI Hub). The CI Hub mediates access to multiple remote repositories on behalf of users of the Project Bamboo Ecosystem; digital content served by some of these remote repositories is expected to be restricted to users who meet some policy requirement, e.g., "must have library privileges at one of a defined list of Higher Ed institutions."

In the currently evolving implementation of the CI Hub, a user requests content by creating a Zotero bookmark file containing links (URLs) that identify the desired content, and submitting the bookmark file to the CI Hub. The Hub is responsible for querying a PDP (Policy Decision Point) service to determine whether the user submitting the bookmarks meets the requirements set by policies that govern restricted content referenced in the bookmark file, assuming the CI Hub is capable of serving content from the referenced repository in the first place.

The CI Hub is an example of a target-service for which policy requires that authorization be granted as a precondition of use. Other services that require authorization may be substituted in its place in this discussion.

The steps and components involved in this workflow are diagrammed in a sequence diagram below. The steps are numbered, and are not repeated in the body of this post because they are more efficiently represented in the diagram.

click to enlarge image; or cf. full-size sequence diagram

Of particular note in the diagram:

  • The CI Tool is the software used by someone to access the services provided by the CI Hub. In BTP Phase One, the CI Tool might be a repository browser implemented in a Work Space.
  • The PEP AuthZ component is a Policy Enforcement Point that assures the initiator of the request is allowed to access the CI Hub before passing the request through. This Authorization component governs access at a service level and has no knowledge of structure or content of the target-service's input parameters or input payload.
  • The CI Hub is an example of a service that requires authorization at a finer-grained level than can be provided by the PEP AuthZ.
    • For this reason, the CI Hub service acts as a PEP (Policy Enforcement Point) itself, making as many calls to the PDP (Policy Decision Point) as are necessary to obtain the authorization(s) it needs to fulfill a user's request.
      • The CI Hub is responsible for "unpacking" the Zotero bookmark file in this use case, inspecting it, and calling the PDP to determine whether the requesting user is permitted to access content from the repositories identified in bookmark URLs.
      • The CI Hub only checks policy for those URLs that it can act upon -- that is, those URLs that request content from a repository for which the CI Hub is capable of mediating access.
    • These multiple calls from the CI Hub to the PDP are represented inside the loop box in the sequence diagram
    • Not all services will require fine-grained authorization. Only services that do have this need will need to be responsible for implementing calls to the PDP and enforcing decisions to ALLOW or DENY access, as returned by the PDP.

About Authorization Decisions

The PDP returns decisions that are boiled down to one of three possibilities: DENY, ALLOW, or ALLOW WITH OBLIGATIONS.

"Obligations" are operations that the PEP (enforcing service) should perform when enforcing an authorization decision. For example, a service might be obligated to send a notification message whenever a resource is accessed.

See the XACML 2.0 spec for more on obligations.

Implementation plans

In BTP Phase One, we will implement the Rules Repository as a simple 'stub,' without programmatic access for managing (adding, updating, deleting) rules / policies. Because the set of initial policies that will need to be enforced is small, this will not be hard to manage, and will leave open the opportunity to select an appropriately generalizable "policy engine" in BTP Phase Two.

Work on the Authorization components of IAM for the Project Bamboo Ecosystem is described, along with target deliverable dates, on the Ecosystem Security Work Plan page on this wiki.

Implications for Service Implementers

Any authorization scheme imposes requirements on those running the services: someone has to define what's permitted and what is not.

For Project Bamboo, policies governing usage will be defined not only by those running the Bamboo Services Platform, but those whose services are deployed on it. Because a significant fraction of services running on the Bamboo Services Platform will proxy functionality served elsewhere – e.g., offering content from remote repositories such as the Hathi Trust, TCP, Perseus, et al. – any authorization restrictions required by the backing-service providers may also require enforcement on the platform (e.g., before a service call is made to a backing-service provider).

Those building services for deployment on the Bamboo Services Platform should therefore expect that:

  1. Service providers will need to decide whether any policies (restrictions) ought to be enforced on usage of provided services, whether the policies are "yours" or those imposed by backing-service providers on which your services rely.
  2. Service providers will need to express those policies in a manner usable by the Project Bamboo Ecosystem's common authorization framework. Details will be forthcoming as soon as they are settled.
  3. In order to assure that policies are being enforced properly, Service providers will need will need to define tests that prove that the authorization framework is working as expected and required. Again, details will be forthcoming as soon as they are settled.
  4. Service providers that require fine-grained authorization decisions will need to implement calls to the platform's PDP (Policy Decision Point) service, and appropriate enforcement mechanisms that respond to that service's determination of permissions. An API for this service is on our Ecosystem Security Work Plan.