1. 5/17/2004VOMRS Technical Overview1 VOMRS Technical Overview John Weigand

2. 5/17/2004VOMRS Technical Overview2 1.VOMRS Architecture 2.VOMRS database 3.Testing 4.Open Issues

3. 5/17/2004VOMRS Technical Overview3 VOMRS Architecture 1.Access (Client / Web ) CLI GSI authentication (Java Cog Kit)Java Cog Kit SOAP/SSL authentication (EDG Trust Manager)EDG Trust Manager Java Web UI HTTP/SSL authentication (EDG Trust Manager)EDG Trust Manager Java / Java script VOMRS Admin Java / Axis / Tomcat WEB service 2.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 3.ServiceBroker / Services Authorization Business Logic

4. 5/17/2004VOMRS Technical Overview4 VOMRS Architecture Web Access 1.Two ways of accessing the VOMRS besides VOMRS client: a.web UI (HTTP+SSL authentication) http://computing.fnal.gov/docs/products/vomrs/#manualhttp://computing.fnal.gov/docs/products/vomrs/#manual. b.web services (SOAP+SSL authentication) https://vomrs_host:8443/vo- /services/VOMRS?wsdl 2.All access methods utilize the same implementation of the business logic. 3.Authentication provided by the EDG Trust Manager (http://edg-wp2.web.cern.ch/edg-wp2/security)http://edg-wp2.web.cern.ch/edg-wp2/security 4.WEB UI behavior controlled by configuration file parameters: a.The duration of the session b.The name of organization that oversees all grid resources for a particular VO c.The url location of usage rules for this organization Configuration file entries: VOMRS_DIR/var/etc/vomrs_VO_NAME_CNVRT/log4j_webui.properties <!-- time in seconds until session expires 600 --> LCG https://edms.cern.ch/file/428036/LAST_RELEASED/LCG_Usage_Rul es.pdf

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

6. 5/17/2004VOMRS Technical Overview6 VOMRS Architecture Service Broker / Services 1.All 3 access methods utilize a common ServiceBroker and a common set of Services. 2.All use the same business logic to satisfy a requested 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 3.Services define: a.The action performed within VOMRS database b.Administrative roles authorized to perform this action c.List of input and output arguments 4.Authorization restrictions: a.Basic is based on role and arguments implemented in the ServiceBroker b.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.)

7. 5/17/2004VOMRS Technical Overview7 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 5.ServiceBroker performs: a.Service availability b.Service authorization based on role and arguments c.Execution of the authorized service d.Return data/success/failure of the service to the requestor.

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

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

10. 5/17/2004VOMRS Technical Overview10 VOMRS Architecture VOMS Synchronizer 1.Thread of the VOMRS Server that transfers information from the VOMRS database to the VOMS database using EDG VOMS Admin API. 2.Behavior is controlled by the VOMRS configuration 3.Two (2) modes of operations: a.event driven mode - level 4 - using the Interface Manager to handle each event relevant to VOMS (subscribed by VOMS interface). b.Synchronization mode - The other mode allows a Synchronizer to synchronize the VOMRS and VOMS databases. 4.Four (4) levels of synchronization: a.Level 0 - Addition of all “approved” VOMRS members to a root group of the VOMS database b.Level 1 - Addition of all “approved” VOMRS members to a root group and deletion of all “suspended” VOMRS members from the of VOMS database c.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. d.Level 3 - Complete synchronization. Includes synchronization of groups and roles, member assignment to the subgroups and member role within subgroups.

11. 5/17/2004VOMRS Technical Overview11 VOMRS Architecture VOMS Synchronizer Configuration file entries: <!—change to on to enable syncronization, will use VOMS API and SOAP/SSL authentication  off <!-- the synchronization interval in minutes, 10 default is 10 minutes --> <!-- the synchronization level 0 default is 0 -"Add Members", 1- "Add/Delete Banned Members", 2 - "Synchronize Members", 3- "Synchronize", 4- "Event Driven Synchronization" --> https://VOMS_hostname:8443/edg-voms- admin/VOMS_VO_NAME/services/VOMSAdmin <!-- if axis.socketSecureFactory is not defined assumes this org.edg.security.trustmanager.axis.AXISSocketFactory --> <!-- if sslCAFiles is not defined assumes this /etc/grid-security/certificates/*.0 --> <!-- if running as root assume this as a default /etc/grid-security/hostkey.pem /etc/grid-security/hostcert.pem --> <!-- if running as a user assume this as a default /tmp/x509up_u_uid -->

12. 5/17/2004VOMRS Technical Overview12 VOMRS Database 1.Currently MySql with intent to support Oracle. 2.3 categories of tables: a.Core tables contain the basic updatable VO membership data b.Code related tables Tightly coupled with the application’s code Only modified in conjunction with the code Not updated with available VOMRS services c.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 3.‘Code related’ and ‘Log’ tables used to support: a.Concept of Services b.Event (member and interface) notifications c.It is an attempt to reduce the amount of ‘hard-coding’ that would have otherwise been required.

13. 5/17/2004VOMRS Technical Overview13 VOMRS Database ERD Code related tablesCore tablesLog 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.

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

15. 5/17/2004VOMRS Technical Overview15 VOMRS Database Services (Code Related Tables) 1.Defines the authorized functions that can be performed by a VO member in the VOMRS database. 2.Tables a.Services table Defines the service, required arguments and return_values b.Service_roles table Defines the VO member administrative roles that can perform the service 3.Tight coupling of code and tables a.Member role dictates menus presented in the web interface b.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) 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

16. 5/17/2004VOMRS Technical Overview16 VOMRS Database Events / Event Logs (Code and Log Tables) 1.Each service that modifies VOMRS data generates one or more events. 2.The service “dumps” all relevant data for an event / service to a “log” in the form of a database table. 3.The event_log / event_value tables are ‘instances’ of an event. 4.This data is recorded in the form of name/values pairs 4.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. 5.Coupling to the code: a.The service has to know what event to generate (e_tag is used in the code) b.By dumping most everything, we don’t have to modify the code for additional data. 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

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

18. 5/17/2004VOMRS Technical Overview18 VOMRS Database Events / 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 2. For notifying an administrator / representative: Description: Member has removed an alias Template: 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 3. For an interface: Description: VOMSAction="Member has deleted an alias“ Template: deleteVOMSUser;%DN%;%CA%

19. 5/17/2004VOMRS Technical Overview19 VOMRS Database Event Types / Event Subscribers (Code and Log Related Tables) 1.Each event can have 1 or more event types associated with it allowing for different forms of member and interface notifications to be managed. 2.Members subscribe/ unsubscribe to the events available for their role in the VO using the VOMRS service. 3.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. 4.All yellow tables are pre-populated and are treated as part of the code. 5.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. a.This was done intentionally b.The services are only interested generating events and event_values. The services do not care about event_types. c.The subscribers only care about the event description (er_descr) and the message/data associated with it (et_template). d.This made it easier to maintain the table data which is effectively source code.

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

21. 5/17/2004VOMRS Technical Overview21 VOMRS Technical Overview Testing 1.Automated testing of business logic (services) using client / server. a.Since web access side uses same services, business logic is covered for both. b.They also share a “service broker” which performs the authorization functions. 2.700+ tests performed a.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. b.Lacks automation for all 9 administrative roles. Just tests VOAdmin roles.

22. 5/17/2004VOMRS Technical Overview22 VOMRS Technical Overview Open Issues / Additional Enhancements? 1.Services a.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. 2.Event scheduler a.No means of evaluating returned email. b.Email only notification mechanism. Are other methods needed? c.No UI at this point if notification done manually 3.VOMS synchronization a.Synchronization not the most efficient means of interfacing. However, handshakes on interfaces are difficult to implement. b.No real means of processing feedback/handshake with VOMS if synchronization not performed. 4.Other interfaces a.None defined. Will require analysis on an interface by interface basis most likely. Template concept could minimize protocal issues. b.In most case will have to be serialized. 5.Testing a.Manual testing of the Web interface very, very time consuming b.Client/server testing needs to be more robust. Pass/Fail is OK, but not adequate. c.Lacks ability to test all 9 roles. 6.Support for ‘Group (Grid)’ roles. a.No validation criteria. Just a repository. Adequate?