VOMRS Technical Overview John Weigand

VOMRSTechnicalOverviewJohn Weigand VOMRS Technical Overview

VOMRS Technical Overview • VOMRS Architecture • VOMRS database • Testing • Open Issues VOMRS Technical Overview

VOMRS Architecture • Access (Client / Web) CLI GSI authentication (Java Cog Kit) SOAP/SSL authentication (EDG Trust Manager) Java Web UI HTTP/SSL authentication (EDG Trust Manager) Java / Java script VOMRS Admin Java / Axis / Tomcat WEB service • VOMRS Server (Multi-threaded daemon process) : Client Manager Handles remote client request to perform VO membership service Event /Manager Handles member event and interface notifications Interface Manager Handles interface notifications VOMS Synchronizer Synchronizes VOMS with VOMRS database • ServiceBroker / Services Authorization Business Logic VOMRS Technical Overview

VOMRS ArchitectureWeb Access • Two ways of accessing the VOMRS besides VOMRS client: • web UI (HTTP+SSL authentication) http://computing.fnal.gov/docs/products/vomrs/#manual. • web services (SOAP+SSL authentication) https://vomrs_host:8443/vo-<VO_NAME>/services/VOMRS?wsdl • All access methods utilize the same implementation of the business logic. • Authentication provided by the EDG Trust Manager (http://edg-wp2.web.cern.ch/edg-wp2/security) • WEB UI behavior controlled by configuration file parameters: • The duration of the session • The name of organization that oversees all grid resources for a particular VO • The url location of usage rules for this organization Configuration file entries: <web>  <log>VOMRS_DIR/var/etc/vomrs_VO_NAME_CNVRT/log4j_webui.properties</log>   <gridResourceName>LCG</gridResourceName>  <gridUsageRules>https://edms.cern.ch/file/428036/LAST_RELEASED/LCG_Usage_Rules.pdf</gridUsageRules> </web> VOMRS Technical Overview

VOMRS Architecture Client / Server Access • ClientManager is a thread listening for connection from remote clients • When connection is established, a Client Manager starts a temporary new thread (ClientIF) • authenticates a client by using GSI authentication mechanism • execute the requested VO membership services • returns information regarding the success or failure of a requested service as well as the execution result of this service if any • Thread will be stopped either when • client closes the connection or • the allowed connection time is expired whichever comes first. • The allowed connection time can be set up in configuration. Configuration file entries: <client> <!—change to on to enable remote client access, client should use VOMRS API and GSI authentication  <status>off</status> <port>14000</port> <!—allowed connection interval in minutes  <connectionTime>10</connectionTime> </client> VOMRS Technical Overview

VOMRS Architecture Service Broker / Services • All 3 access methods utilize a common ServiceBroker and a common set of Services. • All use the same business logic to satisfy a requested service. • Services define: • The action performed within VOMRS database • Administrative roles authorized to perform this action • List of input and output arguments Service Arguments Return Values Authorized Roles ----------------- ------------ ------------- ------------------------ GetGroupOwners GROUP DN,CA Visitor,Applicant,Member AddGroupOwner DN,CA,GROUP NULL GroupOwner,VOAdmin RemoveGroupOwner DN,CA,GROUP NULL GroupOwner,VOAdmin GetLRPs INSTITUTION DN,CA Visitor,Applicant,Member AddLRP DN,CA NULL SiteAdmin,VOAdmin RemoveLRP DN,CA NULL SiteAdmin,VOAdmin • Authorization restrictions: • Basic is based on role and arguments implemented in the ServiceBroker • Additional restrictions on some implemented in the Services code. (e.g. – AddLRP by SiteAdmin can only be performed on entities associated with his site, while VOAdmin can perform this for any site.) VOMRS Technical Overview

VOMRS Architecture Service Broker / Services Service Arguments Return Values Authorized Roles ----------------- ------------ ------------- ------------------------ GetGroupOwners GROUP DN,CA Visitor,Applicant,Member AddGroupOwner DN,CA,GROUP NULL GroupOwner,VOAdmin RemoveGroupOwner DN,CA,GROUP NULL GroupOwner,VOAdmin GetLRPs INSTITUTION DN,CA Visitor,Applicant,Member AddLRP DN,CA NULL SiteAdmin,VOAdmin RemoveLRP DN,CA NULL SiteAdmin,VOAdmin • ServiceBroker performs: • Service availability • Service authorization based on role and arguments • Execution of the authorized service • Return data/success/failure of the service to the requestor. VOMRS Technical Overview

VOMRS Architecture Event Manager • Thread of the VOMRS Server that processes all the notification events stored in VOMRS database. • Frequency controlled by the VOMRS configuration file. • Performs the following tasks: • Checks database for any event that is ready to be processed • Determines current subscribers to this event • Formats and sends e-mail notification • Updates database with the outcome of event processing and notification (“Completed”/”Failed”) Configuration file entries:  <eventProcessor> <!—change to off to disable event processing <status>on</status> <!—command use to send mail  <mailCommand>/usr/sbin/sendmail</mailCommand>  <url>https://hotdog62.fnal.gov:8443/vo-VO_NAME/services/VOMRS?</url> <from>vomrs-VO_NAME_CNVRT-admin</from> <!—update period in minutes  <updateTime>2</updateTime> </eventProcessor> VOMRS Technical Overview

VOMRS Architecture Interface Manager • Incomplete at this time. VOMS in the only interface support and it is done via the VOMS Synchronizer • Thread of the VOMRS Server that processes all the events that are relevant to a particular interface • Frequency will be controlled by the VOMRS configuration file. • Will performs the following tasks: • Checks database for any interface event that is ready to be processed • Determines current interface subscribers to the event • Formats event and contacts a subscribed interface by using appropriate API • Updates database with the outcome of event processing and notification (“Completed”/”Failed”) • Only an interface to VOMS Admin is currently implemented VOMRS Technical Overview

VOMRS Architecture VOMS Synchronizer • Thread of the VOMRS Server that transfers information from the VOMRS database to the VOMS database using EDG VOMS Admin API. • Behavior is controlled by the VOMRS configuration • Two (2) modes of operations: • event driven mode - level 4 - using the Interface Manager to handle each event relevant to VOMS (subscribed by VOMS interface). • Synchronization mode - The other mode allows a Synchronizer to synchronize the VOMRS and VOMS databases. • Four (4) levels of synchronization: • Level 0 - Addition of all “approved” VOMRS members to a root group of the VOMS database • Level 1 - Addition of all “approved” VOMRS members to a root group and deletion of all “suspended” VOMRS members from the of VOMS database • Level 2 - Synchronization of all members. Includes deletion of all members that are listed in the VOMS database but do not exist in the VOMRS database. • Level 3 - Complete synchronization. Includes synchronization of groups and roles, member assignment to the subgroups and member role within subgroups. VOMRS Technical Overview

VOMRS Architecture VOMS Synchronizer Configuration file entries:  <synchronizer> <!—change to on to enable syncronization, will use VOMS API and SOAP/SSL authentication  <status>off</status>   <vomsUrl>https://VOMS_hostname:8443/edg-voms-admin/VOMS_VO_NAME/services/VOMSAdmin</vomsUrl>     </synchronizer> VOMRS Technical Overview

VOMRS Database • Currently MySql with intent to support Oracle. • 3 categories of tables: • Core tables • contain the basic updatable VO membership data • Code related tables • Tightly coupled with the application’s code • Only modified in conjunction with the code • Not updated with available VOMRS services • Log tables • Basically log ‘files’ in table form documenting changes in a member’s registration status and roles. • Events/subscriptions/notifications for members and system Interfaces • ‘Code related’ and ‘Log’ tables used to support: • Concept of Services • Event (member and interface) notifications • It is an attempt to reduce the amount of ‘hard-coding’ that would have otherwise been required. VOMRS Technical Overview

VOMRS Database ERD Code related tables Core tables Log tables Disclaimer: The above ER diagram was created using the Oracle Designer tool. It does not include all the data relationships present in the VOMRS database, but only the most relevant. This is a variation from the normal use of this tool and was done so intentionally to simplify the diagram. Since this was originally designed for use in a MySql DBMS, the foreign key relationships are in the software rather than the DDL. VOMRS Technical Overview

VOMRS DatabaseVO Membership Data(Core Tables) • Registration Status • Within VO (New, Approved, Denied, Suspended, Revoked) • By site (New, Approved, Denied) • By local resource provider (New, Approved, Denied) • Personal Data • Configurable by VO • Private and public data • Multiple DN/CA per member • Roles • Visitor, Applicant, Member, Group Manager, Group Owner, Site Administrator, Local Resource Provider (LRP), VO Administrator • Grid/Group roles (no validation at this time, just repository) • Groups • Modifiable by VO • Can assign roles for specific groups (both admin and grid roles) VOMRS Technical Overview

VOMRS DatabaseServices(Code Related Tables) • Defines the authorized functions that can be performed by a VO member in the VOMRS database. • Tables • Services table Defines the service, required arguments and return_values • Service_roles table Defines the VO member administrative roles that can perform the service Service Arguments Return Values Authorized Roles ----------------- ------------ ------------- ------------------------ GetGroupOwners GROUP DN,CA Visitor,Applicant,Member AddGroupOwner DN,CA,GROUP NULL GroupOwner,VOAdmin RemoveGroupOwner DN,CA,GROUP NULL GroupOwner,VOAdmin GetLRPs INSTITUTION DN,CA Visitor,Applicant,Member AddLRP DN,CA NULL SiteAdmin,VOAdmin RemoveLRP DN,CA NULL SiteAdmin,VOAdmin • Tight coupling of code and tables • Member role dictates menus presented in the web interface • Service, arguments and roles used in determining if member is authorized to perform the service. (the authorization issue is in not knowing the user’s intended role) VOMRS Technical Overview

VOMRS DatabaseEvents / Event Logs(Code and Log Tables) • Each service that modifies VOMRS data generates one or more events. • The service “dumps” all relevant data for an event / service to a “log” in the form of a database table. • The event_log / event_value tables are ‘instances’ of an event. • This data is recorded in the form of name/values pairs EVENTS E_ID 020 E_TAG MemberAssignedToGroup EVENT_VALUES EL_ID 357 E_ID 020 DN /DC=org/DC=DOEGrids../CN=….. CA DOEGrids GROUP /root/atlas IID 10 MID 1001 REPID 10 RIGHTS full ROLE Member SELFDN /DC=org…../CN=Weigand SELFCA /DOEGrids • Each event can have 1 or more event types associated with it allowing for different forms of member and interface notifications to be managed. Just one set of values. • Coupling to the code: • The service has to know what event to generate (e_tag is used in the code) • By dumping most everything, we don’t have to modify the code for additional data. VOMRS Technical Overview

VOMRS DatabaseEvents / Event Types (Code and Log Related Tables) • Each event can have 1 or more event types associated with it, allowing for different forms of member and interface notifications to be managed. • Event description (et_descr) • For members, it is generally the ‘subject’ of the email • For interfaces, it is less well defined at this point, but generally might be like an ‘action’ indicator. • Event template (et_template) • For members, it is the body of the email. • For interfaces, it would generally be the protocol or format of the interface trasaction. VOMRS Technical Overview

VOMRS DatabaseEvents / Event Types (Example) Event MemberDNDeleted has 3 event types 1. For notifying the affected Member: Description: An alias has been removed for you Template: Dear VO Member,Your alias with Distinguished Name %MAINDN%issued by Certificate Authority %MAINCA% has been deleted by %SELFDN%, %SELFCA%. VO Administrator</html> 2. For notifying an administrator / representative: Description: Member has removed an alias Template: <html>Dear Administrator,The VO member with Distinguished Name %DN% issued by Certificate Authority %CA% deleted an alias with Distinguished Name %MAINDN% issued by Certificate Authority %MAINCA% . Alias has been deleted by %SELFDN%, %SELFCA%. VO Administrator</html> 3. For an interface: Description: VOMSAction="Member has deleted an alias“ Template: deleteVOMSUser;%DN%;%CA% VOMRS Technical Overview

VOMRS DatabaseEvent Types / Event Subscribers(Code and Log Related Tables) • Each event can have 1 or more event types associated with it allowing for different forms of member and interface notifications to be managed. • Members subscribe/ unsubscribe to the events available for their role in the VO using the VOMRS service. • New interfaces are like code. There is no UI. Must be managed by an administrator or new release. Framework is such that we think this design will make addition of interfaces easier. • All yellow tables are pre-populated and are treated as part of the code. • You will notice we violate the normal parent-child forwarding of primary keys in tables such as event/event_types and event_type/role_event. • This was done intentionally • The services are only interested generating events and event_values. The services do not care about event_types. • The subscribers only care about the event description (er_descr) and the message/data associated with it (et_template). • This made it easier to maintain the table data which is effectively source code. VOMRS Technical Overview

VOMRS DatabaseEvent Notifications – Members / Interfaces(Log Related Tables) • The member_event_recipients and interface_event_recipients tables area used to track the notification attempts and feedback. • When an event occurs these tables are populated based on subscriptions of each event type. • The Event Manager / Interface Manager / VOMS Synchronizer then: • Perform a substitution of the event’s values in the template • Send the notification. • Update the recipients tables accordingly. VOMRS Technical Overview

VOMRS Technical OverviewTesting • Automated testing of business logic (services) using client / server. • Since web access side uses same services, business logic is covered for both. • They also share a “service broker” which performs the authorization functions. • 700+ tests performed • it is a rudimentary test (i.e., pass/fail). Has some data validation checks: 1) add something… add in again expect failure 2) test service created to verify templates substitutions are satisfied. • Lacks automation for all 9 administrative roles. Just tests VOAdmin roles. VOMRS Technical Overview

VOMRS Technical OverviewOpen Issues / Additional Enhancements? • Services • Currently have a tight coupling of the code with the return values. The code MUST return all data in the same order as specified in the service table. • Event scheduler • No means of evaluating returned email. • Email only notification mechanism. Are other methods needed? • No UI at this point if notification done manually • VOMS synchronization • Synchronization not the most efficient means of interfacing. However, handshakes on interfaces are difficult to implement. • No real means of processing feedback/handshake with VOMS if synchronization not performed. • Other interfaces • None defined. Will require analysis on an interface by interface basis most likely. Template concept could minimize protocal issues. • In most case will have to be serialized. • Testing • Manual testing of the Web interface very, very time consuming • Client/server testing needs to be more robust. Pass/Fail is OK, but not adequate. • Lacks ability to test all 9 roles. • Support for ‘Group (Grid)’ roles. • No validation criteria. Just a repository. Adequate? VOMRS Technical Overview

VOMRS Technical Overview John Weigand