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 Within a common security context that bounds a virtual organization : • 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
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 b a b1 a1 a a1 X b1Z a1Z a1Z X a X a a2 a1 c c2 b c2Z b2 a X b2Z a1 X a a1Z a1 X c c1 c a b 1 2 Z Curator/Primary Editor Editors Contributors
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
Recommend
More recommend
