1. DIRAC Web User Interface A.Casajus (Universitat de Barcelona) M.Sapunov (CPPM Marseille) On behalf of the LHCb DIRAC Team

2. Outline  Goals and features  Framework description  Architecture  Security  Querying the DIRAC services  Web pages examples  Monitoring pages  Site map  Current limitations  Conclusions CHEP 2009, Prague2

3. Why a web interface?  DIRAC is a distributed data production and analysis system for the LHCb experiment  Users need to interact with DIRAC  Usual solution is command-line or Desktop GUIs  The web provides an interface with lots of benefits  Operative system independent  Minimal requirements (browser, internet)  Familiar to users CHEP 2009, Prague3

4. 4 Required features  Provide a user friendly interface with DIRAC  DIRAC users are organized in groups based on privileges  The web interface has to react to the user’s group Really different profiles like production manager, administrator, analysis user…  Apply authentication and authorization rules to user requests  Secure interface based on grid certificates  Not only an information display but a full interactive web application  Take advantage of modern web technologies  Mimic a desktop application

5. DIRAC Web Portal CHEP 2009, Prague5

6. Internals  Each user action triggers a AJAX call to the web server  Each web page is mapped to a Python function  Web pages interact with DIRAC using DISET (DIRAC’s secure communication framework)  JavaScript is used to create a environment that behaves as a normal application. CHEP 2009, Prague6

7. Architecture  Apache and mod_ssl provide the web server, secure connections and authentication mechanism  DIRAC’s web user interface uses Pylons as the web framework  mod_python is the bridge to execute Pylons under Apache  To give a consistent “look and feel” to the web pages, we use ExtJS as the javascript widget library CHEP 2009, Prague7

8. Authorization and authentication  DIRAC’s web interface allows secure and insecure connections  Insecure connections are only allowed to access general information pages  Users have to load their certificates in the web browser to access the sensitive parts of the web  Once the user has been authenticated, the same authorization mechanism DIRAC uses is applied.  Users can belong to more than one group. The web interface allows to select which group is the active for the session. CHEP 2009, Prague8

9. Authorization and authentication  Different groups have different privileges, and that is reflected on the web pages  Each group can perform different actions CHEP 2009, Prague9 UserAdministrator

10. Service queries  Typically when a user requests a web page, triggers a query to a DIRAC service. CHEP 2009, Prague10

11. Service queries  Service queries can be originated by:  The web interface itself in case the connecting user is anonymous (insecure connection)  The connecting user if it’s a secure connection  Services need to know who is requesting a query so they can apply their authorization rules and modify their behavior accordingly  In case the query was originated by the user, the web server has to forward the user credentials to the services  How to do that? (next slide) CHEP 2009, Prague11

12. Forwarding credentials  Use DIRAC’s ProxyManager to retrieve a user’s proxy and use it to contact the final service  Pros: Cannot “invent” credentials  Cons: Users that don’t have a valid proxy in DIRAC can’t use the web Need to keep proxies as long as the real certificate for all user/group combination  Connect to the service using the web service credentials and “tell” the service who the user is  Pros: Users don’t need to do anything Works automatically for all registered users  Cons: Can “invent” any credential. If the web certificate gets stolen…  Both solutions are implemented but the second one is currently being used CHEP 2009, Prague12

13. Interface example CHEP 2009, Prague13

14. Interface example selections main menu buttons to open/collapse panels buttons to submit or reset the form menu to change DIRAC setup menu to change DIRAC setup actions to perform for job(s) current location refresh table certificate DN DIRAC Group pagination controls items per page Total amount of items CHEP 2009, Prague14

15. Monitoring pages Monitoring pages allows users to:  Display all available information from objects. They can be user jobs, productions, data transfer requests…  Easy access to information associated with an object (e.g. user jobs):  JDL  Attributes  History  Peek output of jobs while running  Access logs: Log files (if any) Standard output and standard error of the pilot that executed the job (if it is accessible)  Perform actions on an item or on a group:  Reschedule  Kill  Delete CHEP 2009, Prague15

16. Site Map CHEP 2009, Prague16

17. Known limitations There are several known limitations:  Require a modern browser with JavaScript enabled  DIRAC web portal doesn’t work properly in all browsers.  Almost every browser has a different Javascript engine and different debugging tools (if any)  Due to the pages being completely dynamic, display of big tables (100+ rows) can take time  Specially in old hardware  DIRAC portal is not yet optimized and initial loading can take time CHEP 2009, Prague17

18. Conclusions  The web interface allows users to easily interact with DIRAC in a secure way  Desktop application behavior without extra software installation  Web pages are aware of groups and react to them  Actions are only allowed following the authorization rules  Same mechanism as the DIRAC Services  Smooth learning curve for new users CHEP 2009, Prague18