Page Tree:

Child pages
  • Account Services UI - Bamboo IAM Client - Drupal Module PoC

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

Skip to end of metadata
Go to start of metadata

Version Control

The Drupal module code is versioned in Project Bamboo's svn instance at Sourceforge, at 

The Drupal Code

Two Drupal modules can be found in the repository:


This is a convenience module for development purposes.  It was useful for developing bamboo_as.module on a local AMP stack where Shibboleth was not installed.  See the in this module for more info.


This module was intended to be installed on a centrally-deployed site through which users of multiple clients would maintain their Bamboo identities. This site was instantiated during the period of the Bamboo Technology Project at (no longer maintained).

Development of this module was halted when funding for a second phase of Project Bamboo software development was not forthcoming.

This module aimed to implement the functionality described on the page Account Services Drupal module workflow.

A demonstration (including webcast) described in a blog entry of November 2012, User-onboarding: creating a Bamboo Identity, shows how far we got with this module. Watch the video here to understand how the module works from a user perspective (with an unfinished user interface), and vis-a-vis user attributes passed into the Drupal environment by the authentication process, managed by the Shibboleth SP Drupal module shib_auth.

REST examples in bamboo_as.module

Some examples of the REST calls made in this module may be useful to developers of future clients to Bamboo's IAM services:

Use Case: Does the User have a Bamboo Person ID? (GET)

The shib_auth module installed in the Drupal instance permits Drupal to act as a Shibboleth Service Provider. When a user logs in via Shib the shib_auth module populates some PHP $_SERVER variables. The first thing we do is throw an error if the expected variables don't exist:

    if (!isset($_SERVER['persistent-id']) || !isset($_SERVER['Shib-Identity-Provider'])) {
      drupal_set_message('Required variables are not present. Please ensure that both shib_auth and all the identity providers are configured corretly.', 'error');

Create a sha256 hash of the persistent-id (an expected / required practice for passing user identities between clients and the Bamboo Person service)

$userid = hash('sha256', $_SERVER['persistent-id']); 

REST Call: Attempt to GET the bamboo person id from BSP:

$endpoint = "persons/sourcedid/?idpid=" . $_SERVER['Shib-Identity-Provider'] . "&userid=$userid";
$url = BSP_ROOT . $endpoint;
$headers = bamboo_as_get_headers();
$personRest = new REST_client($url);
$result = $personRest->doRequest($url, 'GET', null, null, null, $headers);

The REST_client class can be found in

Use Case: Create a Bamboo Person ID if this is a new user (POST)

The approach taken here is to create a variable containing an XML template

define('XMLDECLARATION', '<?xml version="1.0" encoding="UTF-8" standalone="yes"?>' . "\n");
  $xml .=<<<XML
  <person:bambooPerson xmlns:person="" xmlns:xs="">

convert it to an object using PHP's SimpleXML library

  $sx_sourcedId = simplexml_load_string($xml);
  $ns = $sx_sourcedId->getDocNamespaces(TRUE);

populate the object with required values, identifying the IdP used to authenticate and the authenticated user, provided via the shib_auth module on successful authentication (note that the combination of user identifier and IdP identifier were called a "sourced Id" by the team that implemented the Bamboo IAM infrastructure):

  $sx_sourcedId->children($ns['person'])->sourcedId[0]->sourcedIdKey->idPId = $_SESSION['shib_idp'];
  $sx_sourcedId->children($ns['person'])->sourcedId[0]->sourcedIdKey->userId = $_SESSION['userid'];

After prepending the xml declaration, it's removed:

  $xml_prepared = trim(preg_replace('/<\?xml[^>]+>/', '', $sx_sourcedId->asXML()));
As of the time this documentation was written, some months after completion of the code, the reason for including then removing the XML declaration was not clearly recalled. The assumption is that SimpleXML requires the declaration to load the string, but that declaration should not be present when the POST is made to backing services hosted by the BSP. Caveat lector.

POST the request to BSP

  $url = BSP_ROOT . "persons";
  $headers = bamboo_as_get_headers();
  $personRest = new REST_client($url);
  $result = $personRest->doRequest($url, 'POST', $xml_prepared, 'text/xml', null, $headers);

Use Case: List Profiles (GET)

(This code needs more work, which was precluded when the project came to a close.)

A bamboo person id can be associated with multiple profiles.

Look up profile(s) for a bamboo id:

    $url = BSP_ROOT . "persons/" . $_SESSION['bpid'] . "/profiles";

    //list profiles for bpid

    $headers = bamboo_as_get_headers();
    $personRest = new REST_client($url);
    $result = $personRest->doRequest($url, 'GET', null, null, null, $headers);
    if ($result->code != 200) {
      drupal_set_message('Could not find profiles for bpid: ' . $result->code, 'warning');


Find the person namespace of the object and load the profile

    $sx_profiles = simplexml_load_string($result->body);
    $ns = $sx_profiles->getDocNamespaces();
    $person = $sx_profiles->children($ns['person']);
    $profile = $person->bambooProfile;

Then pass the profile data to Drupal's FormAPI:

 $out[] = drupal_get_form('bamboo_as_manage_profile_form', $profile);

Use Case: Create a contact (POST)

From here on the code follows the same patterns as above, so only pointers to functions follow.

function bamboo_as_create_contact() 

Use Case: Read contact from the persons's primary profile

function bamboo_as_contact_form() 

Contact data is under the primary profile.

Use Case: Update a profile (POST)

function bamboo_as_manage_profile_form_submit($form, &$form_state) 
  • No labels