Difference between revisions of "Security middleware deployment planning"

From PDP/Grid Wiki
Jump to navigationJump to search
m (deployment plan)
Line 1: Line 1:
 +
== Deployment planning ==
 +
 +
Deciding which security middleware to deploy at your site depends on the
 +
scenario you need to implement.
 +
 +
 +
 +
In grid computing, users are authenticated by their Grid
 +
Certificate, often in combination with VOMS attributes. This
 +
information is then used to authorize the user at a site.
 +
 +
If you want to set up gLExec on Worker Nodes, you need to install Argus.
 +
 +
; user authorization
 +
: who is allowed
 +
For a site administrator it is vital to manage which users
 +
are allowed in and to keep track of which
 +
users have been using the services.
 +
 
Summary: normally you should install Argus for central authorization and mapping, but a few special cases apply. Alternatively, SCAS may be used.
 
Summary: normally you should install Argus for central authorization and mapping, but a few special cases apply. Alternatively, SCAS may be used.
  

Revision as of 11:03, 23 April 2010

Deployment planning

Deciding which security middleware to deploy at your site depends on the scenario you need to implement.


In grid computing, users are authenticated by their Grid Certificate, often in combination with VOMS attributes. This information is then used to authorize the user at a site.

If you want to set up gLExec on Worker Nodes, you need to install Argus.

user authorization
who is allowed

For a site administrator it is vital to manage which users are allowed in and to keep track of which users have been using the services.

Summary: normally you should install Argus for central authorization and mapping, but a few special cases apply. Alternatively, SCAS may be used.

See if any of the following statements apply.

I would like to do policy management, user mapping and user banning all from one place
The default choice is to set up Argus[1], and configure your resources to use it (see below).
I use dynamic secondary group mappings which require LDAP updates
In this case, you need to use the LDAP enforcement plugin for LCMAPS. This cannot be used in conjunction with Argus; use SCAS as the default alternative.
My cluster is set up to do local mappings to match users to job slots
This is a special case, which can be handled by setting up LCMAPS without a central authorization service (i.e. node-local).
I'm using 3rd party plugins for LCMAPS
We can't say in general if a plugin will or will not work with either Argus or SCAS in this case. You should try Argus first, SCAS next, and node-local setups finally.
I've tried Argus and it didn't work; now what?
Open a support ticket in GGUS[2] for Argus and get it fixed. In the meantime, try to use SCAS as an alternative.
I don't want/need central policy management, mapping or banning
You should set up LCMAPS independently per resource, possibly with a shared NFS gridmapdir to keep consistency between mappings.