Documented second release of the security infrastructure and APIs

IST-2001-32133

GridLab - A Grid Application Toolkit and Testbed

Documented second release of the security

infrastructure and APIs

Author(s): Marcin Adamski, Radoslaw Strugalski, Tomasz Kuczynski,Krzysztof Kurowski, Jarek Nabrzyski

Document Filename:

Work package: WP6 Security

Partner(s): PSNC, MPG, MU, ISUFI

Lead Partner: Poznan Supercomputing and Networking Center

Config ID: GridLab-6-D6.5-0005-0.9

Document classification: INTERNAL

Abstract: In this document, a description of implementation and tests of the second releaseof the Grid Authorization Service developed as a part of WP6 of the GridLabproject is presented.

Last amendment date: 2005/01/28 & time: 10:30:00

Documented second release of the securityinfrastructure and APIs IST-2001-32133

Contents

1 Introduction 3

1.1 Purpose of Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Structure of Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Status of Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Goals and requirements for the second release of the GAS 4

3 Logical structure of GAS 5

3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 The GAS server - logical structure . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Data structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Physical structure of GAS 9

4.1 GAS server application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.2 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.3 GAS management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2 GAS clients applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.3 The GAS administration Portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4 Communication between components . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Integrations and cooperation 17

5.1 Integrations with GRMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.2 Integrations with Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.3 Integrations with Mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.4 Integrations with Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.5 Integration with iGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.6 Integrations with Globus Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Scenarios 22

6.1 The ”simple” scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6.2 The ”cancel” scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

GridLab-6-D6.5-0005-0.9 INTERNAL 1/53


7 The future of the GAS 26

7.1 GAS integration with the SAML technology and XACML . . . . . . . . . . . . . 26

7.2 Integration with callouts from the Globus Toolkit 4.0 . . . . . . . . . . . . . . . . 26

7.3 Distinguishing between local and global GAS servers . . . . . . . . . . . . . . . . 26

7.4 Simplifying the GAS server administration methods . . . . . . . . . . . . . . . . 26

7.5 Support for the RBAC model (continuing works) . . . . . . . . . . . . . . . . . . 27

7.6 Extending scenarios functionality of the GAS . . . . . . . . . . . . . . . . . . . . 27

8 Summary 28

9 Appendix A - GAS Server Installation Manual 29

10 Appendix B - GAS Administration and User Guides 34

10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

10.2 GAS Administration Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

10.3 GAS Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

11 Appendix C - GAS Portlet Administrator’s Guide 45

11.1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

11.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

11.3 Installing the GAS portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

11.4 Configuring the GAS portlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

11.5 Configuring GAS portlet - service settings . . . . . . . . . . . . . . . . . . . . . . 46

11.6 Configuring the GAS portlet - connection settings . . . . . . . . . . . . . . . . . 46

12 Appendix D - GAS Portlet User’s Guide 48

12.1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

12.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

12.3 GAS Portlet Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

12.4 Using GAS Portlet - subtabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

12.5 Using the GAS Portlet - a tree view . . . . . . . . . . . . . . . . . . . . . . . . . 49

12.6 Using the GAS Portlet - operations on the GAS subjects . . . . . . . . . . . . . . 49

12.7 Using the GAS Portlet - operations on GAS groups . . . . . . . . . . . . . . . . . 49

12.8 Using GAS Portlet - GAS relations . . . . . . . . . . . . . . . . . . . . . . . . . . 51

12.9 Using the GAS Portlet - operations on the GAS relations . . . . . . . . . . . . . 51



1 Introduction

1.1 Purpose of Document

This document contains information about the second release of the Grid Authorization Service.Specifically it is focused on issues like building the GAS service, state of integration with otherworkpackages and future plans for the GAS service.

1.2 Structure of Document

The document is divided into 8 general sections and 5 appendices.

In section 1, a general document structure and its goals are presented.

In section 2, the main goals and requirements for the GAS are shown.

Sections 3 and 4 describe the general design of the Grid Authorization Service from the logicaland physical point of view. Internal and external components as well as communication methodsbetween them are described here.

In Section 5, integrations with external services are presented.

Section 6 is dedicated to a description of possible scenarios, which can be used for the secondrelease.

Section 7 contains information on possible future extensions to GAS.

The summary and final notes are given in section 8.

There are five appendices which describe main GAS components manuals and guides.

Appendix A. GAS Server Installation Manual

Appendix B. GAS Administration and User Guides

Appendix C. GAS Portlet Administrator’s Guide

Appendix D. GAS Portlet User’s Guide

1.3 Status of Document

This document is a working draft and refers to the current state of the project. As a workingdraft, this specification may be updated, replaced, or made obsolete at any time. It is distributedfor discussion purposes only, and should not be used as a reference.



2 Goals and requirements for the second release of the GAS

The main requirements for Security Workpackage 6 in the GridLab project have been presented inthe first deliverable, WP6 Security: Initial Requirements [2]. In the following deliverable entitledTechnical Specification for Authorization Service [1], the architecture and structure of GAS isdescribed. The general overview of the first prototype was presented in the Implementation andTest Plan [3]. The next deliverable describes the first release of the Grid Authorization Service.On the basis of these four deliverables, the second release of the Grid Authorization Service isdeveloped.

Each authorization service has to provide functionality, shown below:

• getting a single authorization decision for the user,

• getting part of the security policy for the user,

• managing the authorization service.

In the second release of GAS, all these functionalities are included for two authorization securitymodels: RAD (the Resource Access Decision) and RBAC (the Role Based Access Control). Thesecond release of GAS is developed in accordance with the Technical Specification for Autho-rization Service [1], where the main goals of the Grid Authorization Service are presented:

• The main requirement is flexibility of the Grid Authorization Service. GAS is about toprovide a universal way of defining the security policy for the whole Grid, independentlyof technologies used at lower levels;

• It should be able to implement most security models for Grids and use many differentscenarios at the same time;

• It should support many different security technologies;

• There has to be secure and stable implementation, as GAS is considered as a trustedcomponent of the security model.

Based on such requirements and goals, with the first release of GAS it is possible to:

• create a structure for the security policy based on services requirements with time orcapability limitation;

• add the security policy to the GAS server by a special administration client or web ad-ministration client and store this policy inside a database;

• generate the authorization decision for a user or service;

• generate part of the security policy for a user or service (based on rules defined by theservice);

• generate full security policy for a user or a service (in this mode GAS can be in the CASscenario [1] ) and can be compatible with CAS (the Community Authorization Service);the generated policy can be used with the CAS enabled components (like gsiftp) [4];

• present the security policy in text form (in gas_admin_client and in protlet in Grid-sphere).



3 Logical structure of GAS

In the first subsection (3.1) a short overview of the GAS architecture is presented. In subsection3.2, there are a few words about the GAS server logic written. A very important part of thischapter is subsection 3.3 in which data structure used by the GAS server is shown.

3.1 Architecture

GAS was prepared in typical a client-server architecture. The main part of the system is theGAS server, which is responsible for all authorization and management actions. All interactionswith the GAS server are performed by clients. There are two types of clients:

Figure 1: The GAS architecture

• administration clients - which are for the GAS server configuration and management used

• standard clients - which typically take from the GAS server authorization decision orsecurity policy



3.2 The GAS server - logical structure

The GAS server has a modular structure. This structure was described in the deliverable entitledthe Technical Specification for Authorization Service [1]. Logically, the GAS server consists offives items. Three items ( which are all together named core) are closely placed in the heart ofthe GAS server:

• Authorization and Security Policy Engine,

• Scenario Engine,

• Communication Components,

and two more external:

• Authorization Scenario,

• Database Module.

The structure and communication between these modules are presented in the figure below.

SERVER Communication libraryCommunication library

Authorization Scenario Database Module

CORE

Authorization

and Security

Policy Engine

Communication

Components

Scenario

Engine

Communication library

Scenario File Database server

Clients

Figure 2: The GAS core



The most complicated item is the Scenario Engine, which is responsible for all authorizationprocesses and managing security policies. All security policy rules are stored inside the GASserver database. Rules are read or written from the database to the data structure by theDatabase Module. The Scenario Engine module is responsible for managing scenarios, whichare performed by the GAS server. From this module information about user sessions can betaken. The Communication Component is responsible for all communication with externalclients. This module performs all outside GAS messages and sends them to the correct internalcore module. Also, all internal communication between core modules is done through thismodule. In the future the modular structure of the GAS server makes it possible to use variousexternal communications protocols and various database systems without modification of corecomponents.

3.3 Data structures

The building of the data structure for the GAS server results from security authorization models,which are supported by the GAS server. Generally, such models are described using the followingentities:

• object - entities like servers, files, web pages; the items security policy can be defined for;

• operation - an action which can be performed on objects;

• subject - a user or others entities which want to perform operations on objects;

• role - the special contexts in which subjects want to perform an operation on an object;

• relation - the simple security policy rule, for the RAD model, relation defines the objecton which the user can perform an operation;

• permission - the simple security policy rule for the RBAC model.

In the GAS server the structure of objects definitions is designed to enable creating accuraterepresentations of the world. Generally, this structure looks very complex but it was created insuch a way for the following reasons:

• the world is complex, so structures that describe the world can hardly be simple;

• all items of the world have to be connected into one structure to return unambiguousauthorization decision;

• managing the security policy has to be unambiguous and easy.

This structure, presented in figure 4, is a multi-layered graph which can be used in differentimplementations. In the GridLab environment two layers can be distinguished: physical andlogical. On the physical layer the network items can be placed as: servers, files, web pages andetc. On the logical layer the items can be placed as: services, resource, queue and jobs. On eachlayer all objects are connected into the graph structure.

Each object can be connected to its own set of operations (describing what kind of actions canbe performed on an object). The structure of the operation is not complex. In figure 5, a samplestructure for operations which can be connected to the object from figure 4 is presented.



GRMS_DEF

DN

submitJob

suspendJob

resumeJob

...

SERVER_DEF

DN

URL

IP

access

FILE_DEF

URL

read

write

execute

definition name

operations

attributes

Figure 3: Data structure - a definition structure of sample objects which can be used in GridLab

The structure of subjects is hierarchical starting from groups at the top level and with detailedsubjects at the bottom level. Groups can contain other groups and subjects. In the samplesolution for GridLab, a Virtual Organization object is on the top and groups of users are placedbelow (figure 6).

Relation (the security policy rule for the RAD model) and permission (the security policy rulefor the RBAC model) structures are shown in figure 7.

Relations are created in context of object (an object can have array of relations) and connectitems like:

• operation which can be performed on object;

• subjects or group of subjects;

• array of limitations;

• relation attribute (positive or negative relation).

Permission connects the same items as relation but in context of role are created. Each relationor permission defines one security policy rule.

In the first prototype, GAS was using a simple data structure that contained only a simple arrayof objects. Using this data structure, it was possible to test only one operation on an object -



job003job

job002job

gridlab003virt account


GridLabGrid

Rage1server

GL_TestbedTestbed

Rage2server

eltoroserver

GRMSRB_service

iGridIG_service

MBSMBS_service


adamsaccount

markaccount

mikeaccount

homefile

/homefile

homefile

/home/adamfile

job001job

Layer 2 Layer 1

Figure 4: Data structure - a definition structure of sample objects which can be used in GridLab

the access operation. This structure is still supported in the second release but can be used onlywhile working with text files.

4 Physical structure of GAS

The GAS server is the main and the most important component of the GAS service. Thisprogram is placed at the central point of the system and all other components are connectedto this item. Information on how to run this server and what the startup parameters look likeis given in subsection 4.1. The detailed information about the GAS server can be found insubsections listed below:

• structure of the database (4.1.1),

• methods of the GAS server management (4.1.3),

• API provided by the GAS server (4.1.2).

The GAS client applications in subsection 4.2 are described. A separate section describes theGAS server management portlet 4.3. There is a special section (4.4) about communicationmethods between the GAS components included.



Name: Rage1Def: SERVER

SERVER

DN

URL

IP

access

/C=PL/O=GRID/O=PSNC/CN=host/rage1.man.poznan.pl

rage1.man.poznan.pl

150.254.173.166

Figure 5: Data structure - sample operations for object definitions

4.1 GAS server application

The GAS server was designed as a separate program named gas_server. The path to the configfile is the only parameter for this program. In the config file there are a few parameters available:

• StructureFile - a path to the file which contains the structure of data for the GAS server.This path was used for the first prototype of GAS, when the database was taken from thetext file but it is still possible to work with this structure and use it in simple applications;

• DatabaseFile - a path to the file which covers the security policy database. This pathwas used for the first prototype of GAS similarly to the path from the ”StuctureFile” key,it is still possible to read data from text files;

• Server_Certificate - a path to the file which covers the server certificate in the X.509format;

• Server_Private_Key - a path to the file which covers the server private key;

• Server_Certificate_Dir - a path to the directory which contains all CA certificatesacceptable by the GAS server;

• LogFile - a path to the log file where all information about events into the GAS serverwill be stored

• PortGSI - a port number for GSI connections;

• PortSOAP - a port number for gSOAP connections;

• ExtLogModule- a path to the log library;

• RootDN - defines root user for the GAS server.

A sample configuration file is presented below:

StructureFile=/home/gas_user/test.tt

DatabaseFile=/home/gas_user/testDB.tt

Server_Certificate=/home/gas_user/.cas/usercert.pem

Server_Private_Key=/home/gas_user/.cas/userkey.pem



/

VO_GridLabVO

VO_CrossGridVO

Grou1Group

Group2Group

adamsUser

piotrgUser

MBSService_user

GRMSService_user

Group3Group

Group4Group

Group5Group

marcinpUser

pawelwUser

Figure 6: Data structure - a sample structure of subjects and groups

Server_Certificate_Dir=/home/gas_user/.cas/certificates

LogFile=/home/gas_user/.cas/gas.log

PortGSI=12351

PortSOAP=12350

ExtLogModule=/home/adamski/gas/logso/liblogging.so

RootDN=/C=PL/O=GRID/O=PSNC/CN=Marcin Adamski

A sample command of running GAS:

/gas_server/bin/gas_server /gas_server/sbin/config.gas&

The GAS server is written in the standard ANSI C. The package contains the GAS server isdelivered as tarball gzip file. The structure of package looks as:

• bin - directory contains the gas_server program,

• sbin - directory contains scripts for the gas_server program,

• lib - directory contains dynamic and static libraries for the gas_server program.

The multithreaded technology is used inside the GAS server to support many external requests.

4.1.1 Database

In the second release of GAS it is possible to store the data structure into an external SQLdatabase server. The GAS server uses the unixODBC library to connect to the SQL server.



Figure 7: Data structure - structure of policy rule for the RAD and the RBAC models

Using the unixODBC driver is the only requirement for selecting a specific database system.It is important to mention that during internal tests the GAS server was used only with theMySQL database server, thus this database server is used by the GAS service for the GridLabfinally.

There are 31 tables defined:

• ObjectDef - the table contains objects definitions which cover information like objectname, layer and id;

• SubjectDef - the table contains subjects definitions which cover information like subjectname and id;

• RoleDef - the table contains roles definitions which cover information like role name andid;

• GroupDef - the table contains groups definitions which cover information like group nameand id;

• ObjectAttrDef - the table contains information about object attributes definitions;

• SubjectAttrDef - the table contains information about subject attributes definitions;

• RoleAttrDef - the table contains information about role attributes definitions;



• GroupAttrDef - the table contains information about group attributes definitions;

• OperationDef - the table contains information about object operations definitions;

• ObjectObjectDef - the table of connections between the ObjectDef;

• Object - the table contains information about objects based on the ObjectDef definition;

• Subject - the table contains information about subjects based on the SubjectDef defini-tion;

• Group - the table contains information about groups based on the GroupDef definition;

• Relation - the table contains information about relations;

• ObjectObjectChild - the table of connections between objects (from the same layer);

• ObjectObjectLayerDown - the table of connections between objects but from others layers;

• ObjectAttributes - the table contains information about objects attributes based on theObjectAttrDef definitions;

• ObjectRelations - the table of connections from relations to objects;

• RelationOperations - the table of connections from relations to operations;

• GroupSubjects - the table of memberships between groups and subjects;

• GroupGroupChild - the table of memberships between groups and groups;

• RoleSubjects - the table of connections from subjects to roles;

• RolePermissions - the table of connections from permissions to roles;

• Role - the table contains information about roles based on RoleDef definition;

• Permission - the table contains information about permissions;

• PermissionOperations - the table of connections from operations to permissions;

• AccessSec - the table contains internal rights to all GAS server objects;

• ConnAccessSecToRelations - helper table for the AccessSec table, contains informationabout relations used in the AccessSec table;

• ConnAccessSecRelationToSubject - helper table for the AccessSec table, specified whichsubjects are connected to the AccessSecRelation;

• ConnAccessSecRelationToGroup - helper table for the AccessSec table, specified whichgroups are connected to the AccessSecRelation;

• PolicyScheme - table contains format of security policy rules.

The GAS server can use multiply databases. It is possible to load the content of the databaseto data structures using a command from the gas_client_admin program. In the future, thedatabase module will be extended for support of all edit operations on databases. The modulewill be also thoroughly optimized especially for memory usage. Currently, the database is theonly place where the data integrity can be tested.



4.1.2 API

The gSAOP interface for the GAS server is presented below. This interface can be used byexternal services to access the GAS server functionality.

• ns__getServiceDescription - the function for getting standard service description; thefunction returns a string;

• ns__sendCommandAdminString - the function for sending command string to the server,this function returns a string;

• ns__getAuthorizationDecision - returns the authorization decision if the user can per-form a specific operation on a specific object;

• ns__getSignedAuthorizationDecision - the same as for functionns__getAuthorizationDecision but returns string signed by the GAS server;

• ns__getGeneratePolicyForSubject - returns the list of operations which can be per-formed by a specific user on specific object

• ns__getAccessibleObjectsList - returns all names of objects which can be accessibleby a specific user

• ns__setRegisterContext - create a new dynamic context (namespace, project)

• ns__getGeneratePolicy - returns policy for a specific user in user a specific format

• ns__getContextAccessibleObjectsList - returns all names of objects which can be ac-cessible by a specific user by in the context of specific search scope

• ns__getContextGeneratePolicy - returns policy for a specific user in user a specific formin the context of specific search scope

• ns__getContextAuthorizationDecision - returns the authorization decision if a user canperform a specific operation on a specific object in the context of specific search scope

Please note that this API refers to the current release of the GAS service. In the future, thisinterface will be changed and extended.

4.1.3 GAS management

Currently, there are four ways of the GAS server management:

• gas_admin_client;

• gas_client_admin_soap;

• portlet inside gridsphere;

• API function ns__sendCommandAdminString.



4.2 GAS clients applications

From the technical point of view the second release of GAS consist of eight components:

• gas_client_admin - this is a command line tool for adding new objects, subjects, at-tributes or other items to the security policy stored on the gas_server (see ??). Thisprogram communicates with the gas_server by a protocol compatible with GSI. Thecommand line string for this program is the following: gas_admin_client [-s server][-p port] [file_with_commands]. The ”server” parameter is the host domain name onwhich the gas_server runs at a port given by the ”port” parameter. The last parameteris the path to the script file which contains a set of commands for the gas_server. Allparameters are optional, but when the ”server” parameter is not given, the ”localhost”name is used instead. The default port number for the connection by the GSI protocolwith the gas_server is 12350.

• gas_client_admin_soap - this is a command line tool. This program is similar to thegas_client_admin with exception of the protocol used for communication. The gas_client_admin_soapuses the gSOAP protocol for communication with the gas_server. The command linestring for this program is as follows: gas_client_admin_soap [-s server] [-p port][file_with_commands].The ”server” parameter is the host domain name on which thegas_server runs at a port given by the ”port” parameter. The last parameter is the pathto the script file which contains a set of commands for the gas_server. All parametersare optional but when the ”server” parameter is not given, the ”localhost” name is usedinstead. The default port for the connection by the gSOAP protocol with the gas_serveris 12351.

• gas_client - this is a small program which obtains full security policy for the user from thegas_server and stores this policy into the CAS proxy file (this program is similar to cas-proxy-init [4]). This program communicates with the gas_server by the GSI protocol.The command line string for this program is the following: gas_client -s server -pport. The ”server” parameter is the host domain name on which the gas_server runs atthe port given by the ”port” parameter.

• gas_client_soap - this is a small test program which shows how the GAS server in-terface API functions works. This program communicates with the gas_server by thegSOAP protocol. The command line string for this program looks like that: gas_client-s server -p port. The ”server” parameter is the host domain name on which thegas_server runs at a port given by the ”port” parameter.

• gas_enabled_tcp_server - this is a sample server application which can use the securitypolicy that is provided by a client application (see gas_enabled_tcp_client). The com-mand line string for this program is as follows: gas_enabled_tcp_server [port], where”port” is the port number the server will be running on.

• gas_enabled_tcp_client - this is a sample client application which can use a cas proxyfile to access the gas_enabled_tcp_server. The command line string for this programis the following: gas_enabled_tcp_client [port], where ”port” is the port number theserver will be running on.

• cas_proxy_viewer - this is a tool for printing the security policy which is included intoa standard CAS proxy file or the GAS proxy file on the screen. The command line string



for this program is the following: cas_proxy_viewer [path_to_proxy_file], where the”path to proxy file” is the full path to a valid proxy file.

• gas_enabled_module - this is a library which can be included into a service for communi-cation with GAS and getting full or part of the security policy or the authorization decisionbased on the service request.

All these components are written in the C language.

4.3 The GAS administration Portlet

The GridLab Authorization Service interface consists of the portlet compliant with the Grid-Sphere API. The GAS Portlet can operate in four modes: view, configuration, edit and help.In the configuration mode it is possible to configure such connection parameters as the GASserver hostname and port number. Also default myproxy settings, and http/https settings forconnections between the WWW client and portal, can be set in that mode. In the edit mode theuser can make settings for the myproxy server, which should be used to obtain user’s credentials.The help mode allows to access GAS Portlet Guides. The view mode is the main part of theportlet. The portlet window in the view mode consists of 4 subtabs for making operations onGAS groups, GAS subjects and GAS relations. Data trees presented on panels of the portlet’ssubtabs reflect the GAS database structure. Performing simple operations on those trees allowsthe user to access most functionality of GAS including adding, removing groups and subjects,adding groups and/or subjects to relations, adding and removing operations in the relations.In order to use the GAS Portlet the user has to be familiarized with GAS concepts (howeverhe/she is not required to know the GAS command interface).

4.4 Communication between components

Generally, there are two ways of communication between different components of the GASservice:

• using its own protocol based on the GSI standard protocol;

• using the gSOAP protocol (gSOAP plugin for GSI);

The first protocol is used for communication between the GAS server and GAS internal compo-nents like gas_admin_client, gas_client. This protocol is faster than the second one but notfully universal. For this reason, it will be used only internally. With the second protocol it ispossible to establish communication between the GAS server and internal components, externalservices or portals. The second protocol is more universal and easy to use by anyone who wantsto communicate with the GAS server. Components and communication are presented in figure8.



Figure 8: Components and communication

5 Integrations and cooperation

With the availability of the second GAS release aimed at cooperation with different external ser-vices (provided by other workpackages) integrations have been finished. Below, a brief overviewof the status of the integration between the GAS service and other selected GridLab services isgiven, and information about integration with GLobus Toolkit components is provided.

5.1 Integrations with GRMS

The integration with GRMS was changed a lot in the past. The description below presents thecurrent status of the integration with GRMS

For the GRMS service there is a defined set of operations which can be performed on GRMS: ac-cess, findResources, submitJob, migrateJob, suspendJob, resumeJob, getJobsList, registerAppli-cationAccess, cancelJob, getServiceDescription, getAllJobsList, testJobDescription, getJobInfo,getJobHistory, registerNotification, unregisterNotification, addOutputFileDirs, getOutputFileDirs,deleteOutputFileDirs, addCheckpointFileDirs, getCheckpointFileDirs, deleteCheckpointFileDirs,getJobStatus, getHostName, getGlobusJobStatus, getProjectJobsList, registerProjectNotifica-tion, getNotificationInformation getNotificationsList.

Each request to the GRMS service can perform one or more operations defined above. Eachoperation is tested inside GAS if a specific user is authorized to perform such operation. Theauthorization decision is returned to GRMS.

Cooperation between GAS and GRMS is such a way is very easy to manage. The functionalityof GRMS is often extended and the set of operations is changed, too.



For some more complicated scenarios such level of cooperation is not sufficient enough and wasmuch extended. All job requests demand the authorization decision not only in the context ofan operation but in the context of a job. It is not easy to manage jobs because of their dynamicnature.

In such scenario GRMS creates jobs upon user request and by using the API function can createcorespondent object inside GAS. After creating special trigger constructs default security policyrules for such object. This functionality makes it possible for the user to manage his/her jobson the GRMS level and on the resources level (Globus Toolkit level).

Other not trivial scenarios which assume cooperation of a group of users and their jobs extendintegration GAS and GRMS. For this integration the ”project” functionality was added to GASand GRMS. The ”project”concentrates items presented below and relations between these items:

• group of user,

• their jobs,

• services used by these users,

• resources where jobs are run.

To get the authorization decision in the context of a specific ”project” a new set of API functionswas added to GAS. These functions need as input parameter string which represents ”project”.The ”project” functionality is very useful in situations when many users cooperate and it isnecessary to distinguish access rights to resources and other objects provided by these users.Such situation often occurs in the commercial word than in the scientist word.

Other types of integration between GAS and GRMS are accessible. The integrations presentedbelow were performed and tested but are not used currently:

• GAS can return upon the GRMS request a logical part of the security policy containingall operations which a specific user can perform on GRMS service,

• such policy can contain a list of resources which are accessible for a specific user,

• file rights can be tested in GAS for a specific user before copying or moving.

Integration with GRMS is treated as a pattern for integration between GAS and an externalservice. Based on this integration other ones were preformed.

5.2 Integrations with Monitoring

Integration with the Monitoring pressed on two levels:

• on the level on which Mercury gets the security policy from GAS,

• on the logging level.

Integration with the Monitoring system was one of the most difficult. It was the first integrationwhere not a single authorization decision was returned but a logical part of the security policy.Logically, this integration relies on getting the default security policy rules from GAS when theMonitoring system starts to work. The limitation was that the Monitoring system understands



policy rules in a specific form. So the API function was delivered which makes it possible tospecify the format of the returned policy rules (this function was prepared in a more universalform and can used in other applications too). A sample data structure which are used for theMonitoring stem is presented in figure 9.

Figure 9: Monitoring objects inside the GAS

The second integration concerns the possibility of storing the logging information coming fromGAS (and other services) in a special Monitoring service. The new module, as a part of theGAS server, containing interface for any external logging interface, was defined and created.This module use a dynamic libraries for communication with external services. Informationwhich a dynamic library has to be loaded to GAS is in the GAS config file stored (4.1) . For themonitoring logging service, interface was put to a separate dynamic library.

5.3 Integrations with Mobiles

The integration with Mobile services was divided into three integrations:

• Notification Service,

• Message Box Service,

• Mobile Command Center,

The integration with the Notification Service on the communication level is similar to the in-tegration with GRMS but logically differs significantly. Beside standard testing if the user can



perform operation on the Notification Service, a special type of object which represents a mes-sage receiver was added. The policy for such object contains information if a specific user whois connected to this object wants to receive messages like: SMS, emails and others.

The functionality of ’negation’ of rules were implemented and for the first time used in thecontext of this integration. At first, the ’ReceiversRoot’ object and one ’negation’ relation forthis object was defined which denies all operations for all users. Next the ’Receiver’ objects weredefined with positive relation which describes who can send which type of messages to a specificreceiver.

The integration with the Message Box Service (MBS) was easier than others, and it amounts totesting if the user has his/her access right to the MBS service.

The integration with the Mobile Command Center (MCC) is more interesting, and based on theMCC request, the security policy is returned to the MCC service. This security policy containsa list of objects (for this integration it is list of projects) which can be accessible for a specificuser.

Similarly to GRMS the ”project” functionality was added to the integration with all mobileservices. All operations for mobile services can be tested in the context of ”project” inside GAS(more information is included inside subsection 5.1)

5.4 Integrations with Portal

The integration with the Portal group was not a standard integration but more like gettingsupport and advice on how to create a good and useful portlet based on the gridsphere framework.During the integration of the GAS service with the portal, a dedicated portlet for the GASadministration was designed and implemented. The GAS portlet allows to perform variousadministration operations including:

• adding new DN to GAS,

• managing GAS DNs, groups and objects,

• managing GAS relations,

• changing the relation owner and rights,

• changing the list of operations for the relation,

• adding groups and users to the relation.

GAS objects are presented in the GAS portlet with tree views. The mentioned portlet is Grid-sphere API compliant.

5.5 Integration with iGrid

The integration with the iGrid service was performed in two steps. In the first stage the securitypolicy was added to the GAS server for the iGrid service with three objects ( iServer, iStore,iService) and three actions for the iService object (register, unregister, store). In the second stage(on request from the iGrid workpackage) a new interface function was prepared, which returnsall actions, for the specific object, which the user is allowed to do. These functions can be usedin other integrations, integration with iGrid is practically used iGrid on rage1.man.poznan.pltests users rights in the GAS server.



5.6 Integrations with Globus Toolkit

The GAS server is integrated with the Globus Toolkit by two Globus plug-ins, so called, ”call-outs”. Callout is a standard way to customize authorization and job management in Globus.There are two available callouts provided by Globus GT 3.2. pre WS:

• Gridmap plug-in,

• GRAM plug-in.

Both were used during the integration of the GAS server to fully benefit from all featuresprovided by GAS and Globus. In order to communicate with GAS, the plug-ins use the GSIenabled gSOAP protocol.

The first plug-in uses information gathered by the GAS service to get account information andobtain the authorization decision. When such services as the Globus gatekeeper or gridFtp needto perform mapping a user to an account and get the authorization decision, they try to checkwhether an external Gridmap callout is enabled and, if so, call it instead of the standard au-thorization routines. Naturally, when from some reasons the GAS plug-ins cannot communicatewith the GAS server, Globus falls back to the internal authorization procedures.

The second plug-in is responsible for the authorization of every operation to be performedon a particular job. This allows for the fine grained control of all jobs flowing through theGlobus Toolkit. The plug-in is invoked by the Globus Job Manager for such operations likestart or cancel job. In such case the GRAM plug-in asks the GAS server for the authorizationdecision on a given operation and basing on it takes proper actions. The work over those twoplug-ins is finished and now they are both heavily tested on several GridLab testbed machines(fs0.das2.cs.vu.nl, rage3.man.poznan.pl and elthoro.pcz.pl).



6 Scenarios

In this section sample scenarios are described which present how GAS can be used in multiservices environment. In the first subsection the ”simple” scenario is presented. In the nextsubsection a more complicated scenario named the ”cancel” scenario is described.

6.1 The ”simple” scenario

Figure 10: The simple scenario

The ”simple” scenario describes possible interaction between GAS and other services. In thisscenario GAS can be managed from the GAS administration portlet. The authorization decision



is returned as a simple single response for the external service request. All Globus resourcescan be integrated with GAS by using Globus callout mechanisms which is used by GAS plugins.The security policy stored on the GAS server has to describe the external service (in figure6.1 GRMS), resources and users that can perform operation on these objects. In the examplepresented in figure 6.1 two types of questions are allowed:

• GRMS can ask the GAS server generally if users can perform operations like submit job,cancel job, suspend job, resume job and others on the GRMS service

• resources can ask the GAS server if a specific user can perform operations on a specific joblike: submit, status , register and unregister.

6.2 The ”cancel” scenario

”The Cancel Scenario” was introduced to show collaboration between users working in the sameworkgroup or virtual organization. It also demonstrates cooperation between different com-ponents, in particular between the GAS server and Globus GAS plugins described later inAppeendix B [10]. User ”A” will start a new job and let his/her co-worker, user ”B” supervisethis job. Eventually, he/she may restart the whole job with changed input parameters, as it isshown in this scenario.

In short ”the Cancel Scenario” constitutes of the following steps:

• setting the project policies for users A and B,

• user A submits a job using the GRMS portlet,

• user B gets a notification via SMS saying that the job has been started by user A,

• user B obtains partial visualization data,

• user B cancels the job and reruns it with modified input data.

A detailed description:

1. User A defines policies for the whole project using the GAS portlet.

2. User A submits a job using the GRMS portlet which is later registered in the GAS serverby the GRMS service itself. The GAS server knows the JobID.

3. User A adds an SMS notification for users A and B, so they can know the status of thejob as the execution follows. The notifications are managed by the GRMS service.

4. In the meantime, GRMS asks for permission to run the job and after a positive decisionit submits the job to Globus. On the Globus level the Job Manager commences the jobexecution right after it gets permission to start the job identified by the JobID. After that,the GRMS service gets notified and initiates via the Mobile Services an SMS notificationfor user B.

5. After some time user B decides to retrieve partial job results. Because of some reasonsthe input data have to be corrected, user B decides to cancel the current job and rerun itwill changed input parameters.Using a mobile device user B sends a cancel command tothe GRMS service, which is then authorized by the GAS service. GRMS passes the cancelrequest to Globus similarly as the submit request.



6. Globus sends a cancel notification to GRMS which is further translated into an SMSnotification to user B. Now he/she can submit the job again with changed input data.

Figure 11: The cancel scenario

Technically, this scenario is very interested because of using two new techniques:

• project functionality,

• possibility of adding dynamic policies.

The project functionality makes it possible to specify context of the authorization decision. Itmeans that for two projects which use the same object the authorization decision can be different.



In GAS each object has its main instance in the hierarchical structure which unambiguouslyidentifies this objects and can have more than one shortcut to this object. For each shortcut wecan specify a separate policy.

Dynamic policies give a possibility to add a new object to the GAS server at runtime. Specialtriggers add security policy for such items. In the described scenario this functionality for jobsstarting on resources by the GRMS service is used. GRMS adds job objects to the GAS serverand special trigger adds security policy for this job. The job owner can now specify which otherusers can cancel the running job on a resource while the scenario is running

Each scenario, which can be used for the GRMS integration and the Portal integration, needstwo simple features:

• it has to be possible to manage the GAS server,

• it has to be possible to return the authorization decision upon the user request.



7 The future of the GAS

The following aspects which will probably be discussed and maybe introduced to GAS arepresented:

• GAS integration with the SAML technology (we will probably provide our own SAMLimplementation),

• Integration with callouts from Globus Toolkit 4.0,

• Distinguishing between local and global GAS servers, preparing architecture for such sys-tem and communication between components,

• Simplifying of the GAS server administration methods,

• Support for the RBAC model (continuing works),

• Extension of the ”scenarios functionality”:

7.1 GAS integration with the SAML technology and XACML

SAML is one of the most often used technology for communication with secure services. Makingit possible to use this technology for the communication with GAS can improve the securitydegree and enable using GAS in numerous new solutions ([5], [6]).

7.2 Integration with callouts from the Globus Toolkit 4.0

Similarly to callouts from Globus Toolkit 3.2, developing a new callouts will extend list ofscenarios which will be supported by GAS. This make it possible to get the authorization decisionfor other components of the Globus Toolkit (until now there have been two GAS plugins, allaccessible plugins are described in section 5.6)

7.3 Distinguishing between local and global GAS servers

While developing GAS, two main problems occurs. The first problem concerns communicationwith GAS in a situation when a lot of users want to get the authorization decision from GAS.The second problem concerns the size of security policy stored on the GAS server. To avoid thisproblem a new GAS architecture was proposed (see figure 12), which distinguishes between localand global GAS. The nature of such solution divides network communication for more than oneGAS server. On the other hand, local GASes can contain a policy which is important only fromthe local services’ point of view (which cooperate with the local GAS). Information which ismore important from the global point of view will be stored on the global GAS. How to dividepolicy for local and global is not easy and still an open question.

7.4 Simplifying the GAS server administration methods

One of the main problem of authorization services is the problem of administration. Numeroussystems are good but very complex to manage.There is a plan to simplify the GAS serveradministration methods by:



Figure 12: The GAS architecture

• extension of the GAS administration portlet (which is currently prepared more for gridsolutions),

• preparing a system of rules and templates (which can be used to multiply objects or users).

7.5 Support for the RBAC model (continuing works)

The RBAC security model in a very good form maps the real word. This feature makes RBACvery attractive for a lot of solutions. While developing GAS, the main effort was put to implementthe RAD model, and not all aspects of the RBAC model were implemented and tested. Especiallythe ”project” functionality and the GAS administration portlet do not support the RBAC model.

7.6 Extending scenarios functionality of the GAS

The general idea of scenario functionality was introduced and is used in the GAS server. A feweasy extensions can make the GAS server more attractive for potential users. Features whichare missing in GAS are presented below:

• user sessions inside the GAS server,

• preparation of the ”state machine” on which scenarios can be run.



8 Summary

At the end of the GridLab project, a summary has to be given. The second release of GASis a fact. GAS is ready to work and integrate with many workpackages. Functionality of thedelivered software significantly extends assumptions from the first deliverables. By integrationswith many workpackages, it was found what good integrations have to look like and what theanticipations of other workpackages could be. After three years of creating and developing theauthorization system, a full package of software is ready and can be used in external projectsand systems. It was not easy to develop the security system, because security is not a trivialproblem, and all proposed solutions for such system have to be well thought-out. Experiencesgained during the GridLab project will be very useful in the future, helping to use GAS in otherprojects like InteliGrid, HPC-Europe and others. It was found what new useful functionalitycan be added to GAS, and what improvement will be very much desired by new services andprojects.

A nice feature of GAS is flexibility which gives a possibility to use GAS not only in Gridsolutions. A complex data structure and using SQL database for storing data helps to modelcomplicated real world used in many advanced applications. Preparing special plugins for theGlobus Toolkit gives a possibility to create a complex system in which security is a priority oneach layer. Probably only such systems can give us an adequate level of trust. One of the mainproblems of the authorization service is administration. When administration is too complicated,it discourages potential users. In GAS a very useful authorization portlet is accessible, whichgives users a possibility to manage GAS in an easy graphic form. Only such web portlet canhide the complex structure of GAS and gives a possibility to present this structure in a morefriendly form. All features described above make GAS attractive for people who set security ontop of requirements for their projects.

So in our opinion, the GAS service is one of the successes of the GridLab project and will bevery useful for many grid and non grid solutions.



9 Appendix A - GAS Server Installation Manual

Information about GAS server installation presented below comes from INSTALL file which isadded to all distribution of GAS server.

Basic Installation ==================

These are generic installation instructions.

The ‘configure’ shell script attempts to guess correct values for various system-dependent variables used during compilation. It uses those values to create a ‘Make-file’ in each directory of the package. It may also create one or more ‘.h’ filescontaining system-dependent definitions. Finally, it creates a shell script ‘con-fig.status’ that you can run in the future to recreate the current configuration,a file ‘config.cache’ that saves the results of its tests to speed up reconfigur-ing, and a file ‘config.log’ containing compiler output (useful mainly for debug-ging ‘configure’).

If you need to do unusual things to compile the package, please try to figure outhow ‘configure’ could check whether to do them, and mail diffs or instructions tothe address given in the ‘README’ so they can be considered for the next release.If at some point ‘config.cache’ contains results you don’t want to keep, you mayremove or edit it.

The file ‘configure.in’ is used to create ‘configure’ by a program called ‘auto-conf’. You only need ‘configure.in’ if you want to change it or regenerate ‘con-figure’ using a newer version of ‘autoconf’.

The simplest way to compile this package is:

1. ‘cd’ to the directory containing the package’s source code and type ‘./config-ure’ to configure the package for your system. If you’re using ‘csh’ on an old ver-sion of System V, you might need to type ‘sh ./configure’ instead to prevent ‘csh’from trying to execute ‘configure’ itself.

Running ‘configure’ takes a while. While running, it prints some messages tellingwhich features it is checking for.

2. Type ‘make’ to compile the package.

3. Type ‘make install’ to install the programs and any data files and documenta-tion.

4. You can remove the program binaries and object files from the source code di-rectory by typing ‘make clean’.

Compilers and Options =====================

Some systems require unusual options for compilation or linking that the ‘config-ure’ script does not know about. You can give ‘configure’ initial values for vari-ables by setting them in the environment. Using a Bourne-compatible shell, you cando that on the command line like this: CC=c89 CFLAGS=-O2 LIBS=-lposix ./config-ure

Or on systems that have the ‘env’ program, you can do it like this: env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure

Compiling For Multiple Architectures ====================================



You can compile the package for more than one kind of computer at the same time,by placing the object files for each architecture in their own directory. To dothis, you must use a version of ‘make’ that supports the ‘VPATH’ variable, such asGNU ‘make’. ‘cd’ to the directory where you want the object files and executablesto go and run the ‘configure’ script. ‘configure’ automatically checks for the sourcecode in the directory that ‘configure’ is in and in ‘..’.

If you have to use a ‘make’ that does not supports the ‘VPATH’ variable, you haveto compile the package for one architecture at a time in the source code directory.After you have installed the package for one architecture, use ‘make distclean’ be-fore reconfiguring for another architecture.

Installation Names ==================

By default, ‘make install’ will install the package’s files in ‘/usr/local/bin’,‘/usr/local/man’, etc. You can specify an installation prefix other than ‘/usr/local’by giving ‘configure’ the option ‘-prefix=PATH’.

You can specify separate installation prefixes for architecture-specific files andarchitecture-independent files. If you give ‘configure’ the option ‘-exec-prefix=PATH’,the package will use PATH as the prefix for installing programs and libraries. Doc-umentation and other data files will still use the regular prefix.

If the package supports it, you can cause programs to be installed with an extraprefix or suffix on their names by giving ‘configure’ the option ‘-program-prefix=PREFIX’or ‘-program-suffix=SUFFIX’.

Optional Features =================

Some packages pay attention to ‘-enable-FEATURE’ options to ‘configure’, where FEA-TURE indicates an optional part of the package. They may also pay attention to ‘-with-PACKAGE’ options, where PACKAGE is something like ‘gnu-as’ or ‘x’ (for the XWindow System). The ‘README’ should mention any ‘-enable-’ and ‘-with-’ optionsthat the package recognizes.

For packages that use the X Window System, ‘configure’ can usually find the X in-clude and library files automatically, but if it doesn’t, you can use the ‘config-ure’ options ‘-x-includes=DIR’ and ‘-x-libraries=DIR’ to specify their locations.

Specifying the System Type ==========================

There may be some features ‘configure’ can not figure out automatically, but needsto determine by the type of host the package will run on. Usually ‘configure’ canfigure that out, but if it prints a message saying it can not guess the host type,give it the ‘-host=TYPE’ option. TYPE can either be a short name for the systemtype, such as ‘sun4’, or a canonical name with three fields: CPU-COMPANY-SYSTEM

See the file ‘config.sub’ for the possible values of each field. If ‘config.sub’isn’t included in this package, then this package doesn’t need to know the host type.

If you are building compiler tools for cross-compiling, you can also use the ‘-target=TYPE’option to select the type of system they will produce code for and the ‘-build=TYPE’option to select the type of system on which you are compiling the package.

Sharing Defaults ================

If you want to set default values for ‘configure’ scripts to share, you can cre-ate a site shell script called ‘config.site’ that gives default values for vari-ables like ‘CC’, ‘cache_file’, and ‘prefix’. ‘configure’ looks for ‘PREFIX/share/config.site’



if it exists, then ‘PREFIX/etc/config.site’ if it exists. Or, you can set the ‘CON-FIG_SITE’ environment variable to the location of the site script. A warning: notall ‘configure’ scripts look for a site script.

Operation Controls ==================

‘configure’ recognizes the following options to control how it operates.

‘-cache-file=FILE’ Use and save the results of the tests in FILE instead of ‘./con-fig.cache’. Set FILE to ‘/dev/null’ to disable caching, for debugging ‘configure’.

‘-help’ Print a summary of the options to ‘configure’, and exit.

‘-quiet’ ‘-silent’ ‘-q’ Do not print messages saying which checks are being made.

‘-srcdir=DIR’ Look for the package’s source code in directory DIR. Usually ‘con-figure’ can determine that directory automatically.

‘-version’ Print the version of Autoconf used to generate the ‘configure’ script,and exit.

‘configure’ also accepts some other, not widely useful, options.

unixODBC ========

The unixODBC is required for compiling the GAS server. Please use ’-with-unixODBCswitch to specify correct path pointing to the unixODBC installation. If is notset installation program looks to the unixODBC installation directory: /usr /usr/local

Globus toolkit ==============

$GLOBUS_LOCATION environment variable have to be specified so that location of theGlobus toolkit installation could be properly located.

Installation step by step =========================

1. Install the unixODBC drivers (look for more information at: http://www.unixodbc.org,GAS was tested with versions 2.2.5, 2.2.6, 2.2.7, 2.2.8, 2.2.9, 2.2.10)

2. Install Globus Toolkit (look for more information at: http://www.globus.org,GAS was tested with versions 3.2.0 and 3.2.1)

3. Check if the $GLOBUS_LOCATION and the $LD_LIBRARY_PATH environment variableswere set correctly

4. Install version of the SQL server which has drivers compatible with the unixODBC.GAS was tested using the MySQL server in version number from 4.0.13 to 4.0.18

5. Under the SQL server create a new user account named gas_admin. You can usethe following command: create user gas_admin password <your_password>

6. Logon to this new user account and create database named GAS (create databasenamed GAS)

7. Modify the odbc.ini file like as shown below. Depends on configuration the .odbc.inifile have to be modified in the user home directory or the /etc/odbc.ini file (seethe unixODBC manual for more information)

[GAS] Driver = /usr/local/lib/libmyodbc3.so Description = MySQL ODBC 3.51 DriverDSN SERVER = localhost PORT = 3306 USER = gas_admin Password = Database = GAS OP-TION = 3 SOCKET =

8. Configure sources:



(for example: ./configure -with-prefix=/usr/local -with-unixODBC=/usr/local )

9. Compile and link sources:

make

10. Install sources: (when the GAS server will be installed in system directo-ries, root privileges can be needed)

make install

11. Setup config.gas file

Server_Certificate - path to the server certificate file,

Server_Private_Key - path to the server key file,

Server_Certificate_Dir - path to the directory containing valid CA certificates

LogFile - a path to the GAS server internal logger file

ODBC_Ini_Section_Name - the odbc.ini section name, which defines connection to theSQL server cooperating with the GAS server,

PortGSI - port on which the GAS server listening for connection (internal the GASprotocol based on GSI is used for this port),

PortSOAP - port for SOAP connections to the GAS server.ATTENTION: In current implementation of the GAS server the GSI plugin for the gSOAPToolkit version 2.1 for the SOAP communication is used (see: http://sara.unile.it/ cafaro/gsi-plugin.html).

RootDN - the distinguish name of the user with root privileges for the GAS server,ATTENTION: it must be given at least one root entry

ExLogLibraryPath - the path to the dynamic library which contains interface to ex-ternal logger service

Example config.gas file:

Server_Certificate=/home/adam/.gas/usercert.pem

Server_Private_Key=/home/adam/.gas/userkey.pem

Server_Certificate_Dir=/home/adam/.gas/certificates

LogFile=/home/adam/.gas/gas.log

ODBC_Ini_Section_Name=GAS

PortGSI=12350

PortSOAP=12352

RootDN=/O=Grid/OU=GridLab/CN=Marcin Adamski

ExLogLibraryPath=/lib/monitoring_logger.so

Running GAS server ==================

In order to run GAS server please go to a directory where GAS was installed and type:

cd bin ./gas_server <path_to>/config.gas

Inside ’sbin’ directory there are scripts which contain the data structure for theGAS integration with external services (e. g. GRMS, Mobiles services,..) In or-der to be able to update the GAS server with data contained in these script files,please install additional the gas_client_admin program.



For more details please visit our web pages: http://www.gridlab.org/WorkPackages/wp-6/



10 Appendix B - GAS Administration and User Guides

10.1 Introduction

The main goal of GAS is to provide functionality that would be able to fulfill most authorizationrequirements of grid computing environments. GAS is designed as a trusted single logical pointfor defining security policy for complex grid infrastructures. As the flexibility is a key require-ment, it is to be able to implement various security scenarios, based on push or pull models,simultaneously.

Secondly, GAS is considered as independent of specific technologies used at lower layers, and itshould be fully usable in environments based on Globus (supporting compatibility scenario withCAS) as well as other toolkits. The high level of flexibility is achieved mainly through modulardesign of GAS. It is divided into five logical components, with the main GAS core module (CoreFunctionality) responsible for performing authorization decisions based upon defined securitypolicy, which is maintained as a set of permissions for specific subjects (e.g. user) and objects(e.g. resource).

GAS package include several components, which are:

• the GAS server,

• administration tools (web portal, command line tools),

• Globus GAS plug-ins.

10.2 GAS Administration Client

Administration client comes in two versions which differs only by a protocol used for commu-nication. First, basic version uses the GSI compatible protocol, while the second one uses thegSOAP protocol when communicating with server. The names of the administration tools arerespectively gas_client_admin and gas_client_admin_soap. The GAS administration clientallows a user to add new objects, subjects, attributes or other items to the security policy storedon the GAS server. Additionally, because the GAS server uses multiple databases, it is possibleto load content of database to the data structures using above mentioned administration client.

Installation

Unzip the downloaded package to a selected directory, go to that directory and invoke the fol-lowing commands:./configuremakemake installThe gas_client_admin application will be installed by default in the /usr/local/bin directory.

Usage:In general gas_client_admin can operate in two modes:

• batch mode where all operations to be performed are contained in a prepared script file,

• terminal mode, where all commands are typed directly by a user.



Application syntax

gas_client_admin -s <hostname> [-p <port>] [-f <script file>]<hostname> - name of the host where the GAS server is running (by default localhost),<port> - number of a port on which GAS server is listening (by default 12350),<script file> - file containing list of commands to perform, line by line.

Commands

add obj def This command is used to add a new item definition to the securitypolicy database.Command syntax:add obj def type=<X> name=<Y> [layer=<L>] [value type=<V>][obj type=<T>]Where <X> is one of the following types: ObjectDef, ObjectAttrsDef,SubjectDef, RoleDef, GroupDef, AttrDef, GroupAttrsDef and Opera-tionDef. <Y> is the name of the item. <L> can be used only if typeequals to ObjectDef and this is the number of the layer on which objectwill be placed. <V> and <T> can be used only when type is equalto AttrDef and means a value type (STRING, INT, TIME, DOUBLE)and an object type this attribute belongs to (from set of: ObjectDef,SubjectDef, RoleDef, GroupDef).

del obj def Deletes object definition of given type and name.Command syntax:del obj def type=<T> name=<N>Where <T> is the type and <N> is the name of an object definition.



add obj This command is used to add a new item to the security policy database.Command syntax:add obj type=<X> name=<Y> [def=<Z>] [obj name=<V>][obj type=<T>] [owner mask=<M>] [all mask=<AM>] [rule=R][parent path=<P>] [rel attr=0|1] [obj mask=*].Where <X> is one of the following types: Object, ObjectAttributes,Subject, Role, Group, Relation, Permission, Attribute and Poli-cyScheme. <Y> is the name of an item. <Z> is the name of anobject definition which was added using command add obj def. <V>and <T> can be used only when type is equal to Attribute and itdescribes the object name and the object type this attribute will beapplied to. <T> can be one of: Object, Subject, Role, Group, Relation,Permission. <R> is used only when the type is PolicyScheme. <P> isa parent path.Object access rights are determined by specifying owner mask andall mask, where owner mask defines mask for the owner of an objectand all mask defines the access mask for all users. Access rights arespecified by one digit as in Unix, e.g 5 specifies execute and read accessfor a given object. Execute right is used when a given object has somechild objects. The child objects can be accessed only when parentobject has execute right. The group access can be only defined by usingedit obj command.PolicyScheme case requires additional explanation. When creating suchan object a user has to provide a rule string describing the format of theresult returned each time when some service or other application asksfor a policy rule. The rule string can contain a number of predefinedvariables which will be expanded to names of objects meeting a requiredpolicy scheme. Those special strings are:operation , object , group , object def , group or subject ,param name , param value , auth dec allow deny .

It is possible to simplify the process of adding object and connecting itto some other object. Those two operations can be performed by usingadditional parameter of add obj command, namely parent path. Whenspecified it binds newly added object to a specified parent object. Thepath is a list of slash separated object names starting from root objectname, through all descendant objects till the direct parent object name,e.g.: /GridLab/GridLab TestBed/Machine1/.Additional parameter rel attr is required when creating objects oftype Relation. Available values are 0 or 1 and they mean respectivelynegative and positive relation.When relation (objects of type Relation) has the obj mask= * specified,it means that all rules specified for this object will apply for all its childobjects as well (unless child object has that particular rule overwritten).



edit obj It defines the relation (users and groups) access for a specifiedGAS object. A user can specify which groups of objects (forexample users) or just subjects has which access rights to thespecified object.Command syntax:type=Object name=<N> edit operation=<E> re-lation name=<R> relation mask=<Digit> rela-tion group|relation subject=<G>Where <N> is an object name, <E> is the type of anoperation, <R> is a relation name, <Digit> is a numberin range 0-7 and <G> is a name of a group. There are5 possible operations: add access group, del access group,add access subject, del access subject and del relation. Forexample, adding read-write access to an object for Group1group could look like:edit obj name=SomeObject edit operation=add access group relation name=SomeRelName rela-tion mask=3 relation group=Group1. In this case relationname is not so important. It is not an external object, butinternal object created automatically by the GAS engine whenno such relation exists yet. This relation is unique for each ob-ject, that is, specifying the same name for another object willcreate separate relation object. del relation operation doesnot require relation mask and relation group/relation subject.For add access subject and del access subject operations auser have to specify relation subject name, not relation grouplike in add access group and del access group case.

del obj Deletes object of given type and name.Command syntax:del obj type=<T> name=<N>Where <T> is type and <N> is the name of an object.

add conn def Use this command to define a connection between two objectdefinitions.Command syntax:add conn def type=<T> ConnectionParent=<X> Connec-tionChild=<Y>Where <T> is ObjectObjectDef. Currently there is only thisone type of connection type. <X> and <Y> are names ofobject definitions. Those definitions have to be created earlier.

del conn def Deletes connection definition of a given type between specifiedparent and child objects.Command syntax:del conn def type=<T> ConnectionParent=<X> Connec-tionChild=<Y>Where <T> is type a connection definition, <X> and <Y>are names of object definitions.



add conn This command creates a connection between two objectinstances.Command syntax:add conn type=<T> ConnectionParent=<X> Connection-Child=<Y>Where <T> can be one of the following types: Group-GroupChild and GroupSubjects (which can be used whenadding content to a group), ConnAccessSecRelationToSubject,ConnAccessSecToRelations, ObjectObjectChild (which addsparent-child connection between two objects), ObjectRelations(which connects object with relation), PermissionOperations,RelationGroups, RelationOperations, RelationSubjects,RolePermissions, RoleSubjects, SubjectDef. <X> and <Y>are names of object instances.

del conn Deletes connection of a given type between specified parentand child objects.Command syntax:del conn type=<T> ConnectionParent=<X> Connection-Child=<Y>Where <T> is the type a connection definition, <X> and<Y> are names of object definitions.

list obj It lists all objects which meet the input condition.Command syntax:list obj type=<T>Where <T> can be: ObjectDef, SubjectDef, RoleDef,GroupDef, AttrDef, OperationDef, Object, Subject, Role,Group, Relation, Permission or Attribute.

list conn It lists all connections which meet the input condition.Command syntax:list obj type=<T> name=<N>Where <X> can be: ObjectDef, SubjectDef, RoleDef,GroupDef, AttrDef, OperationDef, Object, Subject, Role,Group, Relation, Permission or Attribute.

list obj attrs This command lists all objects which meet the input condition.Command syntax:list obj attrs type=<X> name=<Y>Where <X> can have one of the following values: ObjectDef,SubjectDef, RoleDef, GroupDef, AttrDef, OperationDef,Object, Subject, Role, Group, Relation, Permission andAttribute. <Y> is the name of an item.



list obj operations This command lists all objects which meet the input condition.Command syntax:list obj operations <Y>Where <Y> is the name of an object (operation can be onlyadded to the Object item).

info obj This is the command allows obtaining full information aboutone specific item.Command syntax:info obj type=<X> name=<Y> [parent type=<T>] [par-ent name=<V>]Where <X> can have one of the following values: ObjectDef,SubjectDef, RoleDef, GroupDef, AttrDef, OperationDef,Object, Subject, Role, Group, Relation, Permission andAttribute. <V> and <T> have to be specified whentype=AttrDef and they describe the object name and theobject type this attribute is applied to. The object typecan have one of the following values: ObjectDef, SubjectDef,RoleDef, GroupDef, OperationDef, Object, Subject, Role,Group, Relation and Permission.

close Closes the connection to the GAS server.Command syntax:close

stop server Stops the GAS server.Command syntax:stop server

save database This command saves data structures to the database.Command syntax:save database <X>Where <X> is the name of a data link to the database fromthe odbc.ini file.

load database This command loads the database into the GAS data struc-tures.Command syntax:load database <X>Where <X> is the name of a data link to the database fromthe odbc.ini file.

su This command switches similarly like under Unix to thesuperuser mode or specified user mode.Command syntax:su [<user name>]

nosu Returns to the original user mode, that is, to the one a userused during login.Command syntax:nosu



whoami The same like under Unix.Command syntax:whoami

query Returns the authorization decision. This command can beonly used to test security policy stored on the GAS sever.Command syntax:query type=<T> ObjectName=<ON> SubjectName=<SN>OperationName=<OPN> [RoleName=<RN>]Where <T> can be one of: RAD AuthorizationDecision,RBAC AuthorizationDecision. <ON> is the name of anobject, <SN> is the name of a subject (user), <OPN> is thename of an operation which a user wants to perform on anobject and <RN> is obligatory when RBAC model type isselected and it describes the role of a user.

execute sql query Invokes SQL query on a database loaded by invokingload database command. All remaining string after thecommand name is treated as a SQL query.Command syntax:execute sql query

Although GAS supports any possible type of objects dependencies (graphs with loops), as a gen-eral hint it is recommended to create a tree-like structure of objects, because the administrationportal in the current stage of development supports only this kind of structures.There in the data structure was introduced levels idea, which can distinguish group of objects.Usually root objects are placed on the first level while nested object are placed on successivelayers. Although it is recommended to use this attribute when defining new objects is not re-quired to specify level number.All commands and their parameters are CASE SENSITIVE.

As it can be seen below, adding a simple account object and associating it with a server and auser requires quite a number of commands to run. In most cases however gas client admin willbe used in batch mode as it can greatly simplify repetitious works. Also, it can perform opera-tions which cannot be done using web portal such as all direct operations on the GAS databaseor setup of the specific access rights to selected objects. When a user wants to administratethe GAS server in the interactive mode, the best suited tool for this task is however the GASAdministration Portal.

Samples:1. Granting permission for a user to login into a specified machine. We assume that: the username is John, his distinguish name is /DN=John, the machine domain name is grid.test.org(and machine distinguish name is respectively /DN=grid.test.org) and the account which a userwill be mapped to is vouser1.

// define a user - described by DIST NAMEadd obj def type=SubjectDef name=Useradd obj def type=AttrDef name=DIST NAME value type=STRING obj type=SubjectDef obj name=User



// add an user objectadd obj type=Subject name=John def=Useradd obj type=Attribute def=DIST NAME value=”/DN=John”obj name=”John”obj type=Subject

// define a machine - each server has to be defined by three attributes: DIST NAME, IP,DOMAIN NAME

add obj def type=ObjectDef name=Server layer=1add obj def type=AttrDef name=DIST NAME value type=STRING obj type=ObjectDefobj name=Serveradd obj def type=AttrDef name=IP value type=STRING obj type=ObjectDefobj name=Serveradd obj def type=AttrDef name=DOMAIN NAME value type=STRING obj type=ObjectDefobj name=Server

// add an operation that can be performed on the Server objectadd obj def type=OperationDef name=access obj name=Server

// add the server object - we will name it Machine1add obj type=Object name=Machine1 def=Server

add obj type=Attribute def=DIST NAME value=”/DN=grid.test.org” obj name=”Machine1”obj type=Objectadd obj type=Attribute def=DOMAIN NAME value=”grid.test.org” obj name=”Machine1”obj type=Objectadd obj type=Attribute def=IP value=”101.102.103.104” obj name=”Machine1”obj type=Object

// define an account (which attribute is NAME)add obj def type=ObjectDef name=Account layer=2//add obj def type=AttrDef name=NAME value type=STRING obj type=ObjectDef obj name=Account

// add account objectadd obj type=Object name=vouser1 def=Account parent path=”Machine1”// if you do not specify parent path then it is necessary to add a direct connection between aserver and an account as shown below:

// define a relation between a server and an account (* is optional) and connect vouser1 withMachine1add conn def type=ObjectObjectDef ConnectionParent=Server ConnectionChild=Accountadd conn type=ObjectObjectChild ConnectionParent=Machine1 ConnectionChild=vouser1

// define an operation that can be performed on Machine1. In this case it is naturally anaccess operation. You can freely name the operation name.

add obj type=Relation name=AllowAccess1 rel attr=1 obj mask=”*”add conn type=ObjectRelations ConnectionParent=”/Machine1”ConnectionChild=AllowAccess1add conn type=RelationOperations ConnectionParent=AllowAccess1 ConnectionChild=access



// give John access defined by the AllowAccess1 relation. add conn type=RelationSubjectsConnectionParent=AllowAccess1 ConnectionChild=John

2. We will add a second machine with name Machine2 which domain name is grid2.test.org(and the machine distinguish name is respectively /DN=grid2.test.org). There will be the sameaccount created, that is, vouser1. Both those machines will belong to a newly create testbedSampleTestbed. We would like John to have an access to both of those machines on the samerules.

// define object type TestBedadd obj def type=ObjectDef name=TestBed layer=2

// define the object itselfadd obj type=Object name= SampleTestbed def=TestBed

// next we will add the second machineadd obj type=Object name=Machine2 def=Serveradd obj type=Attribute def=DIST NAME value=”/DN=grid2.test.org” obj name=”Machine2”obj type=Objectadd obj type=Attribute def=DOMAIN NAME value=”grid2.test.org” obj name=”Machine2”obj type=Objectadd obj type=Attribute def=IP value=”101.102.103.105”obj name=”Machine2”obj type=Object

// add the account object. Please, note that the account vouser1 will be automatically con-nected with Machine2 object.add obj type=Object name=vouser1 def=Account parent path=”Machine2”

// define an access operation that can be performed on Machine2.add conn type=ObjectRelations ConnectionParent=”/Machine2”ConnectionChild=AllowAccess1

// add machines to Testbedadd conn type=ObjectObjectChild ConnectionParent=SampleTestBed ConnectionChild=Machine1add conn type=ObjectObjectChild ConnectionParent=SampleTestBed ConnectionChild=Machine2

3. Adding new user Betty. She has to be able to use all machines in Testbed and she willbe using the same account vouser1. In order to simplify that process a group of users will becreated. Betty will become member of that group. The group will be named VOMembers.

// define a group of usersadd obj def type=GroupDef name= VOMembersDef

// create the group itselfadd obj type=Group name= VOMembers def= VOMembersDef

// add users to the groupadd conn type=GroupSubjects ConnectionParent=VOMembers ConnectionChild=Johnadd conn type=GroupSubjects ConnectionParent=VOMembers ConnectionChild=Betty

// add an access right to the group



add conn type=RelationGroups ConnectionParent=AllowAccess1 ConnectionChild= VOMem-bers

10.3 GAS Plug-ins

The GAS plug-in is the Globus plug-in meeting specified requirement, which will be called lateras a callout. When enabled, it uses information gathered by the GAS service to get accountinformation and obtain authorization decision. When such services as Globus gatekeeper orgridFtp need to perform mapping user to an account and get authorization decision, they looksfirst to the gsi-authz.conf file located in the ”/etc/grid-security directory” to check whether werenot specified some external callouts that should be called in order to perform these tasks.

There are many clear advantages of using the GAS server integrated with Globus over thestandard grid-mapfile. Especially when it comes to managing of a number of servers runningGlobus because an administrator can manage them all simultaneously using the GAS admin-istration portlet or GAS administration tools. Adding or removing a user to/from a group ofusers that are allowed to work on some group of machines is as easy as performing one action tothe GAS service. There will be no longer necessity to edit grid-mapfile on all machines belongingto that group. The same applies to editing particular user rights.The GAS plug-in solution is transparent, that is, it uses standard authorization routines whenthe GAS service is turned off or when specified user is not in the database.

Currently there are two callouts implemented. One of them is the gridmap callout which inte-grates with globus-gatekeeper and is invoked during the user authorization and mapping to aspecified account.The second one works on slightly lower level, namely it integrates with job-manager and it isinvoked whenever some job related operation is to be performed. As both callouts are includedwithing a single library, the following instructions will apply to both those callouts.

Current version of the GAS plug-ins with Globus GT3.2 pre WS is integrated

InstallationBefore installing GAS plug-ins a system on which it will be installed has to meet the followingrequirements:

1. Because this these callouts contact the external service the proper firewall(s) adjustmentshave to be done before installing the GAS plug-in software. That is, a proper port has to beopened in order the communication with the GAS server to work correctly.2. GPT is used to build the GAS callouts, thus having the write access to $GLOBUS LOCATION/liband $GLOBUS LOCATION/etc is a must.3. Having the write access to the /etc/grid-security directory where the gsi-authz.conf file willbe written or modified.4. The possibility to change the read access flag of the gsi-authz.conf file.5. The access right to the /var directory in order to create the log directory (by default it is/var/gas). If you want it to be created in another location please modify the INSTALL script.

Installation guide



Before running the INSTALL script go the /etc subdirectory and fill out properly the gas mapfilefile. It has to contain all account names followed by the ’=’ mark. These accounts will be treatedas virtual accounts, that is, when a user does not have an account on the machine the GAS plu-gin is running, he/she can use one of not yet assigned virtual accounts, provided that an accessto that virtual account has been granted by the GAS service.In order to set the logging directory edit the gas config file located in /etc/grid-security. Theline beginning with ”LogFileLocation” needs to be modified to point to the proper location.

Run the INSTALL script.

Ensure that the gsi-authz.conf DOES NOT have write access specified for group and others.

UsageAfter the installation of the GAS Plug-ins no access rights will be modified, granted or denied tothose existing in the current grid-mapfile. All changes to the access rights can be made simulta-neously in the grid-mapfile and in the GAS server database. In the second case it is necessaryto use one of the administration tools described in this document.However the proper working of GAS plug-ins require the GAS data structure to follow somegeneral rules:- a server has to be described by the distinguish name attribute. The attribute name have tobe named DIST NAME,- a user has to be described by the distinguish name attribute. The attribute name have to benamed DIST NAME,- an account object has to be defined with Account or VirtualAccount name depending on whataccount type a user has to have assigned,- connect some relation with an access operation.The GAS engine will be looking for a machine entry then it will be walking through the tree-likedata structure and looking for a specified user and an access relation between these two objects.Therefore there is no special limitation of placement of a machine and a user entry in the datastructure. The flexibility of GAS allows for grouping objects, either users or servers.



11 Appendix C - GAS Portlet Administrator’s Guide

11.1 Table of Contents

• Introduction

• Installing the GAS portlet

• Configuring the GAS portlet

• Configuring the GAS portlet - service settings

• Configuring the GAS portlet - connection settings

11.2 Introduction

The GAS Portlet Administrator’s Guide describes how to install and maintain the GAS portletwithin the GridSphere portal. For more information on working with GAS, please read the GASPortlet User’s Guide document or visit the following web page:http://www.gridlab.org/WorkPackages/wp-6/documentation.html It is assumed that you havesuccessfully installed the GridSphere Framework Portal and you are familiar with portlets andGAS. The current version of described portlet supports GAS v1.4.0.

11.3 Installing the GAS portlet

In order to install the GAS portlet please:

• extract content of the GAS portlet tarball to <GRIDSPHERE HOME>/projects

• change directory to <GRIDSPHERE HOME>/projects/gas

• run ant install

These steps should deploy portlet within the GridSphere and generate the documentation (thedocumentation you are reading at the moment).

Since GAS and the GAS portlet use communication over the httpg protocol, you have to makesome changes in the $CATALINA_HOME/bin/catalina.sh script. Please add the following linesinto the start section just afterelif [ "$1" = "start" ] ; thenshift touch "$CATALINA_BASE"/logs/catalina.out

lines in the script: CLASSPATH="$CLASSPATH":"$CATALINA_HOME/shared/lib/cog-jglobus.jar":

"$CATALINA_HOME/shared/lib/log4j-core.jar"CLASSPATH="$CLASSPATH":"$CATALINA_HOME/common/endorsed/xercesImpl.jar":

"$CATALINA_HOME/common/endorsed/xmlParserAPIs.jar"CLASSPATH="$CLASSPATH":"$CATALINA_HOME/shared/lib/puretls.jar":

"$CATALINA_HOME/shared/lib/jce-jdk13-117.jar"CLASSPATH="$CLASSPATH":"$CATALINA_HOME/shared/lib/cryptix32.jar":



"$CATALINA_HOME/shared/lib/cryptix-asn1.jar"CLASSPATH="$CLASSPATH":"$CATALINA_HOME/shared/lib/cryptix.jar"

The modification above will add necessary jars to the $CLASSPATH environment variable duringthe Tomcat startup.

The GAS Portlet is ready to configure and use !!!Please see 11.4 section of this documentation.

11.4 Configuring the GAS portlet

In order to setup portlet settings please switch portlet to the config mode (note that you haveto have the admin rights).

For the first time, you can see default settings that comes fromthe $CATALINA HOME/webapps/gas/WEB-INF/PortletServices.xml file.These settings should fit your needs (maybe except for the GAS service URL). Otherwise, pleasechange them (please note that: after making changes the settings are stored in$CATALINA HOME/webapps/gas/WEB-INF/Settings/config.xml,and any changes in$CATALINA HOME/webapps/gas/WEB-INF/PortletServices.xmlwill not have any effects). Please make any changes through config mode only (do not edit configfiles directly).

This settings affect all users (except MyProxy default settings if a user was using the GASportlet before). You have 2 subtabs here:

• Service settings

• Connection settings

After making any changes you have to confirm it by pressing the set button. See also the GASPortlet Settings for user in the GAS Portlet Configuration User’s Guide.

11.5 Configuring GAS portlet - service settings

Service settings allow to:

• setup the GAS service settings - GAS Service URL

• setup MyProxy default settings - this settings will appear in the edit mode by default(setup of the MyProxy default hostname and the MyProxy default port)

11.6 Configuring the GAS portlet - connection settings

Connection settings allow to define 2 separate connectors. We call them secure and insecureconnector (port number and scheme), although portlet doesn’t check if connector is secure orinsecure (you can even describe here 2 secure or insecure connectors, it depends on your HTTPserver settings).



Figure 13: Service settings in the config mode of the GAS portlet

Please do not make any changes here, unless you know exactly what HTTP server settings are.You can find the following fields here:

Default scheme - scheme for insecure (first type) connection (just leave http, as it is)

Default port - the port number for insecure connection. The port for the default Tomcat con-nector (unless you make changes in server.xml) is 8080.

Secure scheme - scheme for secure (second type) connection (just leave https, as it is)

Secure port - the port number for the secure connection. The port for the default secure Tomcatconnector (unless you make changes in server.xml) is 8443. Please note that you have to followthe instructions in server.xml in order to enable the secure connector.

View mode use secure - if the checkbox is switched on, the view mode will use the secureconnector.

Edit mode use secure - if the checkbox is switched on, the edit mode will use the secure connector.Please note, that user exchanges confidential data with portlet in the edit mode.

Config mode use secure - if the checkbox is switched on, the configure mode will use the secureconnector.

Help mode use secure - if the checkbox is switched on, the help mode will use the secure connector.

Figure 14: Connection settings in the config mode of the GAS portlet



12 Appendix D - GAS Portlet User’s Guide

12.1 Table of Contents

• Introduction

• GAS Portlet Configuration

• Using the GAS Portlet - subtabs

• Using the GAS Portlet - tree view

• Using the GAS Portlet - operations on GAS subjects

• Using the GAS Portlet - operations on GAS groups

• Using the GAS Portlet - GAS relations

• Using the GAS Portlet - operations on GAS relations

12.2 Introduction

The GAS Portlet User’s Guide describes how to use the GAS Portlet. This guide assumes thatyou are familiar with portlets (the change mode etc.) and with GAS concepts. For more informa-tion on the GAS sever, installing and maintaining the GAS portlet, please read the GAS PortletAdmin’s Guide or visit the GAS documentation web page: http://www.gridlab.org/WorkPackages/wp-6/documentation.html . The current version of the portlet supports GAS v. 1.4.

12.3 GAS Portlet Configuration

In order to configure the GAS Portlet, please switch to the edit mode. There are you will beable to setup myproxy settings and download their credentials to the GAS Portlet. To applychanges please press the set button. For more information on config the GAS service and defaultMyProxy, please read the GAS Portlet Administrator’s Guide.

Figure 15: MyProxy settings in the edit mode of the GAS portlet



12.4 Using GAS Portlet - subtabs

The view mode of the GAS Portlet consists of 4 subtabs (one is for operations on GAS groupsand GAS subjects; three are for operations on GAS relations):

• Account Management - GAS groups and subjects management (including adding, removinggroups and subjects)

• Services Management - services management (adding groups and/or subjects to relationsassociated with services)

• Resources Management - servers and virtual accounts management (adding groups and/orsubjects to relations under servers and virtual accounts)

• Projects Management - GRMS projects and jobs management (adding jobs, groups and/orsubjects to relations associated with GRMS projects) for ”Collaboration Scenario”. Fordetails please visit the GRMS documentation web page:http://www.gridlab.org/WorkPackages/wp-9/documentation.html

The GAS Portlet state and settings are persistent - users have the same environment as theyhad during the last visit.

12.5 Using the GAS Portlet - a tree view

All subtabs of the GAS portlet consists of 2 panels presenting data in form of the tree view. Auser can easily perform operations on GAS using ”<” and ”>”buttons. Context of the operationdepends on an active entry (an entry written in bold name, and had white background). A usercan change the context by choosing entries (by clicking the entry name). Entries on which auser wants to perform the GAS operation should be selected by marking appropriate checkboxes.The GAS operations that can be performed with the GAS Portlet are described in more detailsin sections: operations on GAS subjects, operations on GAS groups and operations on GASrelations.

12.6 Using the GAS Portlet - operations on the GAS subjects

The Account Management subtab allows a user to perform the following operations on the GASsubjects (please use the right panel):

Adding a subject - please fill out and submit (with ”Add” button) a form placed on the bottomof the panel (6 on the ”Account Management subtab in the GAS portlet” figure; Username isthe internal GAS name of the subject, DN is the distinguish name).

Removing subjects - please mark checkboxes near the internal GAS names of subjects and pressthe ”Delete” button (5 in the ”Account Management subtab in the GAS portlet” figure). Youcan delete more then one subject during one request.

12.7 Using the GAS Portlet - operations on GAS groups

The Account Management subtab allows a user to perform the following operations on the GASgroups (please use the left panel):



Figure 16: Account Management subtab in the GAS portlet

Adding groups - please choose the context by clicking the name of the GAS group (activationof the GAS group; see no 1 in the ”Account Management subtab in GAS portlet” figure). Thename of the active GAS group is written in bold, with white background. Please fill out andsubmit (using the ”Add” button) a form placed on the bottom of the panel (see no 3 on the”Account Management subtab in GAS portlet” figure; Groupname is name of the GAS group.The GAS group will be added to the active group or to group’s root if context is not chosen.

Removing groups - please check checkboxes near names of GAS groups and press ”delete”button(2 in the ”Account Management subtab in the GAS portlet” figure). You can delete more thenone group during one single request. The removing the GAS group operation doesn’t need acontext. Please note, that marking the internal GAS names of subjects and performing thisoperation will remove GAS subjects from the parent GAS group(s), not from GAS (if you wantto remove GAS subjects, please see operations on GAS subjects).

Adding subjects to the group - please choose the context by clicking the name of the GAS group(activate the GAS group; 1 in the ”Account Management subtab in the GAS portlet” figure).Name of the active GAS group is written in bold, background is white. Please mark checkboxesnear the internal GAS names of subjects (use the right panel) and press the ”<” button (locatedbetween panels; 4 in the ”Account Management subtab in GAS portlet” figure). GAS subjects



will not be added context is not chosen. You can add to the GAS group more then one GASsubject during one request.

Removing subjects from the group - please mark checkboxes near the internal GAS names ofsubjects under the GAS groups and press the ”>” button (located between panels; 4 in the”Account Management subtab in GAS portlet” figure) or press the ”Delete” button (2 in the”Account Management subtab in GAS portlet” figure). You can remove from the GAS group(s)more then one GAS subject during one request.

12.8 Using GAS Portlet - GAS relations

The GAS relations are listed on the left panel in the Services Management, the ResourcesManagement and the Projects Management subtabs.

The GAS Portlet uses red font for rendering a list of names of operations associated with negativerelations and green font for rendering names of operations associated with positive relations.

For more information on the GAS relations please consult the GAS documentation web page:http://www.gridlab.org/WorkPackages/wp-6/documentation.html .

For information on performing the GAS relations operations in the GAS Portlet, please seeOperations on GAS relations section.

12.9 Using the GAS Portlet - operations on the GAS relations

Services Management, Resources Management and Projects Management allow a user to performthe following operations on the GAS relations:

Adding operations to the relation - please open the ”list of operations” subpanel using link underthe ”O” icon near name of the GAS relation (4 in the ”Resource Management subtab in GASportlet” figure). Please fill out and submit (with ”Add operation” button) a form placed belowthe name of the GAS relation (5 in the ”Resource Management subtab in GAS portlet” figure;OPERATION is name of a new GAS relation operation - please consult the GAS documentation).You can add only one operation during one request.

Removing operations from the relation - please open the ”list of operations” subpanel using linkunder ”O” icon near the name of the GAS relation (4 on the ”Resource Management subtab inthe GAS portlet” figure). Please use the ”remove” link placed by operation you want to remove(5 in the ”Resource Management subtab in the GAS portlet” figure). You can remove only oneoperation during one request.

Changing owner of the relation - please open the ”rights and owner” subpanel using link underthe ”R” icon near the name of the GAS relation (1 in the ”Resource Management subtab in GASportlet” figure). Please use the listbox placed on the subpanel to select a new owner. Use the”Set owner” button to confirm the selection (2 in the ”Resource Management subtab in GASportlet” figure). You can change the owner of only one relation during one request.

Changing rights for the relation - please open the ”rights and owner” subpanel using link underthe ”R” icon near the name of the GAS relation (1 on the ”Resource Management subtab in GASportlet” figure). Please select/unselect proper checkboxes placed on the subpanel, and confirmnew rights with the ”set rights” button (3 in the ”Resource Management subtab in GAS portlet”figure). You can change the rights of only one relation during one request.



Adding subjects and groups to the relation - please choose the context by clicking the name ofthe GAS relation (activate the GAS relation; 6 on the ”Resource Management subtab in theGAS portlet” figure). the name of an active the GAS relation is written in bold with a whitebackground. Please mark checkboxes near the internal GAS names of subjects or/and namesof the GAS groups (use right panel) and press ”<” button (placed between panels; No 7 in the”Resource Management subtab in the GAS portlet” figure). The GAS subjects and GAS groupswill not be added if the context is not chosen.

Removing subjects and groups from the relation - please mark checkboxes near the internal GASnames of subjects or/and names of the GAS groups associated with GAS relations and pressthe ”>” button (located between panels; No 7 in the ”Resource Management subtab in the GASportlet” figure).

Figure 17: Resource Management subtab in the GAS portlet



References

[1] M. Adamski, M. Chmielewski, S. Fonrobert, A. Gowdiak, B. Lewandowski, J. Nabrzyski,T. Ostwald, and J. Pukacki. Technical specification for Authorization Service, August 2002.http://www.gridlab.org/Resources/Deliverables/D6.2b.pdf.

[2] M. Adamski, M. Chmielewski, S. Fonrobert, A. Gowdiak, B. Lewandowski, J. Nabrzyski,T. Ostwald, and J. Pukacki. WP6 Security: Initial Requirements, April 2002.http://www.gridlab.org/Internal/Drafts/wp6_requirements_draft.pdf.

[3] M. Adamski, M. Chmielewski, S. Fonrobert, A. Gowdiak, B. Lewandowski, J. Nabrzyski,T. Ostwald, and J. Pukacki. Implementation and Test Plan, January 2003.http://www.gridlab.org/Resources/Deliverables/D6.3.pdf.

[4] The Globus Project. CAS User and Administrative Guide, August 2002.http://www.globus.org/security/cas/alpha-r2/cas-guide-v0_2.pdf.

[5] P. Hallam-Baker, E. Maler, and VeriSign. Assertions and Protocol for the OASIS SecurityAssertion Markup Language (SAML). OASIS, May 2002.http://www.oasis-open.org/committees/security/docs/cs-sstc-core-01.pdf.

[6] P. Mishra and Netegrity. Bindings and Profiles for the OASIS Security Assertion MarkupLanguage (SAML). OASIS, May 2002.http://www.oasis-open.org/committees/security/docs/cs-sstc-bindings-01.pdf.


Documented second release of the security infrastructure and APIs

Documents

Transcript of Documented second release of the security infrastructure and APIs