© Fraunhofer IAO, IAT Universität Stuttgart Message based propagation of changes in VO membership in a Grid environment Change Propagation in a heterogeneous Application Landscape Cracow Grid Workshop 2009 Oliver Strauss Fraunhofer IAO, Stuttgart, Germany Cracow, October 13 th 2009

© Fraunhofer IAO, IAT Universität Stuttgart Slide 2 Outline Background and motivation Overview and architecture Example Conclusion

© Fraunhofer IAO, IAT Universität Stuttgart Slide 3 GNS Systems (Provider of numerical services) Background: PartnerGrid Goal: Usage of Grid in a commercial environment Scenario: Portal based collaboration between a provider of crash simulations and its customers RCE GNS-Customer Grid GI A RCE Engineer RCE Engineer... Consultant Animator Generator INDEED Portal

© Fraunhofer IAO, IAT Universität Stuttgart Slide 4 Problem: Keep the Grid in sync with the VO Scenario: A new user enters the VO Accounts have to be created Roles in different systems have to be assigned Access rights have to be set Shell scripts work well for most tasks PartnerGrid VOMRS VO-Representative (potential) VO-Members approvesregister Data management accounts + rights WebDAV access rigths Grid resources affects D-Gridmap Web portal accounts, roles, rights Whitelist What if we want to have a whitelist of grid users or other sources of change that affect the Grid configuration?

© Fraunhofer IAO, IAT Universität Stuttgart Slide 5 Problem: Keep the Grid in sync with the VO Scenario: A new user enters the VO Accounts have to be created Roles in different systems have to be assigned Access rights have to be set Shell scripts work well for most tasks PartnerGrid VOMRS VO-Representative (potential) VO-Members approvesregister Data management accounts + rights WebDAV access rigths Grid resources affects D-Gridmap Web portal accounts, roles, rights Whitelist What if we want to have a whitelist of grid users or other sources of change that affect the Grid configuration? Idea: Why not take an event based approach and use messaging to propagate changes? Change manager

© Fraunhofer IAO, IAT Universität Stuttgart Slide 6 Architecture: Message based change propagation Source of change grid-mapfile Change adapter Target of change Liferay Portal Change adapter Target of change WebDAV Change adapter Message queue server Change Manager (Rule engine) Incoming queue: Changes Data processing and enhancement Message routing Outgoing queue: Liferay Outgoing queue: WebDAV Rules 7 Trigger 06 gridmap DN Username VO Roles gridmap DN Username VO Roles Apache Username Generated PW Liferay DN Username Organisation Portal Roles Add. queues: Logging Errors Mail etc… Tools … ack

© Fraunhofer IAO, IAT Universität Stuttgart Slide 7 Adapters Adapters have to be provided for each system Inside the target system (e.g. as a Liferay Portlet) Acting from the outside (e.g. via an API, WebServices, shell scripts) Adapter have very limited responsibilities Source adapters Detect and submit changes to a message queue Target adapters Receive from a message queue and execute changes Acknowledge success or report error Optionally submit logging information Adapters can be implemented in any language for which a Stomp client is available (e.g. Java, Ruby, Python, …)

© Fraunhofer IAO, IAT Universität Stuttgart Slide 8 Change Manager The Change Manager receives requests on the “Incoming“ queue feeds the change messages to the rule engine Data normalization and enhancement Lookup in external directories (e.g. LDAP) Blacklists and whitelists Send processed change request to output queue of the target system Prototype implemented based on Stompserver (Ruby) message queue Rule engine (Rools)

© Fraunhofer IAO, IAT Universität Stuttgart Slide 9 Example rules # Receive original message and insert a GridmapChange object in the rule engine rule 'receiveGridmapChange' do parameter Message, :source, :body, :change_type condition { msg.source == "gridmap" } consequence { assert GridmapChange.new( msg.body, msg.source, msg.change_type ) } end # On GridmapChange objects with organisation “IAO” change organization to # “Fraunhofer IAO” rule 'normalizeO' do parameter GridmapChange, :o condition { change.o == "IAO" } consequence { change.o = "Fraunhofer IAO" } end # Send every GridmapChange object with change_type “add” to the target rule 'addLiferayUser' do parameter GridmapChange, :change_type condition { change.change_type == "add" } consequence { send_add_liferay_user( change, ) } end

© Fraunhofer IAO, IAT Universität Stuttgart Slide 10 Discussion and future work Advantages Decoupling of change detection, data manipulation and change execution facilitates reuse Modular system with explicit rule based logic provides good flexibility Centralized logging (audit trail) Easier maintenance and better extensibility expected Easy integration with other tools like e.g. LDAP Possible disadvantages Introduction of a single point of failure More complexity, one more server, more things that can go wrong Security is crucial, since much harm can be done by injecting malicious messages Future work Further test practicability in the PartnerGrid scenario Improve security (transfer via HTTPS, encryption and signing of messages)

© Fraunhofer IAO, IAT Universität Stuttgart Slide 11 Contact Fraunhofer-Institute for Industrial Engineering (IAO) Oliver Strauss Research Assistant / Software Technology Mail: Web:

© Fraunhofer IAO, IAT Universität Stuttgart Slide 12 User, Role and Access Rights Management in PartnerGrid PartnerGrid VOMRS VO-Representative VO-Members (Customers, Engineers, Project Managers, etc.) Approval Registration D-Gridmap creates PartnerGrid Role and Rights Management loads Interpretation of D-Grid UserID Username (CN) Organisation (OU) Roles (VOMRS Attributes) RCE Data Management User, Rolls and Access Rights PG WebDAV Server User, Rolls and Access Rights PG Portal User, Rolls and Access Rights Customer Data Upload via WebDAV Client (e.g. Windows Explorer) Project Handling and Management via Browser Engineer sets integrates reads PG Resources User, Roles and Access Rights sets Resource Access Project Manager