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,
1Sichuan University; 2Indiana University
*presenter GCE06, 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?
Authorization can be done through the portal’s login mechanism. Given a portal user identity

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

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

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

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

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

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

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

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

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

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

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

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

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