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 *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? Authorization can be done through the portal’s login mechanism. Given a portal user identity

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 is not sufficient if only one credential is used, and complex if each user supplies a personal credential

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 1M. Lorch et al., "Conceptual Grid Authorization Framework and Classification,” GGF GFD-I.038. http://www.ggf.org/documents/GFD.38.pdf.

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) Both client(portal) and service side use handler to deal with security information. Handler on portal side embeds the SAML Authentication token into SOAP header; handler on service side extract it from SOAP header to get the user identity.

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 1. SAML assertion about user’s identity added to SOAP header by handler 2. Handler validates signature and constructs authorization request with subject, action and target=user, SOAP action, and web services 3. Request is checked by Authorization Decision Function (ADF)ADF returns authorization decision and call is forwarded to Web Service or rejected with a SOAP fault.

PERMIS in context Portal system is Gridsphere JSR 168 compliant container 2. Use Axis 1.x Handlers to add and remove assertions 2. Assertion handler is Open SAML 3. Signature and encryption through WSS4J 4. PERMIS is used as the

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 The PERMIS API takes charge of the mapping between user identity and a role. Handler on service side provides 3 parameters to PERMIS API: user identity as subject in X.500 DN format;Web service method name as action; Web service as target in X.500 DN format. PERMIS API makes the decision using the information stored in LDAP. Firstly, getting the role assigned to the user by his or her X.509 certificate; then verifying the AuthZ policy stored in SOA's X.509 certificate.

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 Data from remote lab’s instruments and sensors are meant to be presented in portlets.

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 #2, etc. … (7) Streaming Data (6) Response with Data (3) Request (5) Sensor Data Actuator command (4) (2) Session token (1) Session Request Common Instrument Middleware Architecture (CIMA) aims at Grid-enabling instruments and sensors Clients interact with a CIMA service through Web Services, and the CIMA service streams data to a client’s WS endpoint Gridsphere is used to build user interfaces for CIMA instruments and related data management services Portlets retrieve instrument data content via Web Services 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 Targets are Web service name in X.500 DN format stored in a XML-based policy in the SOA's certificate.Only users and SOA have certificates.

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.

authorize portlet access to a shared CIMA instrument resource Portlet client CIMA service PERMIS Roles and Permissions DB Encryption Handler (WSS4J) Encryption Handler (WSS4J) Network Signature Handler (WSS4J) Signature Handler (WSS4J) PERMIS ADF Assertion Handler (OpenSAML) PERMIS AEF Apache Axis 1.x Axis API 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 CIMA client must request a session key to use the shared instrument In the prototype the Web Services entry point for requesting a session key was wrapped in a PERMIS Authorization Enforcement Function such that only users with the appropriate role in the permission database are allowed to use the instrument remotely.If the ADF rejects the message a SOAP FAULT and appropriate error text is returned to the client, otherwise the message is delivered to the service. Shared Instrument User

PERMIS-based authorization of a portlet to an instrument service 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-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

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