Content-type: text/html Manpage of SCAS

SCAS

Section: scas (8)
Updated: Jan 2009
Index Return to Main Contents

 

NAME

scas - Site Central Authorization Service

 

SYNOPSIS

scas [--conf <configuration file>] [--port <0-9+>] [--log <log file>] [--cert <X509 (public) certificate file>] [--key <private key file>] [--capath <directory with CA files>] [--h | -h]

 

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. The result of the query will either be an allow or deny. When the service decided to send an allow message to its requesting client it may include obligations. These obligations are undeniable and MUST be processed. The returned obligations can tell the client on which terms the credentials were allowed. In our case with the SCAS (and also with GUMS/PRIMA/gPlazma use cases) this will be Unix account mapping obligations (and other use case specific attributes).

When a SCAS is queried for a authorization decision it receives user credentials among other pieces of information that tells the SCAS more about the query's origin. The SCAS is mostly interested in the user credentials. The user credentials are extracted from the query and processed in Local Centre Authorization Service (LCAS) and Local Credential Mapping Service (LCMAPS).

On the return of the allow message from the SCAS back to the client, the LCMAPS mapping result will be transported back to the client in the form of an obligation that holds sufficient information to perform an LCMAPS mapping on the client side. The type of obligations may be extended to support other type of clients. But for now all LCMAPS based clients are supported (like the GT4 gatekeepers with LCMAPS and gLExec). This will be extended to GUMS/PRIMA/gPlazma in time because they will require the support for other XACML obligations.

 

OPTIONS

--conf <configuration file>
This is the configuration file for the SCAS service. It will configure how the SCAS will operate, like the logfile locations and port number on whih the daemon is listening, and how it will invoke the LCAS and LCMAPS frameworks.

--port <0-9+>
Portnumber on which the daemon will be listening.

--log <log file>
The location of the logfile for this SCAS execution. Provide the full filepath to a file in which the log entries can be written. The SCAS service will combine the SCAS specific, LCAS and LCMAPS log entries into one file.

--cert <X509 (public) certificate file>
The path to the public certificate file to be used to authenticate the SCAS to its connecting clients. Use a host or service certificate.

--key <private key file>
The path to the private key file that fits the public key in the used certificate file.

--capath <directory with CA files>
The path to the directory that contains the installed and supported CAs (Certificate Authorities). The SCAS clients that connect to the service MUST present a certificate that is (ultimately) signed by one of the installed CA certificates. In the Grid world this is most often set to '/etc/grid-security/certificates/' using the IGTF (International Grid Trust Federation) accredited CAs. The CA directory is also used to read the CRL (Certificate Revocation List) files to check if a SCAS client's certificate was revoked.

--h | -h
The help on the CLI which should tell you the command line options.

--no-daemon
This will prevent the SCAS service to daemonize properly and escape the TTY from which it was started to run under init or launchd. This option is introduced to be able to debug the service.

 

Note:

The commandline options take presidence over the content of the read configuration file.

 

SIGNALING

The signal handling in SCAS will react on the SIGHUP signal. The SCAS service will react on the SIGHUP by re-initializing the log facility. This allows logrotate to move the logfile and send the SIGHUP to the main SCAS process. An example logrotate configuration file is included in the package.

 

ENVIRONMENT

SCAS_DEBUG_LEVEL
This environment variable will steer the detailedness of the SCAS service logfile. The range is from 0 to 5, where 0 is the near nothing what it will log and 5 means super verbose. Tune it wisely, other wise the logfiles might be useless or too verbose. The advised operational level is '1'.

SCAS_LOG_STRING
The value of this environment variable will be used as a prefix to all log lines.

LCAS_LOG_FILE
This variable will declare an alternate location for the logfile of the LCAS framework.

LCMAPS_LOG_FILE
This variable will declare an alternate location for the logfile of the LCMAPS framework.

 

MISCELLANEOUS

To verify if the public key and private key fit together you can compare the modulus of the certificate and private key file and check if they are the same:

openssl x509 -noout -modulus -in <X509 (public) certificate file>
openssl rsa -noout -modulus -in <private key file>

 

FILES

/opt/glite/etc/scas.conf /opt/glite/etc/init.d/scas.init.d /opt/glite/etc/logrotate.d/scas.logrotate

 

BUGS

After lots of Valgrinding I can conclude that the Globus libraries used by LCAS and LCMAPS leak memory and OpenSSL 0.9.7a leaks memory. But that leakage is not significant. The real hitter is the SAML2-XACML2 library (also from Globus, but independent from the existing Globus code). I'm unable to let this be patch quickly and resorted to a proven concept of the Apache HTTPd service to split the service into a clean parent process and timely enough re-issue a child process that performs the hard work. This solution is very stable, doesn't hurt performance and our planning.

 

SEE ALSO

lcas(1), lcmaps(1), x509(1), glexec(1), glexec.conf(5)

 

AUTHOR

Writen by Oscar Koeroo <okoeroo@nikhef.nl>

 

COPYRIGHT

Copyright © 2008, EGEE


 

Index

NAME
SYNOPSIS
DESCRIPTION
OPTIONS
Note:
SIGNALING
ENVIRONMENT
MISCELLANEOUS
FILES
BUGS
SEE ALSO
AUTHOR
COPYRIGHT

This document was created by man2html, using the manual pages.
Time: 10:42:42 GMT, May 15, 2009