2012-02-27 DfR Technical Meeting

Regular Attendees

• Andrew
• Bill
• Brad
• Chris
• Dan
• Jonathan

General

• Call In To: Free Conference Call HD - DuraCloud Line

  Please note that we will be using the Free Conference Call HD line for this call. Information about calling into this line is available from the link above.

• - Indicates who will be taking minutes

Discussion Topics

Planning Board
Task Board
DfR Planning and Estimating - 0.1

Actions from last meeting

Last meeting

Last Weeks Actions:

Related Information
DfR Software Next Steps - Jan 2012
2012-01-03 - Architecture Meeting, Temple University

Status

• Jonathan
• Andrew
  • What I have put together so far are two AMIs, one of which has the
    Shib IdP installed and configured (apache2 and the IdP servlet), the
    other of which has the Shib Service Provider (SP) installed and
    configured (apache2, mod_shib) and a test web application that is
    being "secured" by Shib.
    The build and configuration notes of the AMIs are found here:
  • Shibboleth IdP Setup
  • Shibboleth SP Setup
  • Additionally, I have set up a simple LDAP server on the IdP that
    provides the backend authentication source for the Shib framework.
  • When hitting the "secured" web app on the SP, apache2 redirects the
    user to the IdP, if a user session does not exist, the user is
    prompted for credentials which are checked against the LDAP, then the
    user is redirected back to the "secured" target resource.
    In this process, the Shib IdP and SP have been configured to send and
    populate the REMOTE_USER attribute, which is available to the
    "secured" web application.
  • I have also modified a local instance of Duradmin to use Spring
    Security's PreAuthentication components to read the REMOTE_USER
    attribute and query the LDAP on the IdP for that user's groups and
    roles. This last part of setting up the proper LDAP query from Spring
    Security is not quite returning the expected values yet.
  • Some additional remaining pieces include:
    • need to model LDAP to hold the DuraCloud (DfR) user details
      appropriately (users, accounts, groups, roles)
    • need to weigh the possibility of using Shib for the browser-based
      authentication interactions, and security tokens for REST-based
      authentication interactions
• Bill
  • Engaged in design of the Auto-User (now called Executor) with Andrew.
    • Jira item
    • Design page
• Brad
• Chris
  • Finished tasks for DFR-11 and got a working end-to-end OCS ingest & delete test going between DuraCloud & Fedora.
  • While doing DFR-11 tasks, identified a couple stories (using "E" type datastreams and persisting MD5 checksum in Fedora) that should be written for an upcoming iteration. Both of these require outstanding Fedora issues to be addressed.
  • Started DfR Development Resources with various info/links important to DfR developers, including coding guidelines which should be reviewed by others dev-types (try out the intellij settings attached to that page).
• Dan
  • Discussed OCS-related stories with Chris
  • Reworked Jira-Greenhopper to include release assignment
  • Reviewed Jira setup with Jonathan to better meet his needs
• Jonathan

Minutes

Chris: Infrastructure:

• Set up page, take a look at coding standards.
• Document key decisions about Tomcat, etc, on Development Resources page.
• Andrew: idp.duracloud.org now hosts shibboleth IdP and an LDAP server. Dev-oriented but could evolve into the ultimate place for this stuff at some point.

Andrew: Shibboleth:

• Seems like Shib will be sufficient (no need for CAS or apache security project) unless I'm missing something.
• Bill: REST API via Shib or use an access key/private key pairing?
• Chris: Web UIs shibbolized, and programmatic APIs use access key idea?
• Andrew: Yes
• Brad: Outside developers would have an extra step: Authenticate to DfR using their user/pass, and we give them a key file they can use to authenticate to REST apis for programmatic access.
• Jonathan: Where's LDAP?
• Andrew: A few roles. Two authN pathways. Depends on which app you're hitting. Through browser, will be fully shib. Either authenticated with DuraSpace's IdP or another institution's IdP, either of which can be LDAP-backed. However, the REST API pathway would use keys.
• Andrew: Any LDAP aficcionados? Looking for best practices.
• Chris: Don't love LDAP, but would be willing to talk about best practices I've found

Dan: Status of Issues:

• DFR-1: Moved to Unscheduled as per Dan & Chris discussion
• DFR-74:
  • Chris: Think a checksum-related story for this iteration might make sense for me…see status re:Fedora issues with asserting checksum. But not necessarily this issue as written.
  • Consensus to add additional Fedora issue and keep this one scoped completely to DuraCloud as written.
• DFR-64: Closed as dupe. Andrew will take off the fix version.
• DFR-23: Functional needs/expectations of researchers for sync tools on their systems.
• Chris: Scope of task…probably not realistic to fully address this in first iteration. Should we couch it to be scope to just this iteration, or keep it general and span multiple iterations? (Maybe it's an epic?)
• Dan: De-scope down to low level to what can be done for this iteration.
• Bill: Would like to have discussion about technology options. Local vs remote web-based UI?
• (Discussion of time budget for DfR 0.1, Andrew & Chris note that they used a lot of available time last week)

Jonathan:

• Fluid dilemma (availability & fit problematic for us)
• This Friday 12pm, Mark is doing demo of Smithsonian Demo. Don't have connection info yet.

Actions

TBD