DIRAC Web User Interface

A.Casajus (Universitat de Barcelona)M.Sapunov (CPPM Marseille)

On behalf of the LHCb DIRAC Team

CHEP 2009, Prague 2

Outline

m Goals and featuresm Framework description

Architecture Security Querying the DIRAC services

m Web pages examples Monitoring pages Site map

m Current limitations m Conclusions

CHEP 2009, Prague 3

Why a web interface?

m DIRAC is a distributed data production and analysis system for the LHCb experiment

m Users need to interact with DIRAC Usual solution is command-line or Desktop GUIs

m The web provides an interface with lots of benefits Operative system independent Minimal requirements (browser, internet) Familiar to users

4CHEP 2009, Prague

Required features

m Provide a user friendly interface with DIRAC

m DIRAC users are organized in groups based on privilegeso The web interface has to react to the user’s group

P Really different profiles like production manager, administrator, analysis user…

o Apply authentication and authorization rules to user requests

m Secure interface based on grid certificates

m Not only an information display but a full interactive web applicationo Take advantage of modern web technologies o Mimic a desktop application

CHEP 2009, Prague 5

DIRAC Web Portal

Internals

m Each user action triggers a AJAX call to the web server

m Each web page is mapped to a Python function

m Web pages interact with DIRAC using DISET (DIRAC’s secure communication framework)

m JavaScript is used to create a environment that behaves as a normal application.

CHEP 2009, Prague 6

CHEP 2009, Prague 7

Architecture

m Apache and mod_ssl provide the web server, secure connections and authentication mechanism

m DIRAC’s web user interface uses Pylons as the web framework

m mod_python is the bridge to execute Pylons under Apache

m To give a consistent “look and feel” to the web pages, we use ExtJS as the javascript widget library

CHEP 2009, Prague 8

Authorization and authentication

m DIRAC’s web interface allows secure and insecure connections

m Insecure connections are only allowed to access general information pages

m Users have to load their certificates in the web browser to access the sensitive parts of the web

m Once the user has been authenticated, the same authorization mechanism DIRAC uses is applied.

m Users can belong to more than one group. The web interface allows to select which group is the active for the session.

9

Authorization and authentication

m Different groups have different privileges, and that is reflected on the web pages

m Each group can perform different actions

CHEP 2009, Prague

User Administrator

CHEP 2009, Prague 10

Service queries

m Typically when a user requests a web page, triggers a query to a DIRAC service.

CHEP 2009, Prague 11

Service queries

m 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

m Services need to know who is requesting a query so they can apply their authorization rules and modify their behavior accordingly

m In case the query was originated by the user, the web server has to forward the user credentials to the services

m How to do that? (next slide)

12

Forwarding credentials

m 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

m 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…

m Both solutions are implemented but the second one is currently being used

CHEP 2009, Prague

Interface example

CHEP 2009, Prague 13

Interface example

selections

main menu buttons to open/collapse panels

buttons to submit or reset the form

menu to changeDIRAC setup

actions to perform for job(s)

current location

refresh table

certificate DNDIRAC Group

pagination controls items per page

Total amount of items

CHEP 2009, Prague 14

CHEP 2009, Prague 15

Monitoring pages

Monitoring pages allows users to:m Display all available information from objects. They can be

user jobs, productions, data transfer requests…m 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)

m Perform actions on an item or on a group: Reschedule Kill Delete

CHEP 2009, Prague 16

Site Map

CHEP 2009, Prague 17

Known limitations

There are several known limitations:

m Require a modern browser with JavaScript enabled

m DIRAC web portal doesn’t work properly in all browsers. Almost every browser has a different Javascript engine and

different debugging tools (if any)

m Due to the pages being completely dynamic, display of big tables (100+ rows) can take time Specially in old hardware

m DIRAC portal is not yet optimized and initial loading can take time

CHEP 2009, Prague 18

Conclusions

m The web interface allows users to easily interact with DIRAC in a secure way

m Desktop application behavior without extra software installation

m Web pages are aware of groups and react to them

m Actions are only allowed following the authorization rules Same mechanism as the DIRAC Services

m Smooth learning curve for new users