SCAS

What is the SCAS

The Site Central Authorization Service (SCAS) will make authorization and mapping decision centrally. It uses HTTPS authentication to authenticate a client (as regular user or pilot job user) and present user credentials. The return message will contain a deny of permit decision, and when permitted Unix UID, primary GID and secondary GIDs will be returned. The primary client tool is gLExec, but the client is actually an LCMAPS plugin, so other tools like all the pre-WS GT4 gatekeepers, gridftpd and gsi-opensshd tools can also utilize this client server interaction.

Architecture and concepts

The Site Central Authorization Service (SCAS) is briefly described in the presentation given to the EGEE08 Conference (MWSG).

Installation guide

Prerequisites

The SCAS service will perform the credential mapping based on the SCAS client requests. The default result will be the Unix UID and Unix GIDs in their numeric form. The numeric form of the UIDs and GIDs are numbers found on the system of the SCAS service in the groups and passwd files. Therefor the UIDs and GIDs between the SCAS clients and SCAS service must be fully consistent.

IMPORTANT: Special care must be taken to avoid conflicts in the mappings of proxies by the SCAS server and by the CE(s) of the site. There are 2 ways to accomplish this:

1. The SCAS server and the CE(s) can share /etc/grid-security/gridmapdir through NFS (with the "noac" mount option).
2. The SCAS server and the CE(s) use separate ranges of pool accounts. For example, when the CE currently has dteam001-dteam050, the SCAS server could be configured to use dteam051-dteam100.

What to install (latest version of)

glite-security-saml2-xacml2-c-lib
glite-security-scas
glite-security-lcas
glite-security-lcas-interface
glite-security-lcas-plugins-basic
glite-security-lcas-voms
glite-security-lcmaps
glite-security-lcmaps-plugins-basic
glite-security-lcmaps-plugins-voms

The RPMs and tar-balls can be found in the etics repository, or (once released) from the gLite repository pages.

On the client, you will need a look like a gatekeeper or gLExec, and the following additional packages:

glite-security-saml2-xacml2-c-lib
glite-security-lcmaps-plugins-scas-client
glite-security-lcmaps-plugins-verify-proxy

in addition to all other, 'normal' LCAS/LCMAPS components, usually identical to the list needed for the SCAS service.

Setup

IMPORTANT: This installation does not use YAIM and may be incompatible with an installation using YAIM. This is a how-to that will enable you to do it manually without the use of YAIM. It's probably safer like that anyway.

1. add the user account named 'scas'. This will be the useraccount used to run the SCAS service with. This account doesn't require a shell.
2. When installing add a symlink from /etc/init.d/scas to /opt/glite/etc/init.d/scas.init.d
3. chkconfig --add scas
4. mkdir /var/log/glite/
5. touch /var/log/glite/scas.log
6. chown scas:scas /var/log/glite/scas.log Note: the scas.log file must only be writeable for scas.
7. cp /opt/glite/etc/logrotate.d/scas.logrotate.d to /etc/logrotate.d/scas.logrotate Note: The log of SCAS could grow very big quickly. Please consider to let logrotate run more frequent then daily (recommendation: hourly) and let it trigger on the size of the file, rather then the date.
8. Add the /opt/glite/lib and /opt/globus/lib to the default path in /etc/ld.so.conf, a new file in the /etc/ld.so.conf.d/ dir or make sure that the LD_LIBRARY_PATH is set to the required paths.
9. Install the CA certificates, like the IGTF accredited CAs.
10. Setup fetch-crl to update the CRL files.
11. Create a configuration file for the scas daemon in /opt/glite/etc/scas.conf with the following content:

scas_port = 8443
scas_capath = /etc/grid-security/certificates/
scas_hostcert = /etc/grid-security/scascert.pem
scas_hostkey = /etc/grid-security/scaskey.pem
lcas_db_file = /opt/glite/etc/lcmaps/lcas-scas.db
lcmaps_db_file = /opt/glite/etc/lcmaps/lcmaps-scas.db
scas_log_level = 1
scas_debug_level = 0
scas_log_file = /var/log/glite/scas.log
lcas_log_level = 1
lcas_debug_level = 0
lcmaps_log_level = 1
lcmaps_debug_level = 0

Note: For testing practices its advised to set the scas_log_level and scas_debug_level to 5 to see all possible interactions with the service.

1. Prepare the gridmapdir for LCMAPS, like on a CE. All the poolaccounts that are required for the mapping on the client machines need to exist on the system. The poolaccounts need to exist as empty files in this directory, each representing a poolaccount.
2. The gridmapdir directory must be owned by the 'scas' account.
3. Create the following lcmaps-scas.db in the following location: /opt/glite/etc/lcmaps/lcmaps-scas.db

# LCMAPS policy file/plugin definition
# Written by: Oscar Koeroo - okoeroo * at * nikhef * dot * nl
# The configuration file is specialized for non-root privileged processes/services, like:
### SCAS service and others

# default path for the modules
# IMPORTANT: NO WHITE SPACE CHARACTERS ARE ALLOWED AT THE END OF THE LINE!!!
path = /opt/glite/lib/modules

# Plugin definitions:
good             = "lcmaps_dummy_good.mod"

localaccount     = "lcmaps_localaccount.mod"
                   " -gridmapfile /etc/grid-security/grid-mapfile"

poolaccount      = "lcmaps_poolaccount.mod"
                   " -override_inconsistency"
                   " -gridmapfile /etc/grid-security/grid-mapfile"
                   " -gridmapdir /etc/grid-security/gridmapdir"

vomslocalgroup   = "lcmaps_voms_localgroup.mod"
                   " -groupmapfile /etc/grid-security/groupmapfile"
                   " -mapmin 0"

vomspoolaccount  = "lcmaps_voms_poolaccount.mod"
                   " -gridmapfile /etc/grid-security/grid-mapfile"
                   " -gridmapdir /etc/grid-security/gridmapdir"
                   " -do_not_use_secondary_gids"

vomslocalaccount = "lcmaps_voms_localaccount.mod"
                   " -gridmapfile /etc/grid-security/grid-mapfile"
                   " -use_voms_gid"


# Policies:
# DN-local -> VO-static -> VO-pool -> DN-pool

static_account_mapping:
localaccount -> good

voms_mapping:
vomslocalgroup -> vomslocalaccount
vomslocalaccount -> good | vomspoolaccount

classic_poolaccount:
poolaccount -> good

1. The grid-mapfile may contain both DNs and FQANs. They must match to either localaccounts or poolaccounts (both VOMS and non-VOMS based).

"/dteam" .dteam
"/C=NL/CN=Oscar Koeroo" mylocalaccount

Note: These types of data may also be split into different files. Adjust the plugin arguments accordingly to point to the different files.

1. The groupmapfile must have content only related to VOMS (FQAN) mappings, like:

"/dteam"    dteam

1. Install the following lcas.db at the location setup in the scas.conf (usually /opt/glite/etc/lcas/lcas-scas.db):

# LCAS policy file/plugin definition
# Written by: Oscar Koeroo - okoeroo * at * nikhef * dot * nl
pluginname=lcas_userban.mod,pluginargs=ban_users.db

1. touch /opt/glite/etc/lcas/ban_users.db
2. Make sure the configuration files ban_users.db, lcas-scas.db, lcmaps-scas.db, scas.conf, grid-mapfile and groupmapfile can be read by the 'scas' user. May still be owned by root (recommended).
3. After this, you may start the service:

/etc/init.d/scas start or service scas start

Performance test results and certification

The SCAS service was scrutinized by people at CERN (Geneva, CH) to see if they could get it to run on their certification test bed. The results are published at this TWiki page. It gives a nice overview except that, contrary to what is stated there, there is no strict relation between gLExec and SCAS, both are independent and each can be used by itself in your favourite scenario. You can make any service 'SCAS enabled' by installing the plug-in and simply reconfiguring the local LCMAPS setup to include the SCAS plug-in.

SCAS client : connecting to the service

Given that SCAS and GUMS share the same protocol, you can talk to SCAS using a the XACML2 GT4.2 PEP, or the privilege library used in gPlazma. But of course, you can also use the reference SCAS client plug-in of LCMAPS. It is trivial to add to any LCMAPS setup:

1. install the lcmaps-plugin-scas-client
2. configure the lcmaps.db to call it:

...
scasclient = "lcmaps_scas_client.mod"
             " -capath /etc/grid-security/certificates/"
             " -endpoint https://graszaad.nikhef.nl:8443"
             " -endpoint https://grasmaaier.nikhef.nl:8443"
             " -resourcetype wn"
             " -actiontype execute-now"

# policies
glexec_get_account:
verify_proxy -> scasclient
scasclient -> posix_enf

The SCAS client support dynamic load balancing and redundancy across any number of SCAS servers. A round-robin random start is the default, so that all end-points will be load balanced and are redundant. Make sure that all SCAS servers share the same mapping state (i.e. share the gridmapdir across a shared file system, e.g. CXFS, NFS or GPFS).

How do you know and test if the SCAS still works?

Try to connect to the SCAS with telnet:

lap-239:~ okoeroo$ telnet grasmaaier 8443
Trying 194.171.97.25...
Connected to grasmaaier.nikhef.nl.
Escape character is '^]'.
Connection closed by foreign host.
lap-239:~ okoeroo$ 

Note: It is expected for the telnet client to return quickly. A connection refusal is a failure.

The next we can try is to use OpenSSL s_client for a secured connection, using your certificate or even a proxy certificate.

openssl s_client -connect grasmaaier.nikhef.nl:8443 \
    -debug -state -nbio \
    -CApath /etc/grid-security/certificates/ 
    -CAfile $HOME/.globus/usercert.pem \
    -cert /tmp/x509up_u501 \
    -key /tmp/x509up_u501

For more OpenSSL wizardry you can have a look at the page How to handle OpenSSL and not get hurt.

Manual and documentation

The SCAS(8) man page contains all information needed to configure a SCAS service. It is installed with the SCAS package (in share/man/man8) and a snapshot is available on line.