A PERMIS-based Authorization Solution between Portlets and Back-end Web Services Hao Yin 1, Sofia Brenes-Barahona 2, Donald F. McMullen * 2, Marlon Pierce 2, Kianosh Huffman 2, Geoffrey Fox 2 {hayin, sbrenesb, mcmullen, marpierc, kihuffma, 1 Sichuan University; 2 Indiana University *presenter GCE06, at SC06, Tampa, FL November 12-13, 2006

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?

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.

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)

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 1 M. Lorch et al., "Conceptual Grid Authorization Framework and Classification,” GGF GFD-I

PERMIS: RBAC authorization PrivilEge and Role Management Infrastructure Standards (David Chadwick, University of Salford, UK, 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)

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

PERMIS in context

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

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

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

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

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.

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

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.

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

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 , ITR , ITR Vlab, SCI and SCI ) and Professor Jiliu Zhou, School of Computer Science, Sichuan University, China (for supporting H.Y.)

Backup slides

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