SCAS Test Plan

Service Description

The Site Central Authorization Service (SCAS) is a Web Service that allows client programs to query for an authorization decision based upon user credentials to access a particular resource. A service reference card is not yet available; more information about the service can be found in the man pages SCAS(8).

Deployment scenarios

300x300   SCAS2.png
SCAS Client-Server architecture
SCAS internally uses the LCAS and LCMAPS plugins to implement the authorization and mapping decision. Through LCAS a request coming from a Grid user with his DN can be authorized or banned. If authorized, the user can be mapped to a local Unix account; this is done through LCMAPS. When SCAS is used, the authorization and mapping decision are not done locally, on the WN, but the requests are forwarded from glexec to the local lcmaps and from here to the local SCAS client that contacts the SCAS service.

The SCAS service is contacted using the SCAS client module, which can be installed on a Cream CE, on a WN, or on a SE (currently only dCache is expected to interact with SCAS through gPlazma). In the Cream CE and WN the SCAS client is not used directly but through LCMAPS, which redirects a request to the SCAS service. The user identity switch (Grid user to Unix local account) is done through glexec, an executables that can spawn a process and make it run under a specified local account. In this case, it is glexec that will contact the SCAS service (still through LCMAPS and the SCAS client). The SCAS server, in case the Grid user is authorized, will return a Unix uid/gid that glexec will use to execute the spawned process.

In order to run glexec two environment variables must be set:

  • GLEXEC_CLIENT_CERT: pointing to a proxy certificate that will be used for the authorization decision and the identity mapping. This certificate will be passed from glexec to the SCAS service.
  • GLEXEC_SOURCE_PROXY: pointing to a proxy that the real user job can use. gLExec will copy this proxy to the home directory of the mapped user and name it $HOME/proxy. Glexec will also set the variable X509_USER_PROXY to point to this copied certificate. The certificate pointed by X509_USER_PROXY is the one that will be used to authenticate the connection between glexec and the SCAS service.

In the LHCb pilot job model two proxies are used, a 'pilot proxy' and a 'user proxy'. The 'pilot proxy' is not used by glexec, but only by the pilot agent to communicate with the DIRAC WMS services. Therefore, in this scenario, both GLEXEC_CLIENT_CERT and GLEXEC_SOURCE_PROXY point to the same proxy, the 'user proxy'.

gLExec-on-WN scenario

This scenarios refers to the late binding approach where a pilot job is submitted to a WN with the goal of managing future jobs on behalf of a group of users. In this case the SCAS server is installed on a machine, and gLExec is installed on a WN, together with the SCAS client and LCAS/LCMAPS plugins.

At the moment, this is the main use case for SCAS, therefore this test plan will focus on it, and will be tightly bound to glexec.

Features/Scenarios to be tested

Having a single main use case, different tests scenarios are obtained varying configuration options of glexec. Glexec can work with or without SCAS, and with or without identity change (setuid vs. log-only mode), these combination must all work when testing glexec. When testing SCAS of course glexec must be set to work with SCAS.

Basic glexec identity switch with SCAS authorization (implemented)

The test has to be done on a worker node with glexec configured in setuid mode with SCAS. A user proxy must be copied to the pilot user home directory; the two variables GLEXEC_CLIENT_CERT and GLEXEC_SOURCE_PROXY will point to this certificate. Run from a pilot user account, this test must be repeated using different voms credentials in the user proxy (no role, lcgadmin role, production role) Execute:
glexec /usr/bin/id
and verify that the userid returned is the one mapped in the SCAS service for the user DN contained in the user proxy. Glexec is set in setuid mode to retrieve the mapping information from the SCAS server and uses the retrieved Unix credential to spawn a process and execute the given command as argument.

The same test must be repeated using multiple users at the same time. Some of these users must be banned, and their request must not be executed.

Normal workflow - correct input

glexec returns the mapped id. With the same proxy, the same id must be returned. Changing the proxy, another id must be returned.

Error workflow - erroneous input

The error code that glexec must return are:
  • 201 - client error, which includes:
    1. no proxy is provided
    2. wrong proxy permissions
    3. target location is not accessible
    4. the binary to execute does not exist
    5. the mapped user has no rigths to execute the binary
    6. when GLEXEC_CLIENT_CERT is not set

  • 202 - system error
    1. glexec.conf is not present or malformed
    2. lcas or lcmaps initialization failure, can be obtained moving the lcas/lcmaps db files.

  • 203 - authorization error
    1. user is not whitelisted
    2. local lcas authorization failure
    3. user banned by the SCAS server
    4. lcmaps failure on the scas server
    5. SCAS server not running
    6. network cable unplugged on the SCAS server host.
  • 204 - exit code of the called application overlap with the previous ones
    1. application called by glexec exit with code 201, 202, 203 or 204

gLExec in Logging only mode

In this scenario gLExec is configured not to change the uid, but it will log information about the request and the user identity of the process to be executed will run with the original uid (pilot job or Cream CE service container). The test described above can be repeated with glexec configured in logging-only mode. In the normal workflow, the test will return the id of the pilot user. The erroneous workflow is the same as above.

Stress test for the multi-user pilot job scenario (implemented)

One week of high load must be executed. High load means that the SCAS service must be able to satisfy requests with an average frequency of 6Hz. On a VM of the CTB we achieved a frequency of approximately 0.66Hz (SCAS request per second), therefore 10 WNs will be used to achieve 6Hz. When launching the test, one worker node will be added every 2 hours, so that the ramp up time will be 20 hours. After 20 hours 10 WNs will keep calling glexec continuously for a week.

Features not to be tested

'dCache-SCAS interaction'

Testing this scenario depends on the availability of gPlazma, which is not yet released.

-- GianniPucciani - 25 Mar 2009

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2009-03-25 - GianniPucciani
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback