Access Management in Federated Digital Libraries

Kailash Bhoopalam

Kurt Maly

Mohammed Zubair

Ravi Mukkamala

Old Dominion University

Norfolk, Virginia

Contents

• The Federated Digital Library

• Distributed Authentication using Shibboleth

• Role – Based Access Control

• Access Control Using XACML

• The XACML Policy Editor

• Conclusion

Aggregator

Contributor

CERN

Contributor

APS

Subscriber

NSU

Subscriber

IBM

Subscriber

ODU

Archon

Federated Digital Library System• The Stakeholders

– The Aggregator• Archon

(resource repository)

– The Contributors• APS, CERN, etc.

– The Subscribers• ODU, IBM, NSU, etc.

– The End-users• Members of the subscribing

institutions who access the resource.

Contributor-Subscriber Information Access AgreementContributor-Aggregator Information Publishing AgreementAggregator enables Contributor-Subscriber Information Access Agreement

End - User

The Federated Digital Library

1. User request’s resource protected by Shibboleth

2. Target and User’s home organization authenticate each other and the home organization provides user attributes

3. End-User gains access to resource based on access control specifications provided in the policy (XACML)

Contributors

Aggregator

Shibboleth Target

Federated DL & Harvester

Policy Enforcement Point

PDPPolicy Editor

Reg.

Shibboleth Origin (IBM)[Admin classifies users into groups]

Shibboleth Origin (ODU)

Shibboleth Origin (NSU)

[ODU Users, IBM Users, NSU Users]

End-Users

xArchiveCERNAPS

a. Contributor registers with Federated Digital Library

b. Contributor manages access policies for user access to its documents

c. Provides policy in XACML compliant format to the Policy Decision Point1.

2.

3.

a.

b.

c.

S

U

B

S

C

R

I

B

E

R

S

End User AccessArchon, XACML and Shibboleth

Linux 8 (Apache, Tomcat)

Password based AuthenticationLinux 8 (Apache, Tomcat)

Shibboleth requires Apache Archon requires Apache & Tomcat

ARCHON

TARGET

+

XACML

ORIGIN

1. Access

2. Authentication Redirect

3. Opaque handle

4. Attribute Request, Opaque handle

5. User Attributes

6. Access Token using XACML

7. Token based access

SubscriberAggregator

End-User

Distributed Authentication Using Shibboleth

XACML’s Decision Model• Semantics of an XACML policy

– PolicySet Policy+

– Policy (Rule+, PA*)

– Rule (Subject*, Object*, Action, Condition*)

• Semantics of a request to an XACML policy– Request (Subject*, Object, Action)

• Semantics of a response after access evaluation– Response (Status, Decision, Obligation*)

• Status {OK, Error}

• Decision {Permit, Deny, Not Applicable}

• Conflict resolution– Deny overrides, Permit overrides, First deny, First permit.

Engine

(PDP)

Enforcer

(PEP)

Resource

Request Access

XReq

XRes

Policy

Environment

(Timestamp, Source IP)

Access Control using XACML

Response Context* [XACML Compliant]

Origin Target PDP ArchonUser

User Attribute transfer using Shibboleth [SAML]

User Attributes [Request Parameters]

Request Context* [XACML Compliant] Decision Evaluation

using XACML*

Access Token Generation

Access Token Managed User Access

PEP

Authorization in Archon using XACML

Access Request

Information

Differential Access Views in Archon using XACML

Access View for Student Access View for Faculty

XACML Policy EditorCustomizable

The content administrators of the contributors are shown information (resources in the columns and the roles in the top row based on the contractual agreements the contributor has with each subscriber.

 Consistent Access Rules

It is impossible to create access rules where a “subject” is provided access to a “resource” in one rule and denied in another.

Sample XACML Policy

Conclusion