Components
DfR IdP
- The DfR IdP will be used for AuthN for DfR users who
- do not have a home institution IdP, and
- have registered their username and password directly with DfR
- The DfR IdP will sit over the DfR LDAP
DfR LDAP
- The DfR LDAP will service requests for
- AuthN of DfR users who authenticate via the DfR IdP
- AuthZ of all DfR users
Non-browser Clients
- 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
- The exact integration of SI authN and authZ with the DfR IdP or LDAP is still unknown
- There is purported to be a Drupal/Shib module
- Discussions with DGI are underway
- 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
- Fedora will integrate with DuraCloud via the application to application pattern (see Non-browser Clients above)
Management Console Integration
- The MC will expose a browser-based UI that will be protected as a Shib Service Provider
- The MC will also expose a REST-ful API the will be protected via basic auth
- The MC will be the primary interface for CRUD operations on the DfR LDAP
DuraCloud Integration
- DuraCloud will expose a browser-based UI (Duradmin) that will be protected as a Shib Service Provider
- DuraCloud will also expose a REST-ful API (DuraService, DuraStore, DuraBoss, Duradmin/init/security) the will be protected via basic auth
- Full discussion of the DuraCloud security integration is detailed below
CAS Integration
- An internal CAS server could potentially serve two functions in the DfR context
- Be an integration point for institutions with existing CAS AuthN
- Be an extension point once DfR wants to support OAuth
- In the first case, CAS integration would likely fit under a new or existing Shib IdP
- In the second case, CAS integration would likely fit between the DfR IdP and the DfR LDAP
Resources
- https://wiki.jasig.org/display/CASUM/Shibboleth-CAS+Integration
- https://www.switch.ch/aai/docs/shibboleth/SWITCH/1.1/origin/install-cas.html
LDAP
- Goals of DfR LDAP schema
- Must support DfR users/accounts/groups/roles
- Example of existing DuraCloud user/accounts/groups/roles relationship: coming
- Must support Spring Security AuthZ
- Must support SI AuthN & AuthZ
- Should be compatible with Net+ practices
- Must support DfR users/accounts/groups/roles
- At a rudimentary level, an early DfR LDAP schema has been created and tested with Spring Security AuthZ
- This initial testing supports user roles, additional extensions will be needed for account groups
- Further detailed here
Resources
- http://middleware.internet2.edu/dir/docs/ldap-recipe.htm
- http://middleware.internet2.edu/eduperson/
- 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
- 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
- PreAuthenticatedProcessingFilterEntryPoint
- AuthenticationProcessingFilterEntryPoint
- Considerations of AuthN all being handled at the Apache2 level, or split between Apache2 (Shib) and Spring security (basic-auth)
- Simplicity of implementation and design
- 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
- Duradmin only needs Shib AuthN support over the UI paths
- DuraCloud Management Console
- The MC needs to support both both Shib AuthN for the web-UI and basic-auth for initialization
- SI Drupal
- Shib AuthN is required
- Initialization process is yet unknown
- AuthZ needs to be integrated with the DfR LDAP for groups and roles
- Fedora
- AuthN & AuthZ should be unaffected by Shib
Resources
http://wiki.aaf.edu.au/aaf-mini-grants/tpac/shibboleth-integration-with-spring-security