![](media/image1.png){width="1.76875in" height="0.8916666666666667in"}

**Open Science Grid**

+------------------------+---------------------------------------------+
| Document Name          | > **Certificate Attributes Handling in OSG  |
|                        | > and Common Practices for Implementing     |
|                        | > Resource Access Policies**                |
+------------------------+---------------------------------------------+
| Version                | **Draft 0.30**                              |
+------------------------+---------------------------------------------+
| Date last updated      | 11/13/2023                                  |
+------------------------+---------------------------------------------+
| Authors                | > Ted Hesselroth, John Hover, Gabriele      |
|                        | > Garzoglio, Igor Sfiligoi, Tanya Levshina, |
|                        | > Steve Timm, John Weigand                  |
+------------------------+---------------------------------------------+
| OSG document \#        |                                             |
+------------------------+---------------------------------------------+

Change History

  ------------- --------------------------- -----------------------------
  5/17/2007     Gabriele Garzoglio          Put things together

  5/22/2007     Gabriele Garzoglio          Integrating feedback
  ------------- --------------------------- -----------------------------

# 

# About this document

*This document reviews how certificate attributes are used by Virtual
Organizations and Sites on the OSG for policy decisions, such as access
control and priority enforcement.*

# Index

[1. Introduction 3](#introduction)

[2. Blueprint Meeting Executive Summary
3](#blueprint-meeting-executive-summary)

[3. VO Attributes and Structure 7](#vo-attributes-and-structure)

[Grid Identities 7](#grid-identities)

[VO Attributes 7](#vo-attributes)

[VO Administrative Infrastructure 8](#vo-administrative-infrastructure)

[VO Registration Workflow 8](#vo-registration-workflow)

[4. Attribute Propagation Model 9](#attribute-propagation-model)

[5. Resource Access Control and Privilege Enforcement
9](#resource-access-control-and-privilege-enforcement)

[Policy Enforcement Points 9](#policy-enforcement-points)

[Policy Decision Points 10](#policy-decision-points)

[Typical Cluster Configurations 10](#typical-cluster-configurations)

[Typical Storage Configurations 11](#typical-storage-configurations)

[6. Access Accounting and Auditing 11](#access-accounting-and-auditing)

[7. Known Issues with the Infrastructure
11](#known-issues-with-the-infrastructure)

[Wide-Spread Usage of grid-mapfiles
11](#wide-spread-usage-of-grid-mapfiles)

[Propagation of New VO Structures and Policies to Sites
12](#propagation-of-new-vo-structures-and-policies-to-sites)

[Pool Account Maintenance 12](#pool-account-maintenance)

[Inconsistencies in VO Attributes Usage by SAZ and GUMS
13](#inconsistencies-in-vo-attributes-usage-by-saz-and-gums)

[Attribute Validation and Site-wide Authentication
13](#attribute-validation-and-site-wide-authentication)

[Undefined Behavior for Proxies with Multiple VO Attributes
14](#undefined-behavior-for-proxies-with-multiple-vo-attributes)

[Appendix A -- VO Structures: the ATLAS Case Study
14](#vo-structures-the-atlas-case-study)

[Appendix B -- VO Registration Workflows 15](#vo-registration-workflows)

[VOMS Workflow 15](#voms-workflow)

[VOMRS/VOMS Workflow 15](#vomrsvoms-workflow)

[Shibboleth Workflow 15](#shibboleth-workflow)

[Appendix C -- PRIMA/GUMS SAML and SAZ Protocols
16](#primagums-saml-and-saz-protocols)

[GUMS 16](#gums)

[SAZ 16](#saz)

[Appendix D -- Typical Batch System Configurations
16](#typical-batch-system-configurations)

[Appendix E -- Typical Storage Configurations
18](#typical-storage-configurations-1)

[Appendix F -- Glossary 19](#glossary)

[References 20](#references)

## Introduction

This document discusses how members of a VO are granted access rights to
resources. Section 2 summarizes what certificate attributes are used in
what components of the OSG authorization infrastructure. This section
assumes that the reader has a basic knowledge of the concepts described
in detail in the rest of this document. Section 3 describes the internal
organizational structure of VO's and how this structure is
administratively maintained (see also Appendix A and Appendix B).
Section 4 describes how VO attributes are propagated to resources.
Section 5 discusses how access control and priority enforcement is
managed at resources (see also Appendix C) and presents typical cluster
and storage elements configurations (also in Appendix D and Appendix E).
Section 6 describes site accounting and auditing capabilities. Section 7
presents known problems with the infrastructure.

## Blueprint Meeting Executive Summary

The OSG authorization infrastructure is composed of services maintained
by VO and Sites. VO's are responsible for maintaining and publishing
user membership information using set of services called Policy
Information Points (PIP). On the other hand, Sites are responsible for
enforcing access and privileges to resources. This is achieved by two
cooperating set of site services: the Policy Decision Points (PDP),
which maintain access and privilege policies centrally, and the gateway
services to resources, called Policy Enforcement Points (PEP), which
enforce the PDP decisions. Figure 1 shows a diagram of the OSG
authorization infrastructure.

![](media/image2.jpeg){width="5.997222222222222in"
height="3.2680555555555557in"}

Figure 1: The OSG Authorization Infrastructure. The VO maintains user
membership information, while Sites control access and privileges to
resources. This is achieved at sites by using central Policy Decision
Points -- GUMS and SAZ -- and Policy Enforcement Points -- resource
gateways at the Computing Elements (CE), Storage Elements (SE), and
Worker Nodes (WN).

Users authenticate with PEP's using X509 credentials, which encode
information about the user (e.g. the Distinguished Name) and the
credentials themselves (e.g. the validity period, Certificate Authority,
etc.). Users can extend the credential information with VO membership
information, by interacting with the VOMS of the VO. Figure 2 details
the content of (delegated) user credentials and shows all VO Attributes
and the most relevant (to OSG) credential attributes. A complete list of
valid X509 attributes is available in RFC3280. Extended attribute syntax
is described in RFC3281. Figure 3 shows a diagram of the interaction of
a user with VOMS.

![](media/image3.jpeg){width="5.990972222222222in"
height="4.104861111111111in"}

Figure 2: X509 credentials attributes. X509 credentials are composed of
2 parts: a certificate (signed by the private of the Certificate
Authority that issued the certificate), which encodes attributes + a
public key, and a private key, cryptographically related to the public
key of the corresponding certificate. User credentials are represented
by the two central-bottom boxes, enclosed by a solid-line rectangle.
Attributes associated with the user certificate are shown in the
right-bottom box.

Credentials can be delegated, typically to limit privileges associated
with user credentials (e.g. limit validity and functionalities). User
Proxies, or first-level delegated credentials, contain the user
certificate, a proxy certificate/public key (signed by the user private
key) and the related private key. Proxy credentials are represented by
three boxes in the center, enclosed by a dashed-line rectangle. Proxy
certificates can be extended with VO Attributes. Proxy attributes are
shown in the right-top box; VO attributes are shown in bold.

Proxies are typically further delegated to PEP's. A second-level
delegated credential contains the user certificate, the proxy
certificate (already signed by the user private key), and a delegated
proxy certificate/public key (signed by the proxy private key) and
private key. Delegated proxy credentials are represented by four boxes
in the center, enclosed by a dotted-line rectangle (note: the "Proxy
Private Key" box is not included).

It should be noted that validating the chain of delegation
cryptographically proves that the "delegator" had access to its private
key. Ownership of the private key, together with the corresponding
certificate, ultimately proves identity.

![](media/image4.jpeg){width="5.717361111111111in"
height="3.4520833333333334in"}

Figure 3: User interaction with VOMS. Users extend credentials with VO
Attributes by interacting with VOMS. Users authenticate with VOMS using
proxies (bottom-left), generated by user credentials (top-left). VOMS
embeds an Attribute Certificate (AC) (red/bold text to the right),
encoding the VO Attributes ("attribute" parameter in red/bold), into the
user proxy. Such AC is signed by the service certificate of VOMS
(typically, the host certificate of the machine where VOMS runs). VO
Attributes are in the form
"/\<VO\>/\<group\>/\<subgroup\>/.../Role=\<role\>/Capabilities=NULL"
(Capabilities are NOT used in the OSG). In reality, the AC contains a
list of "attribute" parameters, one for every group to which the user
belong. The first attribute in the list is the set of VO Attributes
requested by the user to VOMS.

Different attributes of the credentials presented to a PEP are used for
authentication, access authorization (SAZ), and local identity mapping /
privilege setting (GUMS). Figure 4 details what attributes are used by
the different services.

PDP can be configured to support different access and mapping policies.
In particular for GUMS, administrators are responsible for maintaining
synchronized the PDP policies with the ones supported by the PEP. For
example, GUMS can map a certain FQAN to a local user, but it cannot
check if that local user exists in the context of the PEP. Typical
configurations of Computing and Storage Elements PEP's are discussed in
Section 5, Appendix D, and Appendix E. Common administrative pitfalls
and known problems with the infrastructure are discussed in Section 7.

![](media/image5.jpeg){width="5.9944444444444445in" height="4.475in"}

Figure 4: Certificate Attributes used in the OSG Authorization
Infrastructure. The diagram shows what attributes are used during
authentication with the PEP, during access authorization with SAZ (PDP),
and during identity mapping with GUMS (PDP). The same credentials (user
proxy delegated to the PEP) are shown 3 times. Each time, credentials
are represented by 3 vertically adjacent text boxes: user certificate
(bottom), proxy certificate (center), and delegated proxy certificate +
private key (top). The attributes used in each occasion are marked in
bold red. It should also be noted that, for convenience, the diagram
shows the same PEP twice.

For authentication, the PEP validates credentials, using local files
("Local GSI Config" box). These files are the Certificates / Public Keys
of the trusted CA's, the signature policy files (defining the CA
authority in signing a certain DN namespace), and the Certificate
Revocation lists (frequently updated list of certificate serial numbers
revoked by the CA). The Attributes used in combination with these files
are *Issuer*, *Subject*, and *Serial Number* attributes. Today, the AC
is not validated against the VOMS certificates. During authentication,
the PEP verifies the *validity* dates of the certificates and the
allowed functionalities (*Other X509 Attributes*) (e.g. by default,
Globus libraries delegate "limited" proxy, which cannot be used to
submit jobs).

For access authorization, SAZ client sends SAZ the whole delegated proxy
chain (this includes the CA certificates). The SAZ server can deny
access to users based on the *VO*, *VO Attributes* (Group hierarchy and
Role), and CA (*Issuer* attribute of the user certificate). By default,
SAZ denies access to users credentials without an AC, unless their
*Subject* is present on an internal white list.

For identity mapping, Prima parses the delegated credentials and passes
the relevant attributes to GUMS as a SAML v1.1 assertion. Today, the DN
of the VOMS server (*Extended Attribute Issuer*) is passed to GUMS, but
not used. the SAML assertion includes also the hostname of the PEP, as
different policies can be enforced for the same FQAN's on different
nodes. GUMS returns Approve / Deny access + a username. The username is
formatted as an XACML Obligation, an extension of the standard SAML v1.1
protocol. The PEP transforms the username in a UID/GID pair (+ RootPath
in the case of SRM) by looking at the local PEP account configuration
(e.g. /etc/passwd file, NIS, dCache account config file). User
privileges are set by using UID/GID in the resource management service
configuration (Batch System configuration, File System permissions,
etc.)

## VO Attributes and Structure

In the OSG, sites authorize users to access resources because of their
membership to a VO. On the other hand, VO's generally have an internal
structure, organizing users in groups and granting members specific
roles. On the OSG, VO's expect to be able to partially control access to
resources according to such internal structure.

Such structure is maintained administratively by a set of trusted
representatives of the VO and groups. In the OSG, in order for a person
to become a member of a group and have certain roles, the VO must record
specific user information and run certain approval workflows. Tools help
with this process.

The following subsections describe how OSG VO's are structured, how
these structures are maintained, and what workflows are in place to
grant user membership.

### Grid Identities

Grid computing uses digital certificates as defined by the X.509
standard to authenticate users. Users prove who they are to a recognized
Certificate Authority (CA). The CA issues them a long-lived grid
certificate, which has an associated private key. Because only users
have access to their private keys, they can cryptographically prove who
they are to any other computer that recognizes their CA. In typical grid
usage, a user generates a temporary grid proxy which is used to
establish the user\'s grid identity. While strictly speaking, the
user\'s grid identity is the grid proxy, it is often useful to think of
the user\'s distinguished name (or DN) as being equivalent to a
username. A DN is defined by the user\'s grid certificate and takes the
form of a string containing their name and other information about their
CA, e.g. \'/DC=org/DC=doegrids/OU=People/CN=John R. Hover 47116\'.

### VO Attributes

To provide sufficient flexibility to resource providers to specify
precisely who should be allowed to do what with their resources, the VO
organize their membership structure around three concepts: groups,
roles, and capabilities. These are also referred to as VO Attributes, as
they characterize a user within the VO structure.

**Groups** serve the same purpose as user groups do on typical computer
systems, with the added feature that Groups are hierarchical structures,
which can contain Subgroups. All members of a subgroup are members of
the parent group, but not vice-versa. Typically, all rights of group
membership are granted automatically by a grid resource provider i.e.
the user need not request these rights. Group membership is typically
expressed as a path expression. For example, for the ATLAS VO, all U.S.
members are put in the Group \'/atlas/usatlas\'. All European members
are in \'/atlas/lcg1\'. And all members of the VO are members of the
group \'/atlas\'. As a practical matter, a Group is essentially a list
of the DN's of the members of the group.

**Roles** are additional attributes that can be granted to a particular
user, as a member of a group. It represents a role that a user can
choose to play in using a resource. An example of a role that is
frequently defined is \"software\", which means that this user is
allowed to act as a software manager for the VO i.e. to have write
access to a particular storage area that non-software users would not.
Note that the use of roles requires the user to specifically request
them when generating their proxy; they are not granted automatically
like rights that derive from group membership.

**Capabilities** were originally conceived of as another attribute that
would be granted similarly to Roles, but VO's have not used them.

**Generic Attributes** are a concept introduced recently to allow the
characterization of users beyond the model defined by the VO Attributes.
For example, the AFS user name on a certain system can be associated to
a user using a Generic Attribute. Generic Attributes address EGEE use
cases, which are not typical of OSG.

VO Attributes are often written as a longer, formatted string like this:

\'/atlas/usatlas/Role=software/Capability=NULL\' and, when combined with
the user\'s DN, are referred to as a Fully Qualified Distinguished Name
(FQAN)[^1], e.g.

> \'/DC=org/DC=doegrids/OU=People/\
> CN=John R. Hover 47116/atlas/usatlas/Role=software/Capability=NULL\'.

The mechanism of propagating certificate attributes to resources is
discussed in detail in section 4.

### VO Administrative Infrastructure

The VO organizational structure is maintained by appointed
administrators of the VO and Groups. While this structure is made
available to the grid via a VO-dedicated VOMS service, membership
registration and maintenance is typically managed via a VOMRS service,
which is then synchronized with VOMS.

In VOMRS, administrator's rights are defined by 5 administrator\'s
roles:

1\. **VO Admin**: manages members, group, group roles, personal
information, administrator assignments, CAs, AUPs, expiration policy,
etc.

2\. **Representative**: approves members during initial registration,
responsible for setting institutional expiration date

3\. **Group Owner**: creates new subgroups and links existing group role
to the owned groups, assigns Group Owner and Group Manager for subgroups
of the owned group. Group Owner is a Group Manager as well

4\. **Group Manager**: assigns/de-assigns member to/from managed groups
and group roles

5\. **Site Admin** / **LRP** (Local Resource Provider): have access to
user public information (in use only by APAC)

### VO Registration Workflow

In order to register as a member of a VO and Group with certain Roles, a
user needs to submit personal information, sign usage policy agreements,
etc. In turn, the appropriate VO administrators must approve the
registration, in the correct order, following well specified workflows.

Two mechanisms, VOMS and VOMRS, are currently available to register
members, each using a different technology. A third mechanism,
Shibboleth, is under investigation. Each approach requires different
information from the user and implements a different registration
workflow. On the OSG, the most common registration mechanism uses the
VOMRS system. Appendix B details the workflow for each registration
system.

## Attribute Propagation Model

In OSG, sites grant users access to resources, because of their
membership in a VO. As discussed in section 3, a user can belong to
multiple Groups and multiple Roles, each potentially resulting in
different privileges at the resources. Therefore, this model requires
that users declare their membership to a VO, Group/Subgroup, and Role,
when requesting access to resources.

Such membership is embedded in the user credentials as an Attribute
Certificate (AC) \[ref.: RFC3281\] and is pushed to resources, which use
the AC during access authorization. Users obtain an AC by presenting
their credentials to a VOMS server. Upon successful authentication and
verification of the requested VO Attributes, VOMS returns new X509
credentials, extended with those VO Attributes and others (see Figure
3). Such extension is signed by the VOMS service certificate (typically
the host certificate of the node where VOMS is running).

The push model is only one of the possible ways of distributing
attributes \[ref.: 3281\]. Using a pull model, users could claim their
VO Attributes directly to the resources. During the authorization
process, the resource access service could contact the VO attribute
service (VOMS) and verify the user claim on her VO Attributes. From the
point of view of the user, this would be easier, since it does not
require a direct interaction with VOMS. However, in the pull model,
clients of all the grid services should be modified to pass VO
Attributes to the respective services. With the push model, instead,
clients don't need any modifications to pass AC's and/or user
certificates to their servers.

## Resource Access Control and Privilege Enforcement

On the Grid, resource authorization is generally controlled by gateway
services, e.g. the Globus Gatekeeper or the SRM interface to storage.
Using XACML \[ref: XACML\] terminology, these gateways are Policy
Enforcement Points (PEP) that receive user attributes from Policy
Information Points (PIP) (VOMS servers). PEP's rely on site-wide Policy
Decision Points (PDP) to implement resource authorization policies in
the form of access control and privilege enforcement. Access control can
be enforced using the Site Authorization Server (SAZ) PDP. Access
privileges are enforced at resources using UID/GID; sites use the GUMS
PDP to map Grid credentials to local Unix usernames, which are
translated in UID/GID pairs (with the additional RootPath information
for SRM).

Appendix C describes in more details the communication protocols between
PEP's and PDP's.

### Policy Enforcement Points

In OSG there are three types of PEPs:

-   **The CE gatekeeper**: running as a CE service, it provides a job
    management interface (submit, monitor, delete, etc.) to a local
    batch system. We generically call "gatekeeper" both the Globus
    Toolkit Web Services and pre-Web Services implementations. The CE
    service is started as root, thus can change UID

-   **The gLExec tool**: pilot jobs running on the worker nodes can
    invoke gLExec to stage-in user files and run user jobs under the
    appropriate UID. gLExec is deployed at each worker node. It is a
    SetUID-enabled executable, thus can change UID, independently of the
    UID of the invoking process.

-   **The Storage Interface**: running as a SE service, it enables
    access to files on the local file system. Available storage
    interfaces are SRM, native dCache, and GridFTP. The SE service is
    started as root, and thus can change UID.

See Appendix C for information about the PRIMA/GUMS and SAZ protocols.

### Policy Decision Points

OSG provides two site-wide PDP's: SAZ, for access control, and GUMS[^2],
for privilege enforcement. PEP's can be configured to use both PDP's,
one, or none (relying on legacy internal system for authorization
decisions, in this case).

For access control, SAZ implements site-wide white/black-lists policies.
Given a user certificate, it can authorize/deny access to resources
based on Certificate Authority, DN, VO, Group and Role. SAZ is currently
deployed only at Fermilab, where it is configured to deny access to
users without a Attribute Certificate, unless their DN is on a white
list.

For privilege enforcement, GUMS supports three types of mapping
policies: many-to-one, one-to-one and one-to-self.

In the **many-to-one** policy, all members with the same VO Attributes
are mapped to a single local UID or Group Account. In the OSG, this
mapping is acceptable even if may present concerns related to security,
including privacy. With many-to-one mappings a user can access files and
interact (kill, access memory, etc.) with processes from other users.
This includes accessing user proxies. Currently, in the OSG users
declare not to do this by signing an Acceptable Usage Policy (AUP) at
the time of registration with the VO.

In the **one-to-one** policy, a set of pool accounts is created on the
batch system and GUMS maps a user's VO Attributes to a unique account
from the pool. This mapping will then be maintained in the GUMS database
so that each successive request for mapping for that user will result in
being mapped to the same pool account UID. Using pool accounts prevents
users from accessing each other's data and processes. One-to-one mapping
also makes it easier to trace a rogue job to the originating user.

In the **one-to-self** policy, as the name suggests, a user is mapped to
her own local UID on the batch system. The mapping logic uses the user
name from the CN field of the user subject to map the DN to a local
account name, generally available from cluster-wide account distribution
systems, such as LDAP or NIS (e.g. "CN=Gabriele Garzoglio 762243" maps
to user name "garzoglio"). This mechanism is rarely used on the grid,
where accounts for opportunistic access are more easily managed in
pools.

### Typical Cluster Configurations

Typically, sites take one of three approaches to making user accounts
for the OSG. One is to create just the bare minimum of accounts, one per
VO, and sometimes one for multiple VO\'s. The second is to create the
user accounts as requested in the default GUMS configuration
(gums.template), i.e. to make pool accounts for the one VO (CMS) that
requests them and not for any other VO. This is Fermilab\'s approach.
The third approach is to make a common set of pool accounts and have any
number of VO\'s be mapped into the same set of pool accounts. This is
BNL\'s approach.

See Section 7 for problems with some of these configurations and
Appendix D for typical batch system configurations.

### Typical Storage Configurations

If a Storage Element consists of a deployment of SRM-dCache, the site
may configure its read/write properties through features provided by
that software. The authorization mechanism of dCache is managed by the
gPlazma component and it requires transactions to be performed under a
set of constraints. The three relevant properties for the constraints
are user id (UID), group id (GID), and root path. The dCache transaction
is performed using the UID and GID assigned during authorization. Read
and write permissions based on file or directory ownership follow Unix
file permissions, requiring a UID or GID of sufficient privilege for
access. The root path offers a further constraint, requiring all
transactions to occur within a portion of the file system namespace. The
properties of UID, GID, and root path are assigned based on the user\'s
credentials. Either or both DN and VO Attributes may be used to "map"
the user to set of constraints.

See Appendix E for examples of how policies may be implemented through
such mappings for storage elements.

## Access Accounting and Auditing

OSG uses the Gratia system for accounting. Its current implementation
does not record certificate attributes. Gratia, in fact, obtains
information from the batch system log files, where FQAN's have already
been translated to a Unix UID/GID. At the moment, Gratia links UID/GID
information to a VO via the osg-user-vo-map.txt file, which contains the
VO information for every user. This file has only UID information and
does not contain VO Attributes.

The Gratia accounting project is planning to get the information about
users' FQAN from the Globus GRAM auditing file. Some ongoing work is
needed from Globus to make this a usable format. In principle, FQAN's
for sites using GUMS could be inferred from the UID/GID by accessing the
local GUMS configuration. However, this "reverse" mapping is not always
unique and, in addition, some sites object to making the GUMS local
policy public.

Work on OSG Auditing is just getting started. The project is aware of
the necessity of accessing FQAN information from log files for auditing
purposes.

## Known Issues with the Infrastructure

The authorization infrastructure of the OSG is still affected by a few
issues. These issues are related to limitations in the software
deployment, operations, and functionalities. This section presents the
most relevant of the known issues.

### Wide-Spread Usage of grid-mapfiles

Many OSG sites still rely on legacy grid-mapfiles for identity mapping
decisions. This mechanism has several drawbacks:

1.  it is not site-central, thus it's difficult to maintain;

2.  it does not support AC's, thus the same user with membership in
    different VO's is always mapped to the same UID i.e. same
    privileges;

3.  it forces GUMS to map all people in a VO to the available pool
    accounts, when GUMS is used to generate the grid-mapfile (see "Pool
    Account Maintenance" later);

4.  it also has implications on resource accounting (beyond the scope of
    this document).

It is in the plan for FY08 to push a wider deployment of GUMS to OSG
sites and the use of AC.

### Propagation of New VO Structures and Policies to Sites

The Open Science Grid propagates information related to VO's via a VO
software configuration package. Experience has taught us that updates to
the VO package are not widely accepted and do not easily propagate
across sites. In addition, the OSG does not have an automatic way of
defining and publishing VO-related and sites-related policies. In other
words, VO's do not have a good way of expressing different policies
(e.g. priorities, data access, etc.) within their organizational
structure. Conversely, sites do not have a good way of publishing the
implemented resource access and priority enforcement policies i.e. VO's
cannot easily check if sites properly implement their desired policies.

Clearly, more needs to be done in this area. For example, today, the
only guidance on VO policy to sites consists in asking that the "mis" VO
have a lower priority in the batch system than any other VO (see OSG CE
install guide).

Another example is the lack of recommendations to sites on how to set up
user accounts. Today, administrators typically do this by reacting to
one of two configuration templates distributed through the OSG VO
package:

-   One template helps setting up a site to use grid-mapfiles
    (edg-mkgridmap configuration): this configuration does not have
    enough information to help with meaningful account creation.

-   The other template is for sites using GUMS. This template includes a
    few subgroups for some VO\'s and the full Role-based authentication
    structure for the CMS VO. Some VO\'s, DZero for instance, have
    requested an "analysis" role separate from the "production" role, to
    manage different priorities at sites. Though this role has been
    added to the default template, it has not been widely accepted
    across the OSG.

Fortunately, an SBIR Phase I grant in this area will bring some effort
to address some of the main problems.

### Pool Account Maintenance

When using pool accounts (one-to-one policy mapping of GUMS), site
system administrators are responsible to make enough pool accounts
available on each worker node in the batch system. For VO's with a
growing membership, this may become difficult. Attempts have been done
in the new version of GUMS (v1.2) to improve the reporting of errors
related to pool account exhaustion. There is no tool that helps with
error prevention, though.

A typical mitigation strategy to the challenge of maintaining several
pools of accounts consists in creating a single large account pool for
all VO's that do not have a special agreement with the site (i.e. for
VO's granted only opportunistic usage of resources). For example, this
is the configuration of accounts at BNL. However, in this case, because
of a limitation of the one-to-one mapping policy of GUMS, a user will
always be mapped to the same UID[^3], even if her AC's is generated by a
different VO every time. In fact, GUMS records only a DN (not a FQAN) to
UID mapping for a given account pool. Today, sites can avoid this by
creating different pools (or group accounts) for different VO's, even if
this implies a higher maintenance burden.

Another account management challenge is raised by the use of GUMS to
generate grid-mapfiles (generateGrid3UserMap interface). In this mode,
GUMS claims a pool account for every member of a VO, so that it can
generate a complete grid-mapfile for the VO. This forces administrators
to create a large number of UID/GID, even if only a fraction of the VO
members is active.

### Inconsistencies in VO Attributes Usage by SAZ and GUMS

Both SAZ and GUMS take policy decisions based on the user membership in
a VO. For example, SAZ can deny access to a site depending on the VO
name and GUMS may define a local ID mapping depending on it. However,
SAZ and GUMS use two different attributes to determine the VO parameter.
SAZ uses the attribute "VO" in the user proxy, if available. GUMS,
instead, uses the root of the full attributes string, e.g. in
"/atlas/usatlas/Role=software/Capability=NULL", GUMS uses "atlas" as the
VO.

Currently, only the ivdgl, mis, fmri, gridex, and osgedu VO's are
affected. The VOMS servers for all of them are maintained at Indiana
University, which uses a common root-level attribute, instead of the VO
name itself. IU is working to change this structure.

In general, both SAZ and GUMS should use the VO Attribute of the user
proxy, like SAZ. However, this requires a change to the PRIMA/GUMS
protocol that is not trivial to deploy, considering the growing number
of PEP relying on it. Since there are plans for FY08 to migrate PRIMA to
use an authorization protocol common to Globus, EGEE, and OSG, the
current strategy is mitigating operationally the problem, rather than
solving it technically.

Beyond the scope of certificate attributes, it should be noted that VO
names are affected by several potential problems in the OSG information
systems. In particular, name ambiguities are principal sources of
confusion. These ambiguities include uscms vs. cms, usatlas vs. atlas,
and VO names presented with different cases depending on the system,
most notably the LIGO VO.

### Attribute Validation and Site-wide Authentication

After interacting with a VOMS server, user credentials have two validity
dates: one for the user proxy, one for the Attribute Certificates (AC)
signed by VOMS. In OSG, though, the latter is not used in any policy
decision. Furthermore, AC's signatures are not validated. This means
that users expelled by a group or VO could, in principle, claim their
membership for a long time (until the validity of the proxy) or try to
claim certain memberships using deceivingly named VOMS servers.
Fortunately, GUMS synchronizes periodically (typically every 6 hours)
with every VO's VOMS, *de-facto* replicating the information on user
membership. Therefore, GUMS can enforce VO's membership changes every 6
hours.

This "safe-net" has a couple drawbacks, though. First, if the
synchronization fails (e.g. the VOMS server is temporarily down), GUMS
will use the old setting, in practice prolonging the ability of a user
to claim AC's. Second, replicating VO information to sites is a
potential privacy concern; for example, this policy would violate
European privacy laws. Currently, this is not a problem for US laws, but
this restricts the usability of the infrastructure to other countries.

A solution to this problem is validating the VOMS ACs. However, today
this is technically challenging. In fact, resources validate signatures
using the certificates of the signer. This means that certificate files
for all trusted CA's and VOMS's must be kept up-to-date at all
resources. Such synchronization is difficult to achieve, considering
that the typical validity of a VOMS certificate is one year and that the
resources involved at sites can be in the thousands (access control at
worker node using gLExec). Providing a central authentication PDP that
provides a validation service seems the common direction to address this
problem.

### Undefined Behavior for Proxies with Multiple VO Attributes

If a user is a member of more than one group, VOMS embeds in the
Attribute Certificate the list of all user groups. The "first" VO
Attributes of this list are the ones requested explicitly by the user,
the others are auxiliary information.

On the other hand, a user can request several VO Attributes for his
proxy by interacting with VOMS several times. Semantically, this is the
equivalent of embedding several "first" VO Attributes in the user proxy.
For example, a user could use this mechanism to claim membership to
multiple VO's at the same time

Despite the fact that certain use cases may be addressed via this
mechanism (e.g. enforcing complex data access policies), the current
infrastructure does not behave consistently under these circumstances.
In other words, the current OSG authorization infrastructure does not
support proxies with multiple "first" VO Attributes.

## -- VO Structures: the ATLAS Case Study {#vo-structures-the-atlas-case-study .Closing}

ATLAS is an example of a VO active on both the Open Science Grid in the
U.S. and the EGEE grid in Europe. As such, it has a relatively elaborate
group structure.

The groups in ATLAS can be divided into two categories. One set of
groups are related to geographic divisions within the VO. As noted,
\'/atlas/usatlas\' consists of members in the U.S. collaboration.
\'/atlas/lcg1\' consists of all the members in the European and Asian
collaboration, specifically members who typically use the EGEE/LCG grid.
\'/atlas/fr\' consists of French VO members, and \'/atlas/ca\' consists
of Canadian members.

The other set of groups is related to specific scientific subject or
activity groups within the experiment. Examples of these are
physics-related groups, e.g. \'/atlas/phys-hi\', \'/atlas/phys-higgs\',
\'/atlas/phys-top\', detector and trigger groups, e.g.
\'/atlas/det-muon\', \'/atlas/det-tile\', and software groups, e.g.
\'/atlas/soft-prod\', \'/atlas/soft-test\'.

Roles within ATLAS include: "AMIManager" and "AMIWriter", "VO-Admin",
"lcgadmin", "production", "root", and "software". The AMI roles are
related to the ATLAS Metadata Interface, a system for storing and
changing experiment metadata. \'VO-Admin\' is a role that exists for all
VOs, and defines who is a manager within the VOMS system. \'lcgadmin\'
defines an administrator role for the EGEE/LCG grid. \'production\' is a
role used by the ATLAS managed data processing system, which means that
it is used by automated systems, not by individual end users. \'root\'
is a role related to the use of the Root high energy physics analysis
and statistics package. \'software\' is the role used for software
installation at grid sites.

## -- VO Registration Workflows {#vo-registration-workflows .Closing}

Two mechanisms are used on the OSG to register users: VOMS and VOMRS. A
third mechanism, Shibboleth, is under investigation.

### VOMS Workflow

A user registering in VOMS:

-   must provide Last Name, First Name and email address

-   must provide email confirmation

-   must be approve by a VO administrator to become a member

Group, Role, and (on EGEE) Generic Attributes can be assigned by a VO
administrator or a person who has relevant ACL's for these actions.

User are not required to sign AUP

A user does not have a membership status and is not notified about any
changes in group, group role or attribute assignments.

### VOMRS/VOMS Workflow

A user registering in VOMRS

-   must provide personal information, which is customized dynamically
    by the VO[^4]. VOMRS can interface to third party databases, like
    the CERN HR Service or Fermilab CNAS to check attributes relevant
    for the users.

-   must select Institution and Representative

-   must provide email confirmation

-   must sign Grid and VO Acceptable Usage Policy documents

-   is allowed to request group and group role assignment

-   is allowed to request a General Attribute, if VO supports it.

A chosen Representative or a VO Admin can approve a user as a valid VO
member. A corresponding Group Owner/Group Manager or a VO Admin can
approve/deny Group/ Role membership at any time.

A VO Admin handles Generic Attribute assignment.

DN and CA of a member in good standing ("Approved" status) is added to
VOMS. Approved membership of the Group, Role and Generic Attribute
assignments are also propagated to VOMS.

### Shibboleth Workflow

The following are the main entities in the Shibboleth architecture:

**Service Provider** **(SP)**: Provides services to internal and
external users. Focuses on core business logic and avoid risks of
managing user confidential information.

**Identity Provider (IdP)**: an Attribute Authority that manages and
asserts user's attributes to trusted SPs securely.

**Federation**: manages trust between all parties)

A user that tryes to access a Service Provider is re-directed by
Shibboleth to an appropriate IdP, which may require authentication via a
login or a certificate.

The IdP creates a SAML assertion and forwards it to the SP.

The SP uses SAML to retrieve additional attributes from the IdP.

Shibboleth validates the assertion and maps the user to a SP role.

## -- PRIMA/GUMS SAML and SAZ Protocols {#primagums-saml-and-saz-protocols .Closing}

### GUMS

GUMS is the OSG identity mapping service. It is a Web-based service that
communicates using an extended[^5] version of the Security Assertion
Markup Language (SAML) v1.1 \[ref. SAML\] over SSL. The SSL connection
is secured by the client\'s host certificate (or a host proxy). The same
proxy is also used for authentication and in the mapping function.

SAML is an XML standard for exchanging authentication and authorization
data between security domains. The GUMS SAML request contains the final
user DN and that user\'s "first"[^6] VO Attributes, if any. GUMS will
reply with an \"accept\" or a \"deny\", and in case of an \"accept\", it
will also send along the \"UID\" to be used for local user mapping.

While GUMS comes with a basic client interface, the PEP's use the PRIMA
C or Java libraries to interface to GUMS.

### SAZ

SAZ is a site-wide authorization PDP developed at Fermilab. It is a
server process that communicates over the network using a Globus
GSI-secured connection.

The client secures the connection by either using the host certificate
or the user proxy. The whole user proxy is then sent over this
connection to the server; then the server replies with a "yes" or a
"no". This protocol transports the private key of the user proxy over
the (secure) network and, therefore, presents security concerns. Thus, a
new version of the protocol is being designed. This would transports
credential information by means of GSI delegation or by sending all
relevant credential attributes only.

## -- Typical Batch System Configurations {#typical-batch-system-configurations .Closing}

Most grid sites take a three-tiered priority scheme for their batch
systems. Namely they let the jobs from their own VO or VO\'s run at
highest priority, jobs from other friendly VO\'s run at second priority,
and jobs from opportunistic VO\'s run only as cycles are available.
There are a number of different ways to implement these priorities.

**Quotas**: Most batch systems have the option to limit any given user
or group of users to a certain number of jobs. Condor does this with
group quotas. PBS has a certain limit of total jobs that can run
simultaneously from any given queue. In both cases, these quotas only
guarantee that a user can never run more than N number of jobs, there is
no guarantee that a user can run at least N number of jobs (this feature
is coming to Condor shortly.) A couple of sites at Fermilab are forcing
all incoming condor jobs to have a group and thus a group quota, to
enforce quotas. In this example, the various subgroups of the Fermilab
VO have quotas ranging from 50-200 batch slots, friendly VO\'s have 25
batch slots, and guest VO\'s start out at just one batch slot.

**Fair Shares**: Most batch systems have a fair share mechanism built
into them, that temporarily adjusts priorities between users or queues
such that each user gets a chance to run. Rather than manipulating this
mechanism itself, it is more common to use preemption and priorities to
tweak it.

**Priorities**: Most batch systems allow different priorities for
different users, in addition to quotas, such that VO A\'s 50 jobs would
start more quickly than VO B\'s 50 jobs. In PBS, this could be
implemented with different queues for different VO\'s. In condor, it
would be implemented with user priorities. A simple configuration is to
give all users a default very low priority and then manually improve the
priorities of those that you want to run faster.

**Preemption**: Under any batch system, it is necessary to configure the
batch system so that one user can\'t fill the site with infinitely long
jobs. This is enforced by either killing jobs longer than a certain
advertised wall time (although it has been noted many times that this
wall time is not configured uniformly across the OSG) or by pre-empting
the jobs of lower priority users. A common configuration on Condor sites
is that any job of the non-host VO can be pre-empted, but it will get 48
hours from the time it is pre-empted to finish out the job.

**Process Protection**: There is little process protection built into
the current OSG setup. i.e. if one process disables a worker node by
either using all memory or all disk, other processes will get killed. To
overcome this problem, one site (SDSC) runs each job in a separate
"chrooted" environment. However, this technique has not yet been made
easily portable. Also, for VO\'s which use group accounts[^7] (the
majority) it is possible that one user could read and/or modify the
other\'s files and process memory space, including proxies. There has
never been an OSG consensus on whether this policy should be allowed.

Some sites use a technique called "sandboxing". Each process runs as one
of five or six Unix UID/GID\'s depending on which job slot it is on at
the time. Such a process is only tenable if there are no NFS-mounted
areas to which the sandboxed processes can write and all access to mass
storage is done by x509-authenticated means, such as SRM, gsiftp, or
dcap.

**Making the batch system aware of roles**: on the OSG, all batch system
policies are done by means of UID/GID. There is no native awareness in
the batch system of VO Attributes. Condor does have the capacity to
identify users and set priorities by DN, instead of by UID/GID, but it
is unaware of VO Attributes. This capacity has been promised in the
6.9.x development release. It is unlikely that other batch systems will
get similar features.

In the longer term as VO\'s want to have a more complicated role and
privilege structure, the only scalable way to do this is from VO job
aggregation points such as Panda or glideWMS. In this way the VO can
control priorities down to the n\'th degree on the submit end without
having to have every site create a large number of different users (with
a manually-set batch system priority for each).

## -- Typical Storage Configurations {#typical-storage-configurations-1 .Closing}

As stated in Section 5, for Storage Elements (SE) consisting of a
deployment of SRM-dCache, the authorization mechanism of dCache assigns
each transaction a set of properties consisting of UID, GID, and root
path. These properties are based on the user\'s FQAN. Unix file
permissions are respected for UID and GID, along with the further
limitation that only files in the file system hierarchy under the root
path may be accessed. The site may specify mappings to UID, GID, and
root path based on a combination of the user's FQAN. The following is a
discussion on two typical policies

**Full Privilege Access**: All members of a specific VO might be given
equal access to files created by anyone in the VO. In that case, the
mapping would be by group only, and all files would be owned by the same
UID and GID.

**Read-only Access**: Members of a VO may be given the right to read any
other member\'s files, but not modify them. Then the DN could be used to
map to UID and the group used to map to group id. Files would be
read-writable by the owner, and readable by the group. The root path may
be used to make users\' files inaccessible to others by giving each user
their own home directory.

**Discriminate Read/Write Access**: the root path can also be used to
allow users with privileged roles to write to specific areas of the file
system, which may be read-only to others or be on tape-backed disks. The
policy of many dCache sites in the world is to assign pool accounts to
individuals by DN and use Unix group membership as an analog to VO
membership (by convention, the group attribute of the credentials).
There are major experiments, however, that use group accounts and assign
all members to the same UID and GID. Complications may arise for
posix-compliant access to files if the user mapping in the Compute
Element does not match that of the Storage Element.

It is possible to map to a fourth constraint, "priority", which would
allow users of sufficient privilege to have their requests queued ahead
of others, however, the current version of SRM-dCache does not enforce
this constraint.

In the next version of SRM-dCache, users may reserve space and write
files against the space reservation. The privilege here rests on the
authorization mechanism already described, hence the same flexibility as
with file ownership applies, i.e. space reservation privilege is a
function of DN and group/role. Since space reservation also relies on
the configuration of dCache storage areas, further dependencies on the
user\'s IP address and the protocol of the transaction are supported. In
addition, any of the above mappings may be combined into a single space
reservation privilege. It is likely that sites will require special
roles for making space reservations, perhaps even roles whose
acquisition is limited to site administrators.

## -- Glossary {#glossary .Closing}

##### Attribute Certificate:

**Capability:** A VO Attribute associated with a user. It is not used in
OSG.

**Certificate Authority (CA):** An organization that issues grid
certificates to individuals and/or for computing hosts, and that is
known and recognized by other institutions.

**Distinguished Name (DN):** A globally unique string which
characterizes a grid identity, e.g.
"/DC=org/DC=doegrids/OU=People/CN=John R. Hover 47116"

**Fully Qualified Attributes Name (FQAN):** A DN concatenated with a set
of VO Attributes; e.g. "/DC=org/DC=doegrids/OU=People/CN=John R. Hover

47116/atlas/usatlas/Role=software/Capability=NULL"

**Gatekeeper:**

**Generic Attribute:**

**gLExec:**

**Grid Certificate**: A long-lived SSL certificate issued to an
individual person by a recognized CA that conforms to the X.509
standard.

**GridFTP:**

**Grid Proxy**: A short-lived temporary SSL certificate generated by a
user, and signed using their Grid Certificate.

**Grid Site:** A computing facility that provides a grid interface to
their institution\'s computing resources, e.g. computation, storage, or
other services.

**Group:** User group in a VOMS server; membership inherits upwards;
members of subgroups are automatically members of parent groups.

**Group Account:**

**GUMS:**

**Pool Account:**

**Public Key Infrastructure (PKI):** A scheme for distributed
authentication using private/public key cryptography and a system of
registration authorities.

**Role:** A VO Attribute associated with a user.

**SAZ:**

**SRM:**

**Secure Sockets Layer (SSL):** A scheme for authenticated network
connections using X.509 certificates.

**Virtual Organization (VO):** A set of DNs and associated groups,
roles, and capabilities. Membership is managed by VO managers, and
embodied in a VOMS server for use by a Grid.

**Virtual Organization Membership Service (VOMS):** Software web service
and application that stores users and user attributes, and allows users
to generate VOMS proxies.

**Virtual Organization Management and Registration Service (VOMRS):**
Software web service and application that provides a higher-level
interface to VOMS, allowing easier, automated registration workflow and
member administration.

**VOMS Proxy:** A temporary user-generated X.509 certificate (Grid
Proxy), extended with an Attribute Certificate by a VOMS server. VOMS
verifies that the user is a member of the VO, and indeed has the
attributes (Groups, Roles) the user claims.

**X.509:** An IETF standard for public key infrastructure. Used by SSL.

## References {#references .References}

-VOMS: R. Alfieri, R. Cecchini, V. Ciaschini, L. dell'Agnello, A.
Frohner, K. Lorentey , F. Spataro, "From gridmap-file to VOMS: managing
authorization in a Grid environment", Future Generation Computer Systems
21 (2005) 549-558

\- VOMRS:

\- XACML

\- SAML

\- FQAN: A. Frohner and V. Ciaschini, VOMS Credential Format, EDG Draft,
2004.

\- RFC that defines X509 certificate format

<http://www.faqs.org/rfcs/rfc3280.html>

\- RFC that defines an "attribute certificate", its delegation,
distribution models

<http://www.networksorcery.com/enp/rfc/rfc3281.txt>

\- Attribute Propagation models:

*http://cd-docdb.fnal.gov/cgi-bin/DisplayMeeting?conferenceid=323*

[^1]: Often, FQAN is used as a synonym for the VO Attributes only. In
    this document, we consistently distinguish between the two concepts.

[^2]: It should be noted that GUMS implements a very limited form of
    access control, when no username can be found for a given set of
    FQAN. In that case, access is denied.

[^3]: The UID used will be the first assigned to the user at the site.

[^4]: In principle, the personal information required by the VOMRS
    interface can be different from the one required by the VOMS
    interface (except from "email", the "name" fields can be blank).

[^5]: The protocol extends SAML with XACML Obligations, as a way of
    communicating identity mapping information back from the PDP to the
    PEP.

[^6]: If a user is a member of more than one group, VOMS embeds in the
    Attribute Certificate the list of all user groups. The "first" VO
    Attributes of this list are the ones requested explicitly by the
    user.

[^7]: Groups accounts are defined using the many-to-one GUMS mapping
    policy.