Versions Compared

Old Version 2

changes.mady.by.user Daniel Davis

Saved on

compared with

New Version Current

changes.mady.by.user Daniel Davis

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Table of Contents

Components

DfR IdP

  1. The DfR IdP will be used for AuthN for DfR users who
    1. do not have a home institution IdP, and
    2. have registered their username and password directly with DfR
  2. The DfR IdP will sit over the DfR LDAP

DfR LDAP

  1. The DfR LDAP will service requests for
    1. AuthN of DfR users who authenticate via the DfR IdP
    2. AuthZ of all DfR users

Non-browser Clients

  1. Non-browser clients will be provided an access-key and paired secret-key for authN
    • These credentials will be used via basic auth
    • These credentials will be re-generated on demand
    • These credentials will be stored in the DfR LDAP

SI Drupal Integration

  1. The exact integration of SI authN and authZ with the DfR IdP or LDAP is still unknown
  2. There is purported to be a Drupal/Shib module
  3. Discussions with DGI are underway
  4. An Internet2 contact in Colorado who apparently has experience developing Shib integrations with Islandora may also be able to provide some insight
    • Nate Klingenstein: ndk at internet2 dot edu

Fedora Integration

  1. Fedora will integrate with DuraCloud via the application to application pattern (see Non-browser Clients above)

Management Console Integration

  1. The MC will expose a browser-based UI that will be protected as a Shib Service Provider
  2. The MC will also expose a REST-ful API the will be protected via basic auth
  3. The MC will be the primary interface for CRUD operations on the DfR LDAP

DuraCloud Integration

  1. DuraCloud will expose a browser-based UI (Duradmin) that will be protected as a Shib Service Provider
  2. DuraCloud will also expose a REST-ful API (DuraService, DuraStore, DuraBoss, Duradmin/init/security) the will be protected via basic auth
  3. Full discussion of the DuraCloud security integration is detailed below

CAS Integration

  1. An internal CAS server could potentially serve two functions in the DfR context
    1. Be an integration point for institutions with existing CAS AuthN
    2. Be an extension point once DfR wants to support OAuth
  2. In the first case, CAS integration would likely fit under a new or existing Shib IdP
  3. In the second case, CAS integration would likely fit between the DfR IdP and the DfR LDAP

Resources

  1. https://wiki.jasig.org/display/CASUM/Shibboleth-CAS+Integration
  2. https://www.switch.ch/aai/docs/shibboleth/SWITCH/1.1/origin/install-cas.html

LDAP

  1. Goals of DfR LDAP schema
    1. Must support DfR users/accounts/groups/roles
      • Example of existing DuraCloud user/accounts/groups/roles relationship: coming
    2. Must support Spring Security AuthZ
    3. Must support SI AuthN & AuthZ
    4. Should be compatible with Net+ practices
  2. At a rudimentary level, an early DfR LDAP schema has been created and tested with Spring Security AuthZ
    1. This initial testing supports user roles, additional extensions will be needed for account groups
    2. Further detailed here

Resources

  1. http://middleware.internet2.edu/dir/docs/ldap-recipe.htm
  2. http://middleware.internet2.edu/eduperson/
  3. http://www.internet2.edu/middleware/index.cfm

Shib Webserver Authentication

Web applications with browser-based UIs will need to support authentication via Shibboleth.
As a note, application to application and non-browser-based interactions only need to support basic-auth.
At present, the webapps requiring Shib AuthN support are

  1. DuraCloud Duradmin
    • Duradmin only needs Shib AuthN support over the UI paths
      • There are existing non-UI paths in Duradmin that should continue to support basic-auth; namely, /init and /security
      • Spring security can support both pre-authenticated and basic-auth requests
      • Shib AuthN is handled at the Apache2 level, and provides a REMOTE_USER attribute to the webapp
      • Basic Auth can also be handled at the Apache2 level, and presumably configured to provide the REMOTE_USER attribute
      • Alternatively, Spring security can presumablysupport two security filter endpoints which could be applied over UI paths and non-UI paths, respectively
        1. PreAuthenticatedProcessingFilterEntryPoint
        2. AuthenticationProcessingFilterEntryPoint
      • Considerations of AuthN all being handled at the Apache2 level, or split between Apache2 (Shib) and Spring security (basic-auth)
        1. Simplicity of implementation and design
        2. Development environment (can an external contributor build the baseline?)
    • Working code based on DuraCloud svn -r 831 for Spring Security over Duradmin relying completely on pre-authentication is here
    • DuraStore, DuraService, and DuraBoss can still rely on basic-auth
  2. DuraCloud Management Console
    • The MC needs to support both both Shib AuthN for the web-UI and basic-auth for initialization
  3. SI Drupal
    • Shib AuthN is required
    • Initialization process is yet unknown
    • AuthZ needs to be integrated with the DfR LDAP for groups and roles
  4. Fedora
    • AuthN & AuthZ should be unaffected by Shib

Resources

http://wiki.aaf.edu.au/aaf-mini-grants/tpac/shibboleth-integration-with-spring-security