Changes

Patches for Release 01-08-00

Server

The AM Server listens now on 2 ports:

The AM servers configurations are stored centrally in the LDAP.

The tool AccessManagerServerRemoteControl can be used to send messages to the AM servers. Below are some usage examples:

[lnxatd40] ~ $ AccessManagerServerRemoteController -h
Version: 1.0 built on Aug 12 2007 03:13:56
Usage: AccessManagerServerRemoteController <-s server_name> <-p port_number> <-c command> [-h]
Options:
         -s the machine name that runs the Access Manager server
         -p the port number on which the Access Manager listens for control messages. Default 20001
         -c the command to send to the server. The valid commands are:
             SERVER_ID        Ask the Access Manager server identifier
             UP_TIME          Ask the Access Manager server uptime
             START_TIME       Ask the Access Manager server start time
             LDAP_UPDATED     Inform the Access Manager server that the LDAP information has been updated
             NEW_CONN         Ask the number of connection request received for AM authorization
             REQ_PROC         Ask the number of authorization requests processed successfully
             REQ_NOT_PROC     Ask the number of authorization requests processed unsuccessfully
         -h display this help screen

[lnxatd40] ~ $ AccessManagerServerRemoteController -s lnxatd79 -c SERVER_ID
Message [SERVER_ID] sent to [lnxatd79(137.138.130.220):20001]
Response [AccessManagerServerID.nightly] received from [137.138.130.220:20001]

[lnxatd40] ~ $ AccessManagerServerRemoteController -s lnxatd79 -c START_TIME
Message [START_TIME] sent to [lnxatd79(137.138.130.220):20001]
Response [Aug 8, 2007 2:01:02 PM] received from [137.138.130.220:20001]

[lnxatd40] ~ $ AccessManagerServerRemoteController -s lnxatd79 -c LDAP_UPDATED
Message [LDAP_UPDATED] sent to [lnxatd79(137.138.130.220):20001]
Response not expected!

[lnxatd40] ~ $ AccessManagerServerRemoteController -s lnxatd79 -c REQ_PROC    
Message [REQ_PROC] sent to [lnxatd79(137.138.130.220):20001]
Response [0] received from [137.138.130.220:20001]

The scripts have been improved and 3 more have been added:

amServerService

amServerService, version 1.0
Starts the TDAQ Access Manager server on the current machine with the configuration stored in LDAP.
Usage: amServerService [-l ldapserver] [-b basedn] [-s] [-h] <start|stop|status|reload>
  -l the ldapserver;    default is [lnxatdsrv.cern.ch]
  -b the basedn;                default is [ou=atlas,o=cern,c=ch]
  -s show all the AM server configurations from LDAP
  -h the help screen

amServerRemoteController

amServerRemoteController, version 1.0
Send messages to AM Servers using their LDAP configuration.
Usage: amServerRemoteController [-l ldapserver] [-b basedn] [-s] [-t am_server_name] <-c command> [-h]
  -l the ldapserver;    default is [lnxatdsrv.cern.ch]
  -b the basedn;                default is [ou=atlas,o=cern,c=ch]
  -s show all the AM server configurations from LDAP
  -c the command to send to the server. The valid commands are:
     SERVER_ID        Ask the Access Manager server identifier
     UP_TIME          Ask the Access Manager server uptime
     START_TIME       Ask the Access Manager server start time
     LDAP_UPDATED     Inform the Access Manager server that the LDAP information has been updated
     NEW_CONN         Ask the number of connection request received for AM authorization
     REQ_PROC         Ask the number of authorization requests processed successfully
     REQ_NOT_PROC     Ask the number of authorization requests processed unsuccessfully
  -t send the command only to this AM server. Default sends to all the AM server configured in LDAP.
  -h the help screen

amServerLDAPNotifier

This shell script takes care of starting and stopping the dnotify daemons to notify the AM servers about the LDAP update events
Usage: amServerLDAPNotifier {start|stop|restart|status}


Changes

Release 01-08-00

Server

The AM Server part that handles the clients connections has been redesigned. It is a highly scalable server architecture based on reactor pattern implemented with the non blocking socket classes from Java NIO package. It uses the thread pool implementation from java.concurrent packages.
The default configuration is:

	Processing threads:	2 threads 
	Timeout: LDAP socket connection: 3 s 
	Timeout: LDAP operation time limit: 3 s
	Timeout: Message receive from the client: 6 s
	Cache timeout: RBAC users: 60 s
	Cache timeout: Policies: 300 s
	Cache timeout: Evaluation Context: 5 s
	JVM max heap size: 384 MB
	JVM max heap size: 512 MB

Client API

There are 2 new resource types defined for RunControl and IGUI.
All the exception are thrown out to the user code in the C++ API.
The C++ exceptions are based on the ERS exception and are the following:

	daq::am::Exception			- the base class of all exception thrown by the AM C++ client API
	|
	|- CommunicationIssue			- the base class of all the exceptions concerning the communication problems
	|  |- CommunicationInit			- failure in communication initialization with the server
	|  |- NetworkError			- generic error when network problems are encountered
	|  |  |- NetworkConnectTimeout		- the network connection to the server has timeout
	|  |- CommunicationStreamsError		- the messages sending or receiving errors
	|     |- CommunicationStreamsTimeout	- the cause of a communication stream error is a timeout
	|
	|- XACMLIssue				- the base class of all the exceptions concerning XACML processing;
	|- ServerProcessingIssue		- the base class of all the exceptions caused by a server processing 
						  error identified as a message in the response from the server
		

Scripts

There are available a set of scripts to run distributed tests in a cluster, collect the test logs and process them. The scripts are amTestDrive, amTestSuite, amTestSuiteBulkRun, amTestSuiteReports.
> Some other scripts have been enhanced with more flags.

amServer

amServer, version 0.5
Start or stops the Access Manager server.
Usage: amServer [-p port] [-d LDAP_host] [-b LDAP_basedn] [-P policies_path] [-L log_dir] 
[-l log_level] [-D] [-J jvm_heap_max] [-t proc_threads] [-s] [-h] 
           -p the port
     number on which
  the server will listen for
     requests Default is
  [20000] -d the LDAP server
     name Default is[atd-ldap.cern.ch]-btheLDAPbaseDNDefaultis[ou=tdaq,ou=atlas,o=cern,c=ch]
  -P the policies directory where the XACML policy files are stored
     Default is [./../data/AccessManager/policies/]
  -L the log directory where the log files are written
     Default is [/home-users/mleahu/logs/]
  -l the log level. Can be one of the following:
        NONE            - no logs at all
        NORMAL          - log the errors and warnings
        VERBOSE         - log the information messages
        VERY_VERBOSE    - log the configuration messages
        DEBUG           - log the debug messages
        ALL             - log all the messages
     Default is [NORMAL]
  -D start the JVM in debug mode for socket connection on port 8000
  -J the maximum JVM heap size. 0 to use the JVM default
     Script default is [512m]
  -t the maximum number of AM Processing Threads
  -s enable the statistics feature
     Default is [off]
  -h this info

amServerInterrogatorCTest

amServerInterrogatorCTest, version 0.2
Run the AM's Server Interrogator implementation using the C++ API.
Usage: amServerInterrogatorCTest [-a ] [-s server_host] [-p server_port] [-l log_level] 
[-n number_iterations] [-t delay_iterations] [-r resource_type] [-1|2|3|4 resource_attr] 
[-u access_subject_username] [-o access_subject_hostname] [-h]

  -a enable or disabled the Access Manager authorization in C++ API. Valid values are 'on' and 'off'
     Default is [on]
  -s the hostname where Access Manager server is running
     Default is [lnxatdmon]
  -p the port number on which the Access Manager server is listening
     Default is [20000]
  -l the ERS debug level. Should be a positive number
     Default is [0]
  -n specify the number of test iterations
     Default is [1]
  -t delay between the test interations in ms
     Default is [0]
  -r the resource type to be accessed.
     Default is []
  -1 the resource type attribute #1.
     Default is []
  -2 the resource type attribute #2.
     Default is []
  -3 the resource type attribute #3.
     Default is []
  -4 the resource type attribute #4.
     Default is []
  -u the access subject's username
     Default is []
  -o the access subject's hostname
     Default is []
  -h this info


Introduction

The AccessManager component has been redeveloped to use the XACML standard for access control policies definitions and authorization requests and responses. The access control model is the same Role Based Access Control. The Access Manager server is an independent application that receives request via TCP network connections from clients and responds in the same way. It is implemented in Java using the Sun's XACML implementation. This version uses a LDAP database to store the users' roles and local XML files to store the access control policies.

Client API

In order to interrogate the Access Manager server, the clients can use the provided API. Currently, the API is available in C++ and Java implementations.

Java API

Following is an example of an request authorization to access a PMG specific resource for a start or terminate action using the Java API:

import am.client.ServerInterrogator;
import am.util.AMException;
import am.xacml.context.impl.PMGResource;

public class ServerInterrogatorTest {
	public static void main(String[] args){
		
		// instantiate a server interrogator object
		ServerInterrogator srv = new ServerInterrogator();
		
		try {
			// define the resource to request the access authorization for
			PMGResource respmg = new PMGResource("ANY:PROCESS");
			// set the action to be performed on the resource and that has to be authorized
			respmg.setStartAction();
			
			// get the authorization result and the reason of the decision
			System.out.println("PMG AUTHORIZATION REQUEST RESULT:" + srv.isAuthorizationGranted(respmg) + 
					" STATUS:" + srv.getStatusMessage());
		} catch (AMException e) {
			System.err.println(e.getMessage());
		}
	}
}			
The environment variables needed by the Java client API are:
	TDAQ_AM_AUTHORIZATION 		- enable or disabled the Access Manager authorization in C++ API. Valid values are 'on' and 'off'
	TDAQ_AM_SERVER_HOST   		- the hostname where Access Manager server is running
	TDAQ_AM_SERVER_PORT   		- the port number on which the Access Manager server is listening
	TDAQ_AM_LOGS_DIR      		- the log directory where the log files are written
	TDAQ_AM_CLIENT_LOG_LEVEL 	- the log level. Can be one of the following:
	        NONE            - no logs at all
	        NORMAL          - log the errors and warnings
	        VERBOSE         - log the information messages
	        VERY_VERBOSE    - log the configuration messages
	        DEBUG           - log the debug messages
	        ALL             - log all the messages		
		

C++ API

Following is an example of an request authorization to access a PMG specific resource for a start or terminate action using the C++ API:
#include <AccessManager/util/ErsIssues.h>
#include <AccessManager/xacml/impl/PMGResource.h>
#include <AccessManager/client/ServerInterrogator.h>

using namespace std;
	
int main() {
	
	daq::am::PMGResource pmgRes("process_binary_path", "hostname", "arg1 arg2");
	pmgRes.setStartAction();

		
	

daq::am::ServerInterrogator si;
bool allowed;
try{ allowed=

  
	
  
	
	    
	si.isAuthorizationGranted(pmgRes);

		
		if (allowed){
	
			cout <<
	"permission:
		ALLOWED"  <<
		endl; }
			else  { cout  <<
		"permission: DENIED" <<
			endl;  } cout  <<
		"Status
		Message = " <<si.getStatusMessage()  <<  endl;
		
	} catch (daq::am::ServerInterrogationIssue& ex){
		ers::error(ex);
	} catch (...) {
		ERS_ERROR("Can not decode the response! "); 
		throw;
	}

	return 0;
}
The environment variables needed by the C++ client API are:
	TDAQ_AM_AUTHORIZATION 		- enable or disabled the Access Manager authorization in C++ API. Valid values are 'on' and 'off'
	TDAQ_AM_SERVER_HOST   		- the hostname where Access Manager server is running
	TDAQ_AM_SERVER_PORT   		- the port number on which the Access Manager server is listening
	TDAQ_ERS_DEBUG_LEVEL     	- the ERS debug level. Should be a positive number
		

Scripts

There are available a set of Access Manager scripts to start/stop the server, generate the policies, run some client tests using the Java and C++ API, and roles manipulations. Following are the help screens of each script showing the list of arguments to be passed to them.

amPAP

         Run the AM's
Policy Access Point to generate the policies into files. Usage: amPAP [-d LDAP_host]
  [-b LDAP_basedn] [-P policies_path] [-L
     log_dir] [-l log_level]
  [-h] -d the LDAP server
     name Default is[atd-ldap.cern.ch]-btheLDAPbaseDNDefaultis[ou=tdaq,ou=atlas,o=cern,c=ch]
  -P the policies directory where the XACML policy files are stored
     Default is [/home-users/mleahu/am/installed/share/bin/../data/AccessManager/policies/]
  -L the log directory where the log files are written
     Default is [/home-users/mleahu/logs/]
  -l the log level. Can be one of the following:
        NONE            - no logs at all
        NORMAL          - log the errors and warnings
        VERBOSE         - log the information messages
        VERY_VERBOSE    - log the configuration messages
        DEBUG           - log the debug messages
        ALL             - log all the messages
     Default is [NORMAL]
  -h this info

amServer

Start or stops the Access Manager server.
Usage: amServer [-p port] [-d LDAP_host] [-b LDAP_basedn] [-P policies_path] [-L log_dir] [-l log_level] [-h] 
           -p the port
     number on which
  the server will listen for
     requests Default is
  [20000] -d the LDAP server
     name Default is[atd-ldap.cern.ch]-btheLDAPbaseDNDefaultis[ou=tdaq,ou=atlas,o=cern,c=ch]
  -P the policies directory where the XACML policy files are stored
     Default is [/home-users/mleahu/am/installed/share/bin/../data/AccessManager/policies/]
  -L the log directory where the log files are written
     Default is [/home-users/mleahu/logs/]
  -l the log level. Can be one of the following:
        NONE            - no logs at all
        NORMAL          - log the errors and warnings
        VERBOSE         - log the information messages
        VERY_VERBOSE    - log the configuration messages
        DEBUG           - log the debug messages
        ALL             - log all the messages
     Default is [NORMAL]
  -h this info

amServerInterrogatorCTest

Run the AM's Server Interrogator implementation using the C++ API.
Usage: amServerInterrogatorCTest [-a ] [-s server_host] [-p server_port] [-l log_level] [-h]
  -a enable or disabled the Access Manager authorization in C++ API. Valid values are 'on' and 'off'
     Default is [on]
  -s the hostname where Access Manager server is running
     Default is [pcatd11]
  -p the port number on which the Access Manager server is listening
     Default is [20000]
  -l the ERS debug level. Should be a positive number
     Default is [0]
  -h this info

amServerInterrogatorJTest

Run the AM's Server Interrogator implementation using the Java API and Junit testing framework.
Usage: amServerInterrogatorJTest [-a ] [-s server_host] [-p server_port] [-L log_dir] [-l log_level] [-h]
  -a enable or disabled the Access Manager authorization in Java API. Valid values are 'on' and 'off'
     Default is [on]
  -s the hostname where Access Manager server is running
     Default is [pcatd11]
  -p the port number on which the Access Manager server is listening
     Default is [20000]
  -L the log directory where the log files are written
     Default is [/home-users/mleahu/logs/]
  -l the log level. Can be one of the following:
        NONE            - no logs at all
        NORMAL          - log the errors and warnings
        VERBOSE         - log the information messages
        VERY_VERBOSE    - log the configuration messages
        DEBUG           - log the debug messages
        ALL             - log all the messages
     Default is [NORMAL]
  -h this info

Access Manager shell scripts

These scripts may require extra privileges to manipulate users roles so that only AM administrators are able to add and revoke roles.

amRoles
Access Manager shell interface for roles manipulation

Usage: amRoles [-a|-r|-e|-d roleid] [-s|-S ] [-u username] [-m userBindDN] [-M] [-p password] [-l ldapserver] [-b basedn] [-h] [-v]
  -a assign the  to the 
  -r revoke the  for the 
  -e enable the  for the 
  -d disable the  for the 
    DO NOT ADD/REMOVE/ENABLE/DISABLE ROLES IN THE SAME TIME!
  -s show the roles assigned to the user
  -S show the roles assigned and enabled to the user
  -u user name; default is the current user [mleahu]
  -m authenticate as  to the LDAP server; default is 
  -M authenticate as [cn=    
      Manager] to the LDAP
  server -p password to       bind to the
  LDAP server -l use           this ldapserver; defaultis[atd-ldap.cern.ch]-busethisbasedn;defaultis[ou=tdaq,ou=atlas,o=cern,c=ch]
  -v verbose mode
  -h this info
amAdminDumpRoles
    

     Dump the roles from
  LDAP Usage: amAdminDumpRoles [-l ldapserver] [-b
  basedn] [-v] [-h] -l use thisldapserver;defaultis[atd-ldap.cern.ch]-busethisbasedn;defaultis[ou=tdaq,ou=atlas,o=cern,c=ch]
  -v verbose mode
  -h this info
amAdminUpdateRoles
Update the roles assignment in LDAP using the 'amRoles' script.
IMPORTANT: The 'amRoles' should be in the path!.

Usage: amAdminUpdateRoles [-f inputfile] [-r]
  -f input file with 'username: role1 role2' on each line
  -r refresh the roles, i.e. revokes all the roles before new assignment
  -h this info