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.edu1Sichuan 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?

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 policy1M. 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)

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 AEF5. 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

Int

erfa

ce

CIMAChannel

(Sink)

Portletcode

User application/portlet

Service main

Plug-inModule

#1

Sensor

CIMAChannel(Source)

Web

Ser

vice

s In

terf

ace

CIMA instrument service

Actuator

Plug-inModule#2, etc.

…

(7) Streaming Data

(6) Response with Data

(3) Request

(5) Sensor Data

Actuatorcommand

(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)

PERMISRoles 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

GridspherePortal

AxisAPI

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