Document Name Attribute Certificate Validation on the Open Science Grid
Authors G.Garzoglio, Mine Altunay
OSG Document # 756
Version Date Comment
001 April 21, 2008 First complete draft
Attribute Certificate Validation on the Open
Gabriele Garzoglio, Mine Altunay
Mar 04, 2008
At the Grid Coordination Meeting on Sep 25, 2007, it was discussed how to implement Attribute
Certificate (AC) validation for the OSG. Typically, AC validation is a step in user authentication,
whereby the authenticity of the attributes associated with user credentials is verified via
In OSG, users embed VO information as AC in their credentials by interacting with VOMS. A
typical example of such AC is the membership of the user to a VO group. With the current
infrastructure, AC validation is not strictly necessary to guarantee proper resource access
authorization. The authorization infrastructure (GUMS), in fact, is kept synchronized with the
authoritative source of information on VO attributes (VOMS).
One of the action items at the meeting was producing "a list of use cases as to why we should
work towards no longer needing the VOMS/GUMS synchronization".
This document addresses the action item above, describing pros and cons of both approaches. It
is written as a collaboration between the VO Services project and the OSG for the OSG.
The Validation Problem
In the OSG, as well as in other large grid infrastructures, access authorization to resources and
user privileges are typically granted to users on the basis of their membership to a VO / VO
group / VO group role, rather than on the basis of the user identity.
Users assert their membership to a VO / VO group / VO group role by asking VOMS to embed
this information as an Attribute Certificate (AC) in their credentials (user proxy). An AC, as the
word suggests, is a list of attributes digitally signed for provenance and integrity by the attribute
authority (VOMS). The resulting user credentials are referred to as an "extended" (by an AC)
Users submit access requests to OSG resources presenting their extended proxy to the resource
gateways. Since authorization is provided on the basis of the AC, it is very important to validate
that the AC has been issued by a trusted authoritative source i.e. a trusted VOMS.
In this document, we are comparing two different mechanisms to achieve this goal:
1) AC validation
2) GUMS/VOMS synchronization
Resource gateways, such as the Globus Gatekeeper, SRM/dCache, or gLExec, can validate
provenance and integrity of an AC using cryptographic functions. AC, in fact, is digitally signed Comment [m1]: Are these functions already
available ? or are you meaning to say “ we can
by the issuing VOMS. Gateways can define a set of trusted VOMS, by pre-installing the VOMS implement if we want to”
identity information needed by these cryptographic functions.
Since VOMS v1.7, this VOMS identity information consists of a text file per VOMS. This file
contains the VOMS service certificate subject and the corresponding subject of the signing
Certificate Authority (CA) for the trusted VOMS service certificate (in reality there is one such Comment [m2]: Below you said the VOMS
certificate is embedded? Are these contradicting
pair per component of the service certificate chain, excluding the CAs certificates). statements ?
In VOMS v1.7, the cryptographic validation can occur, because VOMS signs the AC with its
private key and embeds the corresponding service certificate (public key) in the AC. In turn,
when it was issued, the VOMS service certificate was signed by the private key of the issuing
Certificate Authority. At the gateway, as for all GSI-based infrastructures, the certificates of the
trusted CAs are pre-installed at the site. Thus, the validity of the VOMS service certificate,
embedded in the extended user proxy, can be verified by the gateway using the pre-installed CA
certificates. If the subject of the VOMS service certificate is also listed in one of the VOMS
identity information files, then the VOMS is trusted (in reality also the AC in the VOMS identity
file is checked in the validation process). Therefore, its service certificate can be used to validate
the signature of the AC.
In addition to authenticating the VOMS server, the site must also “authorize” the VOMS server;
meaning that VOMS server must belong to a VO to which, the site has agreed to provide access.
In VOMS servers prior to v1.7, VOMS did NOT embed its service certificate in the AC of the Comment [m3]: Is it the whole certificate or just
the subject DN or public key? Where can I get info
extended user proxy. In this case, the VOMS identity information needed to cryptographically on this?
validate the AC consisted in the VOMS service certificate itself. The signature of the AC was
validated against the pre-installed VOMS service certificates, which were in turn validated with
the pre-installed CA service certificates. This validation mechanism required that the list of
VOMS service certificates be maintained up to date at each gateway. Considering that service
certificates expire annually and that several dozens VOMS servers are trusted by large grids, this
was not an easy task. Therefore this mechanism was abandoned in favor of the more
maintainable mechanism described below.
Because of the difficulty to maintain a list of trusted VOMS servers at each site prior to VOMS
v1.7 (see above), OSG has historically implemented an alternative mechanism to implement AC
In the current infrastructure, resource Gateways only validate that the extended user proxy is
signed by a trusted CA (AC are NOT validated). The information on the user and its
(invalidated) attributes is then sent to the local authorization and mapping service (GUMS). This
service checks its local database to verify that the user is allowed to claim her associated
attributes i.e. user belongs to a certain VO group with a certain VO group role. GUMS
synchronizes its database with VOMS (by downloading the VO member’s Distinguished Names
and FQANs), the repository of such information, every six hours.
GUMS informs the gateway to accept/deny access to the user with her attributes. In addition, if
the user is accepted, GUMS informs the gateway of her local POSIX privileges by returning an
appropriate local user account.
Comparison between AC Validation and GUMS/VOMS Synchronization
This section addressed pros and cons of both approaches. It should inform OSG on the benefits
of AC Validation, before committing to changing the infrastructure.
European privacy laws prevent institutions from keeping user's personal information without
previous consent. In the context of the Grid, this means that sites cannot keep lists of users DN,
VO membership, etc. unless a user has previously accessed the site. By accessing a site, users
implicitly agree for the site to keep records for the purpose of accounting, auditing, mapping, etc.
By synchronizing with VOMS, GUMS effectively keeps a database of user information at the
site, including all members of a VO. This would be illegal according to European privacy laws.
In the US, privacy laws are more relaxed and there are not such restrictions. Adopting AC Comment [m4]: Can we cite something here –
this is a legal statement and I rather cite something
validation, instead of VOMS/GUMS synchronization, would bring OSG in line with the
European standards on privacy.
Becoming Attribute-Provider and Technology Independent
Currently, GUMS is dependent on VOMS as the sole attribute provider, due to its
synchronization issue. This would affect our future progress towards embracing different
attribute providers, such as Shibboleth, openID, Higgins, and likes. Although, such
improvements may take a few more years to come, we must consider the future changes
while doing our current planning. (Globus is looking to work with such technologies – and
currently evaluating openID for one of their projects.)
Instead of GUMS connecting to each VOMS server and downloading DN and FQANs, it
would be more useful to develop a uniform FQAN structure and have GUMS validate the
attributes regardless of which attribute provider generated them. Current identity
management systems (e.g. CardSpace by Microsoft, Higgins by IBM and Shibboleth)
implement the FQANs as SAML tokens and sign them. The user would present signed
tokens to the relying parties for access, the gatekeepers in our case. Since the current
VOMS also signs its attribute tokens, by removing the synchronization, we do not sacrifice
our ability to use VOMS. Instead, we open up for other technologies. With the current
GUMS implementation, we cannot use other attribute providers because 1) they do not
allow a relying party (i.e. GUMS or gatekeeper) to access their whole database and
download their membership 2) they have a different data structure in their database – not
necessarily DN and FQAN 3) they have different push-pull mechanisms between users
Attribute provider and Relying Party. CardSpace and Higgins, for example, only releases
attributes to users and after the user consent, attributes are released to relying parties
As a future step, we can focus on developing a uniform FQAN structure and
implementation in a common wire-protocol such as SAML so that we can embrace newer
technologies as our needs changes. Moreover, we can maintain the uniformity of FQANs
across the sites and grids. Different interpretation of FQANs across the grids is a concern
expressed by OSG and EGEE.
Enforcing AC validity time
In addition to VO attributes, AC contains a validity time attribute. This time is defined by the
VO and indicates for how long the VO attributes should be considered valid. It should be noticed
that this time can be different from the validity time of the user proxy.
In the current model, AC is NOT validated, therefore the validity time cannot be trusted and used
at the gateways. VO policies on attribute validity cannot be enforced on the OSG.
In addition to VO policies, in Europe, there are ongoing discussions on enforcing a Grid-wide
policy on an acceptable maximum AC validity time. The policy would be enforced at the sites,
by passing the validity time to the site authorization infrastructure. Today, no site authorization
software in OSG allows expressing policies on the AC validity time. To achieve this goals, one
would need to do features development in the site authorization software (i.e. SAZ or at
authentication layer) AND enforce AC validation at all sites.
Propagation Promptness of Attribute Changes
When attribute information changes in a VO (e.g. user membership to a VO group is revoked),
one would like to propagate this information to resources as promptly as possible. The two
models under discussion have different properties to this regard.
With AC validation, user information in the extended proxy is valid for as long as the AC
validity time. In other words, an unauthorized user can still get authorized to access the site if her
AC was requested before the membership revocation occurred and for all the validity time of the
AC. The impact of this can be evaluated considering that a reasonable policy for the validity time
of AC is on the order of a few days. However, this problem can be solved by adopting a banning
tool such as SAZ. SAZ can ban users based on DN, VO membership, VO role, and issuer CA.
Therefore, a user banned from a VO can immediately be banned from a site as well. Moreover,
using a true banning tool, instead of relying on VOMS/GUMS synchronization, would allow
banning a dangerous user less than 6 hours.
With GUMS/VOMS synchronization, there is still the possibility to authorize unauthorized
users, because the information is pulled by GUMS from VOMS periodically. The impact,
however, is arguably more limited, considering that the typical synchronization time lag is 6
hours. On the other hand, GUMS/VOMS synchronization can prevent authorized users (e.g. new
VO members) from getting access to resources until the "next" synchronization occurs. If GUMS
cannot synchronize the database for any reasons (e.g. network problems, etc.), the problem can
GUMS Database Size and Network Traffic
Using the GUMS/VOMS synchronization mechanism, GUMS effectively keeps a local copy of
all users from all trusted VOMS (...getting db size from FermiGrid...). Also, this information is
propagated over the network every 6 hours. Considering the current cost of disk space and the
availability of network resources, this is generally deemed of minor impact. Comment [m5]: Eileen, Gabriele I believe the
accuracy of your observation here. However, for
future when we have more than 35 VOs – can we
Using GUMS to Generate gridmap-files
still claim that this would not be an issue for the sites
? for example can we put some data to show the size
of current db and how much network traffic every 6
In OSG, GUMS is sometimes used to create gridmap files at sites. This feature of GUMS was hours for synch.
introduced to let administrators transition to fine-grain authorization with a gradual process, first
checking that GUMS could produce consistent gridmap-files, then removing the dependency on
gridmap-files and going directly to GUMS for fine-gain authorization decisions.
GUMS can create gridmap-files for sites because all user information for all VOs are kept in its
database via the synchronization process. Should OSG decide to abandon this process in favor of
AC validation, gridmap-files could not be created anymore. Administrators would have to adopt
a more abrupt transition process to fine-grain authorization. To ease this burden, OSG can
provide gridmap-files generated by the GOC and present it to the sites.
Maintaining the VOMS Files at all OSG gateways
Either with synchronization or AC-validation, OSG would have to maintain and distribute the list
of VOMS information files. In the former case, the files should include the VOMS server
address (service URL for download) and the service certificate in order to authenticate the
VOMS server. In the latter, the service certificate of the VOMS server would suffice. Since
VOMS v1.7, this information is fairly static, since it includes the VOMS service certificate
subject and the corresponding issuing CA certificate subject. This information is typically the
same even after service certificate renewals. Nevertheless, it should be maintained very
accurately, as wrong information can cause denial of services for a whole VO.
Currently, GUMS do not authenticate the VOMS servers. This is a serious vulnerability since
VOMS servers are crucial for access and maintain sensitive information. Man-in-the-middle type
attacks, or IP-spoofing attacks can cause a GUMS server to connect to a malicious VOMS server
set up by an attacker.
This is an OSG requirement that with or without synchronization, each GUMS server
must authenticate the VOMS server before downloading membership data. There must be
a secure connection between the GUMS and VOMS server. Finally, each site must keep a
list of VOs that they would like to provide access (VOMS “authorization”). The VOMS
server certificates must be included in this list. This is to ensure that each site only provides
access to the VOs that they collaborate with (i.e. authorizing the VOMS servers); OSG does
not mandate sites that they have to provide access to each VO within OSG
DN String Comparison
Formatted: Font: Not Bold
Today having different string representations of user DNs causes headache. GUMS may need to
store different representations or needs to know how to parse a DN string. By having AC
certified certificates, GUMS can get rid of this problem completely because GUMS no longer
cares on the DN string representation but only on the valid AC and CA signatures
Performance and Caching Formatted: Heading 2
Having all VOMS membership information downloaded at GUMS database provides an
advantage when the VOMS server goes offline. The GUMS server can continue determining
membership by using the latest-downloaded information. Since the user does not need to get
signed attributes (because GUMS has the latest database entries), the down time of a VOMS
server may not disrupt the operation.
Assuming there is no synchronization between VOMS and GUMS, if the VOMS server is down,
the user has no way of gaining signed attribute credentials. Without signed credentials, the
authorization cannot take place. As a similar remedy, the site can generate a cached list of
authorized users while the VOMS server was still functioning. This cache can be used as a
backup when the VOMS server does not function. The downside with this cache is that the
cached information maybe very old. Since there would no periodic synchronization between
VOMS and GUMS, the cached information is left from the last time the user requested an
authorization decision. The odds that this authorization decision may have become stale are
higher than the synchronization case, where the synch happens every 8 hours.
In both cases, with or without synchronization, there is a need to contact the VOMS server.
Without synchronization, the burden of contact is on the user, the GUMS server does not need
any off-site connection. But down times of VOMS server may become an issue. With
synchronization, the burden of contacting is on GUMS. But the cached data can be used even
when the VOMS server is down.
Formatted: Font: Not Bold
. Formatted: Normal
Privacy Attribute- Enforci Banning GUMS db Ease of VOMS Formatted Table
provider ng AC- VO & transition files at Formatted: Space Before: 0 pt, After: 0 pt
Dependennc validity usersPropa Network Plain gateways
y time gating traffic from grid-
Attribute map- file
Synch None VOMS- None Every synch Increases Yes Yes –
dependent time – 6 proportiona needs a list
hours lly with of VOMS
number of servers
VOs and (URLs) to
members and their
AC- Yes No- Yes To ban None None – Yes, needs
validation independent before AC- GOC can a list of
Yes validity GUuMS db provide a VOMS
duration would only plain grid- servers
expires— include VO map file to and their
must use a FQANs and ease the certificates
banning tool would not burden s
like SAZ need DNs
Formatted: Normal, Space Before: Auto,