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

Skip to end of metadata
Go to start of metadata

Terms and abbreviations

The following terms and abbreviations appear in the use case scenarios:

  • Account Services Module: a user-facing web-based app that allow users to register for a Bamboo Person identity; and to view, add, and update information associated with that identity. Centrally-hosted backing services, accessed from the Account Services Module via RESTful web services calls, manage different parts of that information: the Person Service, the Profile Service, and the Contact Service; the module itself delegates information management to the backing services. Bamboo is providing an Account Services Drupal module that can be installed within its Drupal-based Research Environments, so that users of these environments -- hosted by institutions, disciplinary groups, et al. -- can register and manage Bamboo Person identities from within a familiar application. Bamboo will also provide a stand-alone Drupal instance whose sole purpose is to provide the functionality of the Account Services Module, independent of any Research Environment or other application. Account Services functionality can be described in three categories:
    1. Self-Registration: New users can create an identity and link it to an external identity provider (see definition below). On self registration, a user is also asked to self-assert profile information.
    2. Profile Maintenance: A user can update profile and contact information (see description of Profile Service and Contact Service below)
    3. Account Linking: A user can associate additional identity providers with a Bamboo Person identity, permitting login via multiple identity providers (definition below) while maintaining a uniform identity – irrespective of IdP used to authenticate in a given session – within Bamboo's ecosystem of environments, applications, and services.
  • Research Environment: a Drupal site provisioned with specialized modules and a Fedora-based object store, that enables humanities scholars to work with textual and other content. Research Environments permitted to access the centrally-hosted backing services that manage Bamboo identities must meet a set of requirements that include (a) operation as a Shibboleth Service Provider (SP); and, (b) be operated by an institution or group with whom Project Bamboo has certain legal agreements. Research Environments that meet these requirements are considered to be Trusted Applications within the Bamboo Ecosystem.
  • Identity Provider (IdP): An authentication service that provides identities. For Bamboo's purposes, these are Shibboleth instances run by universities that authenticate affiliates including faculty, students, and staff; and social media identity providers such as Google and Facebook, whose Authentication services can be leveraged by external applications. Bamboo will run a Social/SAML Gateway to 'translate' attributes returned by social media IdPs into SAML, the data exchange standard used by Shibboleth and throughout the Bamboo ecosystem for expressing information pertaining to authentication events.
  • Centrally-hosted RESTful Backing Services
    • The Person Service stores a unique Bamboo Person ID (BPId) and any number of SourcedIDs (see definition below). Linkage between a BPId and SourcedIds associates Bamboo identities with existing accounts provisioned by universities and social media providers, such as UC Berkeley, UW Madison, Google, and/or Facebook. (Person API, expected to stabilize in August 2012)
    • The Profile Service stores self-asserted information about a user's expertise, languages associated with areas of research, affiliations, and externally-hosted profiles (Profile API, expected to stabilize in August 2012)
    • The Contact Service stores contact information like name, email, IM handle, and phone number (Contact API, expected to stabilize in August 2012; cf. Person API for selected methods, currently being refactored to a separate Contact API)
  • Bamboo Person ID (BPId) uniquely identifies an individual within the Bamboo ecosystem. The Bamboo Person ID is the token used to track a user's actions across environments and services. It is the common identifier used to request information about a user from the Person, Profile, and Contact services.
  • SourcedID: the combination of a user identifier and an IdP identifier provided by an IdP upon successful user authentication. A SourcedId may be associated with a BPId, as described in the description of Bamboo's centrally-hosted Person Service, above.

Contextual notes

All pages generated by the Account Services Module should be available only to users who have logged in using one of those IdPs, with the exception of the LOGIN PAGE (0), to/from which the user may be directed.. (A user may be previously-authenticated if s/he comes to the landing page for an instance of the Account Services Module that is embedded in a Research Environment; in the standalone deployment of the module, all pages on the site -- with the exception of the landing page as noted at the start of this paragraph -- will be protected resources that require pre-authentication handled by Apache httpd plus Shib SP software beyond the scope of the Account Services Module. See below.)

The module will be installed in either of:

  1. A Drupal-based environment in which users are logged in prior to being directed to the Account Services Module [e.g., a Drupal-based Research Environment operating as a Shibboleth Service Provider (Shib SP), that uses the shib_auth module for its own authentication]; or,
  2. a stand-alone Drupal that people can use to manage their Bamboo identities from a web browser, independent of any Research Environment or other application.

In these two contexts, the module will inspect the $_SERVER headers (as described in shib_auth documentation) for user attributes.

The Drupal running the stand-alone self-registration app does not need to persistently store user information by itself (i.e. as Drupal users). Session state must be maintained as the user navigates through the Account Service Module functionality, but no state needs to be preserved by the module/Drupal between sessions; all persistence is handled by the centrally-hosted RESTful Backing Services.

In all calls to the BSP-hosted Person Service, the User Id component of SourcedId returned by an IdP must be transformed by a one-way SHA-256 hash function, yielding a 32 character hexadecimal string, before the client (AS Module) passes the parameter to the BSP.

Narrative

0. Login Page

The login page has a single role: to present the user with a link or button that redirects to the AuthN module(s) of the Drupal host (whether in the "standalone" or "in-RE" deployment). The mechanics of authentication is outside the scope of the Account Services module.

Users may get to the login page by any of the following means:

  • if directed/redirected to it via a link to its URL
  • if a user types its URL into a web browser

Redirection to the Login page occurs if a user attempts to access any protected resource in the AS module (e.g., any page) when NOT logged in.

For the record, authentication is handled by Apache httpd + Shib SP software installed on the Drupal host, or (in the case of shib_auth) as a Drupal module.

1. Landing page

The landing page presents links after a user has authenticated to an IdP (the user must be redirected to the Login Page (0) to authenticate if this page is requested prior to login).

The user may or may not have associated her account on the authenticating IdP with an existing Bamboo Person identity. Behind the landing page, the Account Services Module will call the Bamboo Person service (cf. Person API, Read a BPId) to determine whether the external account used to authenticate is associated with an existing Bamboo Person identity or not, and redirect the user differently depending on this determination.

The combination of User Identifier and IdP Identifier that comprise the user attributes available following successful authentication are referred to as SourcedId (see definition above).

Two conditions can result from the Account Services Module call to the Bamboo Person service:

  • SourcedId IS associated with a Bamboo Person identity: see 1.0, below.
  • SourcedId is NOT associated with a Bamboo Person identity: In this case, a user is presented with a page giving choices for subsequent action; see 1.1, below.
1.0 If a BPId is associated with the AuthN-generated SourcedID:

Redirect to page 4 (View Profile)

1.1 If no associated BPId is found:

The user can either create a new Bamboo Person identity and associate the SourcedID that resulted from their successful authentication with that identity; or associate the SourcedID to an existing Bamboo Person identity.

The page presents two options:

  • 1.1.1 Create new Bamboo Person Identity (link)
    • Clicking this link sends the SourcedID to the Bamboo Person Service, which returns a new Bamboo Person ID (BPId) that's associated with the SourcedID (cf. Person API, Create a BPId)
    • Response data is displayed as part of page 2, to which the user should be directed following successful creation of a BPId
  • 1.1.2 Associate SourcedID with existing Bamboo Person identity (link)
    • Clicking this link sends the person to page 3.1
  • 1.1.3 Cancel Account Services activities
    • Clicking on this link sends the person to the callback URL (if available)

2. Editing Bamboo Profile info

[The user must be redirected to the Login Page (0) to authenticate if this page is requested prior to login.]

This page appears either:

  1. when a user has sent a new SourcedID to the Bamboo Person Service with a request to generate a new Bamboo Person ID (BPId), and the Bamboo Person Service has responded with the new BPId (cf. Person API, Create a BPId)
  2. when a user who has authenticated with a SourcedID known to the Bamboo Person Service (cf. Person API, Read a BPId) wants to edit their profile or add a linked account

The page presents the following information:

  • Each of the data fields stored by the Profile Service is presented to the user, who has the option of filling them out or not. (All of these are either text fields or URLs; some are multi-value, cf. Profile API, Create a Person Profile).
  • Each of the data fields stored by the Contact Service is presented to the user, who has the option of filling them out or not. (This can include name, email address, IM, phone number, etc.; the Create a Bamboo Contact on the Person API page as of 18 Aug 2012 will be refactored and moved to the Contact API by the end of the month)
  • A link, "Add or remove a linked account", that takes the user to a page where they can choose another known provider to authenticate with, and the Account Services module will send this SourcedID and the BPId to the Person Service, to connect the two (cf. Person API, Create a SourcedId)
    • Clicking this link first saves any information that's been added or changed in the data fields, by sending it to the UPDATE methods of the Profile and/or Contact services, and then directs the user to page 3
  • A save button (saves profile information by sending it to the UPDATE methods of the Profile and/or Contact services)
    • Clicking this link directs the user to page 4 (View Profile)

3. Account linking

[The user must be redirected to the Login Page (0) to authenticate if this page is requested prior to login.]

This page allows authenticated users (for whom a BPId has already been obtained by the Account Services Module) to authenticate with a second IdP, in order to link that additional account with their Bamboo Person identity.

The page presents the following information:

"Please click this link to authenticate with a different Identity Provider to which you wish to link your Bamboo Identity."

Clicking this link directs the user to authentication apparatus external to the Account Services module (see Contextual notes, above). Outside the context of the Account Services module, the user is presented with a WAYF list and allowed to authenticate with the selected IdP. If authentication is successful the resulting SourcedID components are returned and made visible in $SERVER headers as described in the Contextual notes above; whereupon the Account Services Module sends the new SourcedID to the Bamboo Person Service (cf. Person API, Read a BPId).

A PoC demonstrating this functionality, against which the AS Module developer can code, is a prerequisite to be provided before work on this aspect of the module can commence. Some of the details in this Account Linking scenario may change once the PoC is completed. See draft sequence diagram on the child page, Account Linking Service Draft Sequence Diagram for a conceptual overview of this functionality.

  • If the SourcedID is already associated with the BPId for this user (Person service returns same BPId obtained from the user's initialAuthN), that means that the SourcedID is already connected to the user's Bamboo Person identity.
    • Direct user back to page 3 with error message "This account is already associated with your Bamboo Person identity."
  • If the SourcedID is found, but is associated with a DIFFERENT BPId, that means that the SourcedID has been linked with a Bamboo Person identity that the person created previously (i.e., the Person service returns a BPId different from the one obtained from the user's initialAuthN).
    • Direct user back to page 3 with error message "Your login is already associated with a different Bamboo Person identity. A login may only be associated with one Bamboo Person identity. If you want to associate the account to which you have just logged in to this Bamboo Person identity, you must dissociate it from that different identity first. To do so, you must first log out completely, then log in using the IdP and user account you are currently trying to associate, and unlink it from its current Bamboo Person identity."
  • If the SourcedID is not found, store that SourcedID with the BPId in the Person Service (cf. Person API, Create a SourcedId)
    • Send user back to page 3 with an info notice "You have successfully associated <SourcedID> with your Bamboo Person Identity"

The page also displays the accounts (SourcedIds) that have previously been linked with the BPId, with a "remove" button next to each one. Clicking the "remove" button will trigger a warning message asking for confirmation, and if confirmed, will send a request to the Person Service to remove that SourcedID (cf. Person API, Delete a SourcedId). [Note: the readability of the content displayed about the SourcedId will depend on the IdP. Further testing is needed. Users will be permitted (but not required) to associate a "nickname" with each SourcedId to help them manage accounts associated with a Bamboo Person identity.] 

In addition, this page includes a link to take the user back to the view profile page (page 4).

3.1 Connecting a user authenticated with a new SourcedID to their existing Bamboo Person identity

[The user must be redirected to the Login Page (0) to authenticate if this page is requested prior to login.]

When a user authenticates to Bamboo for the first time with a new IdP ("SourcedId B") and already has a Bamboo Person identity, s/he can associate SourcedId B with their existing Bamboo Person identity. This page gives them the opportunity to:

  1. authenticate with a SourcedId already associated with their existing Bamboo Person identity ("SourcedId A") to prove ownership of the identity; and then,
  2. to associate SourcedId B with that existingBamboo Person identity.

The page presents the following information:

"Please log in using an identity provider you have already associated with your Bamboo Person identity.

Clicking this link directs the user to authentication apparatus external to the Account Services module (see Contextual notes, above). Outside the context of the Account Services module, the user is presented with a WAYF list and allowed to authenticate with the selected IdP. If authentication is successful the resulting SourcedID components are returned and made visible in $SERVER headers as described in the Contextual notes above; whereupon the Account Services Module sends the new SourcedID to the Bamboo Person Service (cf. Person API, Read a BPId).

A PoC demonstrating this functionality, against which the AS Module developer can code, is a prerequisite to be provided before work on this aspect of the module can commence. Some of the details in this Account Linking scenario may change once the PoC is completed.

The page also includes a "create new account" link, if users decide not to connect SourcedID B to an existing BPId, but instead, create a new Bamboo Person identity.

  • If the user successfully authenticates with the IdP, the resulting "SourcedId A" is sent to the Person Service (cf. Person API, Read a BPId), and if SourcedId A matches an existing BPId, the Account Services Module associates SourcedId B with it, thereby linking both logins to the same Bamboo Person identity (cf. Person API, Create a SourcedId).
  • If the user successfully authenticates with the IdP, and the resulting "SourcedId A" is NOT found to be associated with a Bamboo Person identity (cf. Person API, Read a BPId), the user is returned to page 3.1 with an error message saying that SourcedId A is not associated with a Bamboo Person identity. The error message will include a link for creating a new Bamboo Person identity, which will trigger the account creation process (see 1.1.1).

Additionally, the page contains a link to take the user back to the view profile page (page 4).

4. View profile

[The user must be redirected to the Login Page (0) to authenticate if this page is requested prior to login.]

This page displays all the information that the user has added to their Bamboo Profile (pulled in from the Bamboo Profile Service and Contact services), plus the SourcedIDs they've associated with their Bamboo Person identity (pulled in from the Bamboo Person service).

  • An "edit" link near the profile information takes the user to page 2, where they can edit the information stored by the Bamboo Profile & Contact Services
  • A "link additional accounts" option near the list of SourcedIDs associated with the account takes the user to page 3, where they can add new SourcedIDs
  • From within the "view profile" page, the user can select any of the SourcedIDs listed and click a button to unlink them from the Bamboo Person ID
  • A "Done with Account Management" link that returns the user to a provided callback URL. This is only an option if a callback URL is provided.

Diagram

Account Services Module Page Flow

Interactions

#

Name of interaction/page

Participants

Actions

Result

A

START (authenticated user who has previously created a BPId)

  • User
  • AS module
  • Person Service
  • Authenticated user is directed to the landing page for the AS module
  • AS module inspects $_SERVER headers for user attributes (SourcedID)
  • AS module contacts Person Service, performs Read a BPId using above-mentioned SourcedID
  • AS module receives BPId from Person Service

Process continues at E

B

START (authenticated user w/o BPId)

  • User
  • AS module
  • Person Service
  • Authenticated user is directed to the landing page for the AS module
  • AS module inspects $_SERVER headers for user attributes (SourcedID)
  • AS module contacts Person Service, performs Read a BPId using above-mentioned SourcedID
  • Person Service responds with 404

Display 1.1 (Landing page 1.1)

C

START (unauthenticated user)

  • User
  • AS module
  • Unauthenticated user is directed/redirected to Login Page 0 (C), where s/he initiates authentication via httpd + shib
  • After successful authentication, return user (C1) back to the regular flow:
    • (D1) if AS module receives BPId from Person Service, process continues at E (storing SourcedIDs in current user session)
    • (D2) if AS module receives 404 from Person Service, display 1.1 (Landing page 1.1)

0

Login Page 0

  • User
  • AS module
  • AuthN technology hosted by containing server / Drupal instance
  • User clicks link or button to initiate authentication via httpd + shib (X1)
  • AS module inspects $_SERVER headers for user attributes (SourcedID) and finds them after successful authentication
  • AS module contacts Person Service, performs Read a BPId using above-mentioned SourcedID
  • After successful authentication, return user (C1) to regular flow:
    • (D1) if AS module receives BPId from Person Service, process continues at E (storing SourcedIDs in current user session)
    • (D2) if AS module receives 404 from Person Service, display 1.1 (Landing page 1.1)

1.1

Landing page 1.1

  • User
  • AS module
  • AS module presents user with two options:
    • Create new Bamboo Person Identity
    • Associate SourcedID with existing Bamboo Person Identity
  • User can also cancel Account Services activities
  • if creating new, process continues at G
  • if associating w/ existing, display 3.1
  • if canceling, process concludes at Z
  • if user arrives at this page but is not authenticated, redirect to Login Page 0 (C)

D

[Intentionally blank]

 

 

See 0 (Login Page 0), above

E

Storing SourcedIDs in current user session

  • As module
  • Person Service
  • AS module sends BPId to *Person Service *and performs List all SourcedIds for a BPId
  • AS module stores SourcedIDs returned by the *Person Service *in current user session

Process continues at F (load View Profile page)

F

Loading View Profile page (4)

  • AS module
  • Person Service
  • Contact Service
  • Profile Service
  • AS module performs Read a Person Profile with the Profile Service by submitting the BPId. Multiple profiles may be returned (edge case).
  • AS module performs Read a Bamboo Contact (multiple times if multiple profiles) with the Contact Service by submitting the Contact Id in the profileContact attribute of each retrieved profile
  • AS module uses the responses from these interactions to populate the View Profile page with all Person Profile and Contact data, as well as a list of all sourced IDs

Display 4 (View Profile Page)

4

View Profile page (4)

  • User
  • AS module

This page presents the following options:

  • Edit contact/profile info
  • Link new SourcedIDs
  • Unlink SourcedIDs
  • Done with Account Management
  • If User clicks on edit contact/profile info: display 2 (Edit Profile Page)
  • If User chooses to link new SourcedIDs: display 3 (Account linking Page)
  • If User wants to unlink sourcedIDs: process continues at K
  • If User is done with account management: process continues at Z 
  • if user arrives at this page but is not authenticated, redirect to Login Page 0 (C)

G

Creating a new BPId (from Landing page 1.1)

  •  User
  • AS module
  • Person Service
  • User chooses to create a new BPId to associate with their current SourcedID
  • AS module performs Create a BPId by submitting the SourcedID to the Person Service
  • Person Service responds with a new BPId

Display 2; send header data indicating this is a NEW profile

2

Edit Profile page (2)

  • AS module
  • AS module displays user-editable form; fields are hard-coded, see API documentation for Contact Service and Profile Service for list of fields
  • AS module presents the responses as a form, with one field per attribute
  • If there are multiple profiles present, they are clearly distinguished; exactly one profile is marked as PRIMARY and user may choose which of multiple profiles to mark as PRIMARY.

If header indicating this is a new profile is present, process continues at H

Otherwise, process continues at I

if user arrives at this page but is not authenticated, redirect to Login Page 0 (C)

H

Creating new profile

  • User
  • AS module
  • Contact Service
  • Profile Service
  • User fills out as many fields as they want, and hits "submit", OR: user fills out as many fields as they want, and hits "link additional identities" link
  • AS module sends data corresponding to Contact Service attributes to Contact Service to perform Create a Bamboo Contact; receives contact ID
  • AS module sends data corresponding to Profile Service attributes + user's BPId + contact ID to Profile Service to perform Create a Bamboo Profile
  • If user just submitted data for fields, process continues at F (load View Profile page)
  • If user chose to link additional identities, display Account Linking page (3)

I

Editing existing profile

  • User
  • AS module
  • Contact Service
  • Profile Service
  • AS module requests from Contact Service and Profile Service all the values previously entered by the user by sending the user's BPId (Read a Bamboo Contact, Read a Bamboo Profile)
  • AS module presents the user with a form showing the data they previously entered, and empty fields corresponding to the user-editable attributes where they previously did not enter any data
  • User fills out as many fields as they want, and hits "submit", OR: user fills out as many fields as they want, and hits "link additional identities" link
  • AS module sends data corresponding to Contact Service attributes + user's BPId to Contact Service to perform Update a Bamboo Contact
  • AS module sends data corresponding to Profile Service attributes + user's BPId to Profile Service to perform Update a Bamboo Profile
  • If user just submitted data for fields, process continues at F (load View Profile page)
  • If user chose to link additional identities, display Account Linking page (3)

3

Account linking page

  •  User
  • AS module
  • AuthN technology hosted by containing server / Drupal instance
  • AS module permits user to initiate AuthN with an alternate IdP, at which point s/he is handed off to the AuthN machinery installed on the host server / Drupal instance (X2)
  • User can also click on a link to return to viewing their profile
  • If user chooses to authenticate, process continues at J
  • If user returns to viewing their profile, process continues at F
  • if user arrives at this page but is not authenticated, redirect to Login Page 0 (C)

J

Linking an account

  •  User
  • AS module
  • Person Service
  • IdP
  • If authentication is successful, SourcedID components are made available in a $_SERVER header
  • AS module inspects $_SERVER headers for user attributes ("SourcedID B")
  • AS module contacts Person Service, performs Create a SourcedID

Process continues at M (Creating a SourcedID)

K

Account Unlinking action (presented on page 4, View Profile)

  • User
  • AS module
  • Person service
  • AuthN technology hosted by containing server / Drupal instance
  • Userselects one of the SourcedIDs associated with their BPId for un-linking
    • If user has only one SourcedID associated with their account, and attempts to select it for un-linking, the AS module displays a warning that a user cannot remove the only SourcedID associated with their account.
  • AS module displays a warning alert box, asking if the user is sure they want to un-link that SourcedID
  • If the user confirms, the AS module performs Delete a SourcedID by sending the selected SourcedID and the BPId to the Person service
  • If this is successful, return a message saying that <SourcedID> is no longer linked to this Bamboo Person Identity

Remain on the View Profile page (4)

3.1

Account linking page (variant for linking currently-authenticated SourcedID with previously created BPId)

  • User
  • AS module
  • AuthN technology hosted by containing server / Drupal instance
  • AS module permits user to initiate AuthN with an alternate IdP, at which point s/he is handed off to the AuthN machinery installed on the host server / Drupal instance (X3)
  • User can also click on a link to create a new BPId instead
  • If user authenticates, process continues at L
  • If user chooses to create a new BPId, process continues at G
  • if user arrives at this page but is not authenticated, redirect to Login Page 0 (C)

L

Linking account (currently-authenticated SourcedID with previously created BPId)

  • User
  • AS module
  • Person service
  • If authentication is successful, "SourcedID A" components are made available in a $_SERVER header
  • AS module inspects $_SERVER headers for user attributes (SourcedID A)
  • AS module contacts Person Service, performs Read BPId using SourcedID A; Person Service responds with BPId
  • AS module performs Create a SourcedID with Person Service using the BPId it just received + SourcedID B (from the user's original AuthN session)
  • (L1) If Person Service responds with BPId, process continues at M (Creating a SourcedID; SourcedID B-- from user's original session-- is sent in this process)
  • (L2) If Person Service responds with 404, display 3.1 with error message "<SourcedID A> is not associated with a Bamboo Person Identity."

M

Creating a SourcedID

  • AS module
  • Person Service
  • AS module performs Create a SourcedID by sending the SourcedID and BPId to Person Service 
  • (M1) If Person Service responds with 200, display View Profile page (process F --> page 4) with message stating that that SourcedID is now linked with the current Bamboo Person Identity
  • If Person Service responds with 405, check user session values for SourcedIDs (retrieved in process E):
    • (M2) If SourcedID B matches a SourcedID stored in the current user session, return to Account Linking page with error message stating that SourcedID is already associated with the current Bamboo Person Identity
    • (M3) If SourcedID does NOT match a SourcedID stored in the current user session,  return to Account Linking page with error message stating that the user has to un-link that SourcedID from another Bamboo Person Identity before adding it to their current BPId

X

Handoff to AuthN

  • User
  • AS Module
  • AuthN technology hosted by containing server / Drupal instance
  • Account Services module hands off user to AuthN technology (shib plus httpd)
  • User chooses IdP from WAYF (presented by AuthN technology)
  • User handoff to IdP, Authentication, redirection to AuthN technology (handled by AuthN technology)
  • AuthN technology appropriately populates $_SERVER headers and returns to calling page/component
  • User is returned to calling component or page. Cf. Gliffy.

Z

Go to callback URL

  • User
  • AS module
  •  User has clicked on a link to return them to where they were before engaging in Account Services activities; this link is only available if the environment provided the AS module with a callback URL when loading one of the landing pages
  • AS module returns the user to the callback URL

END

  • No labels

3 Comments

  1. Unknown User (masover@berkeley.edu)

    This page is under active review by Brian Wood at UC Berkeley as he considers implementation of Account Services functionality as a Drupal module.

    For that reason, edit privileges on the page are restricted. Please feel free to comment liberally on the page, or to direct IAM-team focused issues/questions to the IAM-team list, iam@lists.projectbamboo.org.

  2. Unknown User (hazelton@doit.wisc.edu)

    I added a child page with a draft sequence diagram for an account linking service use case.

  3. Unknown User (hazelton@doit.wisc.edu)