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

Skip to end of metadata
Go to start of metadata

Contextual notes

  1. The Self-Registration Application (SRA) is a specific service under the general rubric of Account Services (AS). Account Services includes self registration, account linking, and person profile maintenance.
  2. An AS landing page should be the place to redirect users whenever an RE receives a 404 from the person service when trying to retrieve a BPId given a SourcedId (IdP identifier and user identifier pair)
  3. Each suite of Account Services must be exposed as a unique web app protected by the Shib SP
  4. A Bamboo Registered and Trusted app may provide their own AS
  5. An AS must be provided for those Registered and Trusted apps that do not have their own.

also cf. Person Service Contract

srf 4 Sep 2012 ai:  Add table of contents, Add delete use case, discuss whether to allow to dissasociate all SourcedIDs from a BPID, place variations on use case 2, use case for merge

1) Authenticated user has not yet been registered in the Person Service (i.e., does not have a BPID).

Pre condition

  1. User attempts to access a restricted portion of the RE
  2. User authenticates with an institutional or social credential via the established mechanisms
  3. RE invokes the Person Service with the provided SourcedId.
  4. Person Service returns 404 (Resource not found)

Use Case

  1. RE re-directs user to AS.
    1. Provides AS with a Callback URL.
  2. AS presents user with alternatives, the relevant one to this use case being: "If you are new to Project Bamboo, please click here to register". If user chooses this, invoke the Create Account (CA) service (Technical details)
    1. CA service invokes Person Service to create a BPID and register an initial SourcedId - BPId mapping
    2. User is forwarded to the SRA interface. SRA presents contact and profile information pages for the person's input
    3. The SRA application behind the i (nterface invokes the Person Service and the Profile Service to associate the contact and profile information with the Bamboo Person Id (BPId) created in the prior step.
    4. The self registration interface confirms to the user that self registration is complete.
  3. AS redirects user to RE-provided callback URL.
  4. RE invokes the Person Service again with the SourcedId.
    1. This time the Person Service returns a BPid.

Post condition

  1. User is registered in the Person Service (i.e., has a BPid associated with the provided SourcedId)
  2. BPID is available to the RE
2) Authenticated user who has already registered as a Bamboo user is now coming in with a new SourcedId

Pre condition: same as case 1

Use Case

  1. RE re-directs user to AS.
    1. Provides AS with a Callback URL
  2. AS presents user with alternatives, the relevant one to this use case being: "If you have already registered with Bamboo, click here"
  3. Ask the user if they would like to link the account they just logged in with to another account they previously registered with Bamboo.
  4. If yes, re-direct to the Account Linking service within the Account Services system.
  5. Invite them to re-authenticate with their previously registered account.
  6. If they successfully authenticate
    1. Retrieve the BPid associated with that SourcedId
    2. Associate that BPId with the Sourcedid under which they originally authenticated via calls to the Person Service
  7. AS redirects user to RE-provided Callback URL
  8. RE invokes the Person Service again with the SourcedId.
    1. This time the Person Service returns a BPid.

Post condition

  1. User's new Sourcedid is registered in the Person Service and linked to the existing user
  2. BPid is available to the RE
3) Creating other users

a) user is a real person

  1. The person wishing to create the user, sends an email to the invitee. Email contains the URL for the Account Services page. The rest of the flow is as documented in other sections of this page.
b) user is a test user
  1. The person authenticates as test user.
  2. Remaining steps per Use Case 1
4) Authenticated User comes in from the RE with known credentials and wishes to update her profile and/or contacts.

Pre condition

  1. User attempts to access a restricted portion of the RE
  2. User authenticates with an institutional or social credential via the established mechanisms
  3. RE invokes the Person Service with the provided SourcedId.
  4. Person Service returns a BPid

Use Case

  1. User selects the appropriate link
    1. Note: this can be implemented either by selecting a link on the RE that goes to the Profile (or Contact) Update sub page of Account Servcies or by selecting  a general "manage my account" link on the RE.
    2. Regardless, the AS exposes a link to a landing page, and to each of the sub-choices (Profile, Contact, Update, Account Linking, Create User)
  2. RE directs the user to the AS landing page per options 1a. and 1b. above. 
    1. Provides AS with a Callback URL
  3. User updates profile and/or contact information and submits changes
  4. When the user indicates she has finished, she is re-redirect to the RE-provide Callback URL .

Post condition

  1. User profile and or contacts have been changed
5) User goes directly to the Account Services landing page (not via an RE) in this case to create herself as a new user

Note:   The AS landing page lists each of its constituent services in a list of links.     Once registered, a user can perform any of the operations provided by the links.

Pre condition
  1. User navigates to the AS home page
  2. AS SP redirects user to the IdP for authentication
  3. User is authenticated.
Use case
  1. User selects "Register as a new Bamboo user"
  2. Account service invokes CA sub-service.
  3. CA service invokes Person Service to create a BPID and register an initial SourcedId - BPId mapping
  4. CA returns to AS.
  5. AS forwards user to the SRA interface.
  6. SRA presents a profile information page for the person's input
  7. The SRA application behind the interface invokes the Profile Service to associate the profile information with the Bamboo Person Id (BPId) created in the prior step.
  8. SRA returns to AS.
  9. AS confirms to the user that their self registration is complete.
Post condition
  1. User is registered

Account linking variations

  1. User has not authenticated and wants to create a BPID
  2. User has authenticated and wants to create a BPID
  3. User has authenticated with SourcedID A; the user's BPID is already associated with SourcedID A; she wishes to associate the BPID with SourcedID B
  4. User has authenticated with SourcedID A; the user's BPID is already associated with SourcedID B; she wishes to associate SourcedID A with her BPID. 
  5. User has a BPID associated with both SourcedIDs A and B; wishes to unassociate A
    1. is currently authenticated as SourcedID A
    2. is currently authenticated as SourcedID B
  6. User has a BPID A associated with SourcedID A and BPID B associated with SourcedID B and wishes to merge them
  7. User has a BPID associated with both SourcedIDs A and B and wants to split the BPIDs to create one for each SourcedID (do we want to support this?)
  8. (KeithH 30 August 2012) Added a draft sequence diagram for an account linking use case

Requirements

  1. The AS functions
    1. The AS MUST provide a landing page and links for accessing all Account services funtions
      1. Note: There are different UIs for different use cases, but the back-end functions are all the same. The free-standing Account Services landing page has all the services as links (with tool tips or something to tell the user what to use when). Each of the use cases above has its own natural flow. Proper design and reuse of UI elements should make this all seem quite natural to the user.
    2. The AS MUST provide access to the following functions
      1. Person Creation
      2. Account Linking
      3. Profile maintenance
      4. Contacts maintenance
  2. AS deployment (Note well: the requirements under this section address short term direction.  There is no known implication for longer term direction)
    1. There MAY be more than one SRA deployed in the ecosystem.
    2. If there are multiple instance of the Person Service in the ecosystem, then their data stores MUST be synchronized (note: in phase 1, there will only be one Person Service)
    3. A client MAY deploy its own SRA
    4. The ecosystem MUST contain an SRA available to any client in the Bamboo ecosystem
  3. The AS and federation
    1. The AS MUST be a trusted member of the Bamboo Federation
    2. The AS MUST be protected by a Shiboleth SP
    3. The AS MUST allow the user simply to point to it with a browser
  4. Communication between the RE and the AS
    1. When redirecting the user to the AS, the RE SHOULD provide a callback url. If one is not provided, the user is not returned to the RE.
    2. When returning a user who was directed from the RE, the AS MUST direct the user to the Callback URL.
  5. Communication between the SRA and the Person Service
    1. The SRA must provide the hashed SourcedID
    2. Specifically, the SRA WILL NOT pass along the AppId on whose behalf/bequest it is asking
  • No labels

7 Comments

  1. Unknown User (falvarez@berkeley.edu)

    The Person Service currently returns a URL of the form "http://services.projectbamboo.org/bsp/persons/BPId" where "BPId" is the Bamboo Person identifier in response to a request for a BPId. Would it be more useful to return just the BPId and save the RE the trouble of parsing the URL to get the data it really wants?

  2. Unknown User (falvarez@berkeley.edu)

    Authenticated User comes in with known credentials and wishes to update her profile

    Please confirm that the ownership predicate implied in "her profile" is true if the BPId provided in the request URL equals the BPId passed in the HTTP header.

    Can anyone other than the owner create / update a profile?

  3. Unknown User (falvarez@berkeley.edu)

    To clarify, all calls from a Registered App, including the SRA, will pass their AppId in the appropriate header.

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

    I believe that we have stipulated that the profile update page of Account Service (AS) is intended to be Shib-protected. Therefore the identity of the user in question will be carried in a SourcedId available under the IdP identifier and the remote user identifier in the environment.

    Delegated update of a Bamboo person's contact/profile is a use case yet to be detailed (if we want to support it).

  5. Unknown User (masover@berkeley.edu)

    @Scott et al. – I have reviewed the changes made on this page by Scott on 16 May, changed a few typos and word omissions, and I think Scott's changes have addressed my comments of 15 May.

  6. Unknown User (quinnd@berkeley.edu)

    As I've been working through the storyboards for the Drupal module that will do this, with guidance and clarification from Steve, it seems like we need to rename what we're building. It does more than self-registration-- this app needs to cover Account Services more broadly. So for the sake of clarity, can we refer to this as the Account Services App?

  7. Unknown User (sfullerton@wisc.edu)

    Regarding Quinn's suggestion above: makes sense to me as long as we understand Self Registration as being one of the functions of the Account Services