madrid. oct 8, 2004iadis international conference www/internet 2004 1 access management in federated...

Madrid. Oct 8, 2004 IADIS International Conference WWW/Internet 2004

1

Access Management in Federated Digital Libraries

Kailash Bhoopalam

Kurt Maly

Mohammed Zubair

Ravi Mukkamala

Old Dominion University

Norfolk, Virginia


2

Contents

• The Federated Digital Library1,2

• Distributed Authentication using Shibboleth3

• Architectural Overview for Access Management• End User Access of Archon• Decision Model of XACML4

• Access Control Using XACML• The XACML Policy Editor• Conclusion• Future Work• References


3

Aggregator

Contributor

CERN

Contributor

APS

Subscriber

NSU

Subscriber

IBM

Subscriber

ODU

Archon

Federated Digital Library System

• The Stakeholders– The Aggregator

• Archon (Resource repository, Digital Library, Content Host)

– The Contributors• APS, CERN, etc.

(Content Proprietors who make their content available for a fee.)

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

(Institutional subscribers who buy bulk subscriptions for their employees or members)

– The End-users• Employees or Members of the

subscribing institutions who access the digital library..

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

End - User


4

Federated Digital Library System, Contd. [Problem and Motivation]

• Problem– Subscribing Institutions have an ever changing user community.

Library administrators have to spend a lot of effort keeping the user base current.

– Contributors are usually bound by the uniform access policy of the Library. This prevents small but niche contributors from providing differential and customized access (probably based on a pricing model) to their users.

• Motivation– New and emerging standards address the problem of

• Secure access and transport of user information with low TCO and provision of user privacy.

• Access specification standards and enforcement practices that can be wrapped around legacy applications.


5

Architectural Overview for Access Management

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 Point.1.

2.

3.

a.

b.

c.

S

U

B

S

C

R

I

B

E

R

S


6

Distributed Authentication Using Shibboleth[The Shibboleth Protocol]

1. User accesses Target (Protected Resources) using a web browser.

2. The browser is redirected to the WAYF (a web service.)

3. The WAYF presents the user with a list of home organizations to choose from (This list is a compendium of the all the organizations that the protected resource has agreements with.)

4. User chooses his home organization from the provided list.

5. The user is redirected to the authenticator of his home organization.

6. The authenticator presents the user with a challenge.

7. The user provides his credentials as a response to the challenge.

8. The Authenticator prepares a handle that uniquely identifies the user in its domain space. This handle does not reveal the identity of the user.

9. The target at a later time (typically a few seconds) looks up the handle and requests the authenticator corresponding to the handle to supply more user attributes corresponding to the handle.

10. The Authenticator supplies the requested user attributes.


7

End User Access using Shibboleth [Interaction between Shibboleth, Policy Engine and Archon]

Linux 8 (Apache, Tomcat)

Password based Authentication

Linux 8 (Apache, Tomcat)

Shibboleth requires Apache

Archon requires Apache & Tomcat

ARCHON

TARGE

T

+

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

1- 5 Abstraction of the Shibboleth protocol.

6 User attributes received by the target are submitted to the XACML policy engine (PDP) to evaluate user privileges on the various contents stored in Archon. The privileges are cached in an access token.

7 The access token is used to control user access to the content when the user browses the Archon website.


8

Decision Model of XACML

• 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

Access Policies

{ Environment }

(Timestamp, Source IP, etc)

Request – Domain dependent request format

XReq – XACML complaint request (a.k.a. Request Context)

XRes – XACML compliant response (a.k.a. Response Context)


9

Access Control using XACML[Interaction between the Policy Engine, the Enforcer and Archon]

6. Response Context* [XACML Compliant]

Origin Target PDP ArchonUser

2. User Attribute transfer using Shibboleth [SAML]

3. User Attributes [Request Parameters]

4. Request Context* [XACML Compliant] 5. Decision Evaluation

using XACML*

7. Access Token Generation

8. Access Token Managed User Access

PEP

1. Access Request


10

Access Control using XACML1. User tries to login to the website to access privileged information.2. The target guards the login webpage and initiates the shibboleth handshake. The target receives

the user attributes from the origin after the shibboleth handshake. The attributes are transferred using OpenSAML (an open source implementation of SAML, which is a standard to transport user assertions.)

3. The Policy Enforcement Point (PEP) is invoked by the target and the user attributes are made available to the PEP as request parameters.

4. The PEP constructs XACML compliant request contexts based on the user attributes and its domain knowledge (metadata and services available from each contributor) of the content available in the digital library. Each of these request contexts are submitted to the Policy Decision Point (PDP,) which is a vendor (Sun Microsystems here) supplied XACML decision engine.

5. The PDP evaluates each of the request contexts against access policies, which are stored in a policy repository.

6. The PDP provides a response context for each request context, where each response context encapsulates an access decision for the user on the metadata or a service of the content contributed by a contributor.

7. The PEP parses each of the response contexts and constructs an access token. This access token encapsulates the compendium of user privileges and remains active (alive) during the users session.

8. The access token is used to show (or hide) information as the user browses the Archon website.


11

Differential Access Views in Archon

Access View for Guest Access View for Faculty


12

XACML Policy Editor

Customizable

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.

The Access Matrix is also referred to as the Harrison-Ruzzo-Ullman model. It can be extended to accommodate multiple access permissions and also content and context based permissions.


13

Translation of Access Rules[ GUI to XACML]

XACML Access Rule 1

XACML Access Rule 2

XACML Access Rule 3

XACML Access Rule 0

Access Policy of APS for subscribers from test1.edu

Access Policy of APS for a guest (subscriber independent)

A contributor creates one policy file for each of its subscribers, and one for a guest user.

Each XACML Rule encodes the following

<Subject; Permitted Resource*; Permitted Action>

Example

<[email protected]; APS:title, APS:author...;Read>

http://www.cs.odu.edu/~kbhoopal/xacml/xacml.xml


14

Similar Work

• None that we are aware of that bring multiple technologies (XACML and Shibboleth) for the purpose of access control on Digital Libraries.

• Liberty5 and Advanced Web Services6 (WS-Federation, WS-Policy, etc.) provide a super set of the functionality that Shibboleth provides.


15

Conclusion

• Distributed Authentication at the Authority Sources reduces administrative overhead at the Digital Library.

• Distributed Authentication at the Authority Sources responds more quickly than centralized authentication that may need to get updates at the end of day or weekly.

• Content contributors can define access policies for their content that is hosted by the digital library.

• Initial access latency of the order of only ten seconds.


16

Future Work

• Content based access control• Multi-level access policy definitions, one at the

aggregator level that spans all contributors, and one at the contributor level as it is now.

• Possible extensions to enrich vocabulary for content based access control.

• Cryptographic encryption of access policies.• Separation between domain specific and

application specific Policy Enforcement Points.


17

References

1. Secure Distributed Digital Library Project at Old Dominion University (http://dlib.cs.odu.edu/#sddl)

2. The National Science Digital Library (http://www.nsdl.org/)

3. Shibboleth (http://shibboleth.internet2.edu/)

4. eXtensible Access Control Markup Language (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml)

5. Liberty Project (http://www.projectliberty.org/)

6. Advanced Web Services (http://msdn.microsoft.com/webservices/understanding/advancedwebservices/default.aspx)

http://dlib.cs.odu.edu/#sddl

http://dlib.cs.odu.edu/#sddl

http://shibboleth.internet2.edu/

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

http://www.projectliberty.org/



madrid. oct 8, 2004iadis international conference www/internet 2004 1 access management in federated...

Documents

access policies

customized access

gains access

uniform access policy

problem of secure access

access control specifications

access specification

policy xacml