Identity in Humanist Workflows Project Bamboo Infrastructure for - - PowerPoint PPT Presentation

Identity in Humanist Workflows

Project Bamboo Infrastructure for collaboration, content access, and provenance tracking

Keith Hazelton, Steve Masover http://www.projectbamboo.org

Project Bamboo is supported by the Andrew W. Mellon Foundation

Project Bamboo

• Goal: common infrastructure

– for humanist scholarship – across disciplines, institutions, continents (U.S., Europe, Australia)

• Planning phase:

– April 2008 – September 2010 – 8 workshops / 115 institutions / 600+ humanists, technologists, librarians

• First technology development phase

– October 2010 – September 2012 – 10 institutions: ANU, Berkeley, Chicago, Illinois (UIUC), Indiana, Madison, Maryland, Northwestern, Oxford, Tufts – Focus on IAM, collection interoperability, adaptable research environments, proxied services for textual analytics

• Second technology development phase

– Proposal pending – Focus on curation & annotation of textual materials

Project Bamboo Ecosystem: Overview

• Scholars access research

environments through a web browser

• Research Environments e.g.,

Drupal-based UI, Fedora object store

• Services Platform atop FUSE

ESB / Apache ServiceMix

• Collections Interoperability Hub

(CI Hub): content access, normalization

• Green boxes are Bamboo-built;
• “Cloud”-enclosed elements are

external to Bamboo: at campuses, projects, archives, etc.

• Not shown: Social/SAML

gateway enabling social IdP login

• Not shown: centrally-hosted

Group service that clients may use to synchronize memberships across apps / environments

Within a common security context that bounds a virtual organization:

Digital Content from Heterogeneous Repositories

Humanist scholars want/need to:

• Normalize content for

consumption by tools: so toolmakers need not accommodate each repository’s idiosyncratic content delivery format

• Enforce access policy set by

content owner (e.g., scholar’s campus affiliation permits access when institution has the appropriate subscription…)

Normalize Content

• Bamboo Content Interoperability

Hub transforms to shared content model

– Normalize selected metadata – Transforms heterogeneous content models to present stable API to consuming tools – Proposed work in phase two:

• Provenance of automated & manual

annotations / derivatives / diffs

• Bi‐directional: e.g., annotated texts

returned to source repo

Enforce Access Policy

• Bamboo’s Content Interoperability Hub enforces

access policy on behalf of repositories:

– institutional affiliation (federated AuthN) – institutional roles (not there yet)

• Shared Identity within

Bamboo ecosystem

• User attributes NOT

shared with repos

• Policy enforced within

Bamboo

• Repositories trust

Bamboo to ‘do the right thing’

Identity and Provenance Tracking

• Scholars correct and/or augment materials:

manually and/or algorithmically

• Contributors, editors, curators: review and

vetting processes

• Log provenance (including actor’s identity,

software versions) at each stage:

– To log credit – To correlate trustworthiness with reputation – To prioritize candidate contributions for editorial review (“reputational ranking”)

Vetted Curation/Annotation

a c b 1 2 Z

Contributors Editors Curator/Primary Editor

a c a c a b a a b a a1 c1 a1 c2 a2 b1 a1 a1 b2 a1

X X X X

a1Z a1Z c2Z b1Z a1Z b2Z

X X

Collaboration: An Ecosystem of Heterogeneous Tools

• No single application “to rule them all”
• Common identity context for access and

logging

• Facilitate ingress and egress:

– Ingress: materials of scholarly interest – Egress: corrections, annotations, analytical data sets, etc. ‐‐ for sharing, archiving, publication

User Enrollment and Lifecycle

• Anybody can play

– “Community of curators” may not all be affiliated with a university ... this is a key driver for Social IdP logins – Identities must be distinguishable, even when they are ‘anonymized’ or otherwise not verified as a ‘real person’

• Once a contributor, always citable

– Bamboo’s user profile is thin to reduce duplication, maintenance burden on users – Self‐assertions include capacity to associate “other profiles,” which might include self‐owned domain URL; VIVO profile URL; ORCID; or similar

• Reduce userbase bloat via self‐service signup

User Account Management (1 of 2)

• Account Services functionality permits anyone who can

authenticate to any IdP recognized by Project Bamboo to:

– Self‐register as a “Bamboo Person,” linking an externally provisioned identity to a namespaced, unique Bamboo Person identifier (BPId) – Maintain self‐asserted profile information – Link additional externally provisioned identities to an established BPId (‘account linking’) by proving ability to

• authenticate to an IdP already linked to an existing BPId
• authenticate in the same user session to the “new” IdP to be

associated with that BPId

• The Account Services functionality:

– Is implemented by centrally‐hosted web services, accessible via a RESTful API – Populates a centrally‐accessible store of identity data – Is protected by TLS‐level client auth (only trusted apps may make RESTful service calls to Person service, et al.)

User Account Management (2 of 2)

• A user interface for Account Services is being

implemented as a Drupal module.

– One instance of the Account Services module will be run by Project Bamboo as a standalone, accessible from any web browser – Research Environments built atop Drupal and within the Bamboo Trust Federation may deploy the Account Services module to provide account management services within its own application context – Account Services function may alternately be accessed by suitably trusted/vetted applications that implement a front end to the centrally‐hosted RESTful web services.

Self‐Registration

• WAYF presents campus & social IdPs in Bamboo’s

trust network

• User authenticates to self‐selected IdP
• IdP returns User Id & IdP Identifier (“SourcedId”)
• Person Service: map “SourcedId” to new Bamboo

Person identifier (BPId)

• Profile/Contact Services: user self‐asserts profile

information

Profile Maintenance

• Same as prior slide:

– WAYF presents … – User authenticates … – IdP returns “SourcedId”

• Person Service: locate Bamboo Person identifier

(BPId) previously mapped to “SourcedId”

• Profile/Contact Services: GET profile/contact info for

BPId

• Account Services presents, user edits profile/contact
• Profile/Contact Services: PUT profile/contact info

Account Linking

• Same as prior slide:

– WAYF presents … – User authenticates … – IdP returns “SourcedId” – Person Service: locate BPId mapped to SourcedId

• Account Services Module: cache BPId
• Account Services Module: direct user to alt IdP
• User authenticates at IdP #2
• IdP #2 returns SourcedId #2
• Person Service: map “SourcedId” to existing BPId

Joining the Bamboo Trust Federation

a work in progress…

• Application / Research Environment (RE) must:

– Operate as a Shibboleth SP – Participate in TLS client auth connections

• App/RE Operator must:

– Agree to Terms of Service (TBD) requiring “good citizen” behavior within Trust Federation – Accept SLA (TBD) for centrally operated IAM services

• Technical requirements include:

– Shibboleth metadata exchange – Public key exchange with centrally hosted components for client auth

Fini

http://www.projectbamboo.org http://wiki.projectbamboo.org

feedback@lists.projectbamboo.org Keith Hazelton: hazelton@wisc.edu Steve Masover: masover@berkeley.edu

Project Bamboo is supported by the Andrew W. Mellon Foundation