Authorization in a Web Services world (and elsewhere?)

1. Authorization in aWeb Services world(and elsewhere?) Olle Mulmomulmo@pdc.kth.se

2. Authorization Manager • An extensible standalone module for authorization decisions • Written in Java • Policy-based • May be configured with multiple policies • Thus, one AM can service multiple applications • Good or bad? Necessary?

3. Authorization Manager (cont.) • Implemented authorization information repository types: • VOMS • Mappers (userID -> {attribute set}) • Static configuration • File (gridmap, GACL, …) • DB • Regular expressions wrapper • Caching wrapper • … • And / Or / Not wrappers • …

4. Authorization Manager (cont.) • Attribute assertion verification • authorize(credential) -> {attribute set} • authorize(credential, {requested attrs}) -> {approved attrs} • Translation capabilities • Extra step using mappers • Example: mapping VO roles to local unix group names • Repositories can be combined with and/or/not • Possibility for local override is important: • OR(VOMS, gridmap) -> VO + additional users • AND(VOMS, NOT(blacklist)) -> VO - blacklisted users • AND(OR(VOMS, gridmap), NOT(blacklist)) -> confused sysadm

5. Overview

6. Config example • One policy, reading from the gridmap file, no translation<?xml version="1.0" ?><authorizationmanager> <policy name="gridmap" default="true"> <repository type="map" name="ABCD1234"> <map type="file"> <filename>/etc/grid-security/grid-mapfile</filename> <filetype>gridmap</filetype> <refreshperiod>-1</refreshperiod> </map> </repository> </policy></authorizationmanager>

7. Another policy… • Gridmap + additional users<policy name="another"> <repository type="or"> <repository name="ABCD1234" /> <!-- Reuse of config--> <repository type="map"> <map type="table"> <param key="cn=Olle Mulmo,o=KTH,c=SE" value="root" /> </map> </repository> </repository></policy>

8. Servlet & Web Service integration • Thin wrappers around the Authorization Manager for initial course-grained authorization • Servlet filter (HTTP parameters) • Axis handler (SOAP header elements) • SecurityContext allows for late-decision, application-specific, finer-grained authorization, using the same framework. • Conversation-specific • Allowing for next-step stuff

9. WS: So what do I need to do? • Server (Axis): Add the handler in front of the actual service • Add necessary jar files • Modify/add a <requestFlow> for the service (server-config.wsdd)<service name="Example"> <requestFlow> <handler type="java:…SOAPOverHTTPAuthorizationHandler"> <parameter name="authzManagerConfig" value="/some/path/am.xml" /> <parameter name="shortcutOnError" value="true" /> </handler> </requestFlow> ...</service> • shortcutOnError -> do not allow non-authorized users to access the service

10. So what do I need to do? (cont.) • Client (Axis): a couple of SOAP header elements to the request • … in where a particular “role” may be specifiedhttp://soap.edg.org/security/authorization#role • … or use VOMS extensions in your proxy • … or do nothing • For non-modifiable clients, this may be done in the same manner by adding a handler to the request flow • Modify client-config.wsdd

11. But I will never remember this… • Take a look at edg-java-soap-example (CVS) • A simple web service where the server-side is aware of the SecurityContext • Authorization-aware handler invoked on the client-side • Configuration examples • Scripts to run the client and server • For config parameters: JavaDoc • Will try my best to keep the associated Wiki pages updated. • CompleteAXISExample • AuthorizationManagerConfigFile