This wiki space contains archival documentation of Project Bamboo, April 2008 - March 2013.

Skip to end of metadata
Go to start of metadata

Bamboo's centrally-hosted services include an IAM (Identity and Access Management) suite, Collection Interoperability Hub, and proxy services to remotely-hosted tools for scholarship. This set of services runs on FUSE ESB, an enterprise distribution of Apache's open-source ServiceMix (acquired in 2012 by RedHat). A number of additional, open-source technologies are required to support these services, including Apache Web Server (httpd), and Grouper.

Information on the centrally-hosted services' architectural overview; a service developer "workbench" environment in which to extend or develop services; sys admin documentation for deployment of additional technologies in support of services; and the services' API are organized in this section of the Bamboo documentation, as follows:

 

Installing and Configuring technology components

Technology Component(s)Documentation Link(s)Notes
Developer toolkitDeveloper Workbench Environment for BSP Service DevelopersJava, Maven, Eclipse and IDE plugins, required filesystem directories, required environment variables
FUSE ESBDeveloper Workbench Environment for BSP Service Developers Core element of Bamboo Services Platform (BSP, the deployment container for centrally-hosted services whose APIs are linked from Service APIs - Centrally-Hosted Bamboo Services)
PostgreSQL databaseDeveloper Workbench Environment for BSP Service Developers Relational database providing persistence for BSP-deployed services
Core BSP-deployed servicesDeveloper Workbench Environment for BSP Service Developers Core services, including those that support IAM
Apache Web Server (httpd)Configure Apache Web Server for Client Authhttpd supports client auth (authenticating trusted client applications), as well as proxy-forwarding over AJP of BSP services
GrouperGrouper Install - Configure - PopulateGrouper provides persistence for the "Application Catalog" (known/trusted client applications in the Bamboo Trust Federation); as well as for user-created and -managed groups
Application Catalog dataMaintaining Application Catalog Data for Trusted ClientsFor an application to be trusted (a key element of gaining permission to invoke services protected by policies that restrict access), Application Catalog data must be maintained.
Trust Federation metadataMaintaining SAML Metadata that establishes a Trust FederationIdentity providers and service providers trusted within the Bamboo Trust Federation must be identified with SAML metadata.
Social/SAML GatewaySocial/SAML Gateway to enable social media identity provisionA Social/SAML gateway must be a part of the Authentication 'machinery' if social media Identity Providers (e.g., Google) are to be used for user logins.
Clients

When policies in effect restrict access to anonymous users or anonymous applications, only "Trusted Applications" can succeed in invoking the affected services. Only "Trusted Applications" can assert the identity of a user to BSP-deployed services (anonymous client apps imply anonymous users).

  •  Clients acting as a "Trusted Application" generally do so by functioning with an authentication context backed by Shibboleth SP (Shibboleth Service Provider). Note install and configure document linked from column at left.
  • In addition, exchange of certificates and metadata are necessary for a client application to act as a "Trusted Application" in the Bamboo Trust Federation (this includes simple web service clients such as Firefox Poster or curl). Note Client Auth document linked from column at left, particularly the Certificate Exchange section of that page..
  • In addition to the installation and configuration documentation linked from the column at left, see the Client responsibilities for implementing the conventions section of the page Conventions for representing Identity Providers in the Bamboo Trust Federation.

 

  • No labels