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 Agreement Contributor-Aggregator Information Publishing Agreement Aggregator 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 PDP Policy 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 a.a. b.b. c.c. SUBSCRIBERSSUBSCRIBERS

End User Access Archon, XACML and Shibboleth Linux 8 (Apache, Tomcat) Password based Authentication Linux 8 (Apache, Tomcat) Shibboleth requires Apache Archon requires Apache & Tomcat ARCHONARCHON TARGET+XACMLTARGET+XACML ORIGINORIGIN 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 Subscriber Aggregator 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) ResourceResource RequestAccess XReq XRes Policy Environment (Timestamp, Source IP)

Access Control using XACML Response Context* [XACML Compliant] OriginTargetPDP 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 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.

Sample XACML Policy

Conclusion