A PERMIS-based Authorization Solution between Portlets and Back-end Web Services

1. A PERMIS-based Authorization Solution between Portlets and Back-end Web Services Hao Yin1, Sofia Brenes-Barahona2, Donald F. McMullen*2, Marlon Pierce2, Kianosh Huffman2, Geoffrey Fox2 {hayin, sbrenesb, mcmullen, marpierc, kihuffma, gcf}@indiana.edu 1Sichuan University; 2Indiana University *presenterGCE06, at SC06, Tampa, FL November 12-13, 2006

2. Background • Portals are useful for organizing access to data and computational services used by research virtual organizations • Portlets increasingly use back-end Web Services to provide content • How should services authorize portlet accesses?

3. Motivation • Portal policy decisions are scoped to the portal only, not to back-end services • Services that provide content for portlets need access control that will work with portals from multiple administrative domains • Users have a portal identity, but more naturally relate to services through roles (complexity problem) • Service providers may not want to share an authentication DB, but could define a set of roles that users have with respect to the service.

4. Authorization mechanisms • Access control list (ACL) • Attribute-based access control • Capability-based access control • Role-based access control (RBAC) • Implementations • Virtual Organization Membership System (VOMS) • Community Authorization Services (CAS) • Shibboleth (with appropriate PDP implementation) • Privilege and Role Management Infrastructure Standards (PERMIS)

5. Terminology • Privilege Management Infrastructure (PMI) • X.509 certificates used to convey privilege information • Attribute certificates (AC) • Policy Decision Point (PDP) • Accepts or rejects authorization assertions based on a given policy • Authorization Enforcement Function (AEF)1 • Formulates an authorization query and passes it to an ADF • Forwards or rejects request based on ADF answer • Authorization Decision Function (ADF)1 • Checks authorization query against policy DB • Returns status indicating compliance with policy 1M. Lorch et al., "Conceptual Grid Authorization Framework and Classification,” GGF GFD-I.038. http://www.ggf.org/documents/GFD.38.pdf.

6. PERMIS: RBAC authorization • PrivilEge and Role Management Infrastructure Standards (David Chadwick, University of Salford, UK, www.permis.org) EU Framework project to develop widely usable authentication and authorization infrastructure for services • Both client (portal) and service side use Axis Handlers to deal with security information: • portal side handler adds a SAML authentication token based on user’s ID into SOAP header; • service side handler extract token from SOAP header to get the user identity and determine user’s roles. • Policy DB consists of two components: • user->role (dynamic, negotiated between user and provider) • role->service action mappings (relatively static, defined by provider)

7. Authorization process for a Web Services client User authenticates to portal then invokes Web Service through a portlet. Handler embeds signed user ID in SOAP header. AEF constructs (subject, action, target) tuple and sends to ADF. ADF verifies role of subject on target using subject-role DB and roles permitted on the target from Policy DB ADF returns grant/deny to AEF AEF forwards message to service or returns SOAP fault

8. PERMIS in context

9. Axis Handler chains for PERMIS Request Handler chain on the portal side Request Handler in the Axis service container processes the SAML assertions in the SOAP header to extract the portal user’s identity. This identity is then mapped to a role and the role, action, target checked against policy

10. Application example: sharing instruments in a lab federation • Common Instrument Middleware Architecture (CIMA) provides instruments and sensors as network services via Web Services • One application is a federation of X-ray crystallography labs • Portal organizes lab federation and portlets access shared instruments and data • Need access control mechanism for CIMA services • RBAC is a good choice from an instrument owner’s point of view

11. CIMA instrument service User application/portlet (1) Session Request Service main (2) Session token … Portlet code CIMA Channel(Sink) Web Services Interface (3) Request CIMAChannel(Source) (6) Response with Data Plug-inModule #1 Plug-inModule #2, etc. WS Interface (4) (7) Streaming Data Sensor Actuator (5) Sensor Data Actuatorcommand CIMA Instrument/Sensor services and clients Places where PERMIS can be used for authorizing portlet access

12. Configuring PERMIS • object ID, which acts as a handle, or name, for the policy instance; • Source of Authority (SOA), a signing certificate for all role and target certificates; • roles, which are specified with X.509 certificates; • targets, which are X.500 DNs of the service names signed by the SOA certificate; • actions, which are methods of the Web service that can be invoked; and • privilege allocation, i.e. which roles can do specific actions on a specific target. • Tools are available for generating databases

13. Using PERMIS • Start with an existing Web Service and portlet that retrieves its content from this service • Set up database of users and roles • Set up a policy data base of roles and permissions • Change client code to add user ID to SOAP header as SAML assertion (~3 lines of code) • Provide an Authorization Decision Function if default one is not adequate • Provide an Authorization Enforcement Function as an Axis Handler • default is OK, but must be added to handler chain through the WSDD or programmatically when service is started.

14. CIMA service Portlet client PERMISRoles and Permissions DB Encryption Handler (WSS4J) Encryption Handler (WSS4J) Network Signature Handler (WSS4J) Signature Handler (WSS4J) PERMIS ADF PERMIS AEF Assertion Handler (OpenSAML) Apache Axis 1.x AxisAPI CIMA Channel Service (WS) Gridsphere Portal Using PERMIS to authorize portlet access to a shared CIMA instrument resource Portlet with CIMA Channel Sink Instrument data to portlet client Shared Instrument User

15. PERMIS-based authorization of a portlet to an instrument service. User identity is from portal log-in. Users are assigned roles of “can-register” and “can’t-register” with the service. 1. User0 has rights to register with the service, so SOAP message is forwarded to the service. 2. User 1 does not. Message is rejected with a SOAP Fault.

16. Conclusions and future work • Access control of portlets to content services by authentication using a single “universal” credential is not a good approach (at least from a service provider’s POV) • Roles are a useful way for service providers to classify users and control access to services (e.g. instruments and sensors) • PERMIS bridges the gap between user identity and permissions in a portal context, and user rights on external services through role-based authorization • Future work • Tools for community management of rights • GAMA 2.0 plug-in for assigning and managing PERMIS roles and permissions in a portal • Integration with Shibboleth for federated identity management in instrument-sharing VOs

17. Thank you! Questions? Thanks to Marlon Pierce and the OGCE group. The following support for this work is gratefully acknowledged: National Science Foundation Information Technology Research and Middleware Initiative programs (ITR-0428774, ITR-0427264, ITR-0426867 Vlab, SCI 0330613 and SCI 0330568) and Professor Jiliu Zhou, School of Computer Science, Sichuan University, China (for supporting H.Y.) mcmullen@indiana.edu

18. Backup slides

19. Authorization for Portlets using Web Services • Motivating application: portal and portlets for interacting with instruments and data across a group of laboratories • General approach: RBAC, using SAML assertions about user roles in WS calls • Role-based authorization through PERMIS