Hydra Auth and Fedora Auth

Hydra Partners Meeting at Notre Dame
Monday, 4 PM -- September 10, 2012

Topic: Authz / Authn and Hydra, specifically...
1.) ensuring a complementary approach in managing Hydra & Fedora
2.) review of Hydra's authz strategies, patterns, toollng

Notes

1.) ensuring a complementary approach in managing Hydra & Fedora...
- If one uses only Fedora Authz, you get no gated discovery
- If one uses only Hydra Authz, you get no repository-level access control (and no policy enforcement for access from other systems)

Note: there is a pattern here of not enforcing authz on the data store, but rather at the app layer. c.f. mysql

Most (a majority of...) institutions here need access control to repository objects from other points of access than Hydra apps.

If you go this route then, maybe authz should be presented via a set of services that sit outside of Fedora. Could you do this as a servlet filter against Fedora or Hydra? This is akin to what Stanford does with its PURL services (export rightsMD into a document cache, have authorization services hit this servlet), protecting externally managed content.

Not being tied to Fedora would have the advantage of potentialy being simpler, not being connected to Fedora and accessible for gated discovery.

2nd round of FESL was
- define a vocabulary for access control
- define an API for setting these
- build a UI for making these changes...

Hydra has provided all 3 of these aspects, and solved all the FESL needs, but...
- not at the repository level
- only for Hydra apps. Is Hylandora a path for generalizing?

changing stuff in Fedora is Hard.
changing stuff in Hydra is easy.

<Ben at the Board>

Different paths

1. Secured FCRepo / ServiceAccount. All access to Fedora content is through this service.
Advantages: get gated discovery
Disadvantages: limits API's to Repo to only go through this application

2. Yet to be Developed, Free Standing Authorization Decision Point (not core to Hydra, but compatible with)

Advantages:
A. Hypothetically supports gated discovery
B. Minimizes FC Repo dependency
C. Programmatic non-hydra access
D. More personnel flexibility in coding it (don't need Java/XACML experts per se)
Disadvantages:
A. Needs to be written
B. Hard
C. Scary

3. FCRepo act on community AuthZ instruction (rightsMetadata)

Advantages:
A. Policy consistency across apps
B. Durability of approach
C. Potential use outside Hydra community
Disadvantages:
A. Doesn't exist
B. Small pool of potential developers

Steve Bayliss says #3 is easy as pie. Steve Didomenico says he's tried referencing external files in XACML policies, and has encountered 401 errors (= access denied)

Proposal:
- do this as a 1 hour hackfest to prototype solution
- vet this against UVa and Hull use cases

if it doesn't work after an hour, then assess its potential as a Managed Project.

<segue> --> what about access control to external content exposed via external services, like streaming media.

Topic 2. Review of Hydra's authz Patterns & Tools

Issues:
Securing external content through [djatoka, streaming server, apache, geoservices, etc.]

Policy vs. Collection-aware Authz
Policy vs. collections
>1 Policy per Object?
Cascading Permissions: Contraint vs. Grant
Context-based Authorization
UI to manage policies
Granting access to part of an object--a datastream, or part of a datastream
Authz for parts of objects
Time-based restrictions (during only a semester, or embargo...)

(At least...) two big patterns:
- access managed by reference (in an APO). (Make sure that access is grant only, not constraints... fewer chances to have conflicting policies...)
- vs.
- access managed by rightsMetadata in each object

What are the implications for the code...

Separating APO's vs. intellectual arrangement = a fundamental pattern (?) with broad adoption