Background: Cryptography and Trust

Identity is one of the most important issues in Grid computing. It is necessary for determining who the remote party is (authentication), who is allowed to perform what actions (authorization), and who did what and when (auditing). The use of asymmetric cryptography (public/private keypairs) enables communicating parties to “prove” their identity by digitally signing messages with private-keys that only they should be in possession of. The identity (i.e., “Andrew Grimshaw”) and its corresponding public key are freely dispensed in the form of digital certificates (e.g., X.509 digital certificates), and are used to verify message signatures.

It is important to know that a logical identity that is represented by some string, e.g., “Andrew Grimshaw” is bound to a specific public-key. This is accomplished by having a “Certificate-Authority” (CA) digitally sign the identity certificate (containing the string “Andrew Grimshaw” and the corresponding public key), asserting that the true Andrew Grimshaw should be the only entity in possession of the corresponding private key. The Certificate Authority uses its own private key to sign this Andrew Grimshaw certificate.

The digital certificate corresponding to the Certificate-Authority’s keypair may itself be signed by a Certificate-Authority-Authority. The chain of signed certificates may be arbitrarily long, with each intermediate CA vetting the identity of the next. At the “bottom end” of the certificate chain is the end-entity certificate, “Andrew Grimshaw”. At the other end is the “root CA”, e.g., “UVa PKI Standard Assurance”. In order to trust that the real Andrew Grimshaw was granted a particular certificate and keypair, one must simply know and trust the root CA, and assume that it and all of its subordinate CAs have exercised prudent judgment when issuing digital certificates for keypairs.

Identity Management in Genesis II

Identity is one of the most important issues in Grid computing. It is necessary for determining who the remote party is (authentication), who is allowed to perform what actions (authorization), and who did what and when (auditing). Genesis II supports a number of identity standards that are defined for Web Services. These currently include X.509 digital certificate, username/password, and SAML token profiles.

Resource Identity

All Genesis II Grid resources are given X.509 identities, each consisting of an X.509 digital certificate and a corresponding public/private keypair. These cryptographic identities can be used by clients to ensure that they are indeed communicating with the intended Grid resource (as opposed to being spoofed).

A Grid resource’s X.509 certificate is signed by the X.509 identity of its parent Web Service instance (e.g., the Genesis II Container’s Web Service instance for RNS, ByteIO, BES, IDP, etc.). The certificates for the Web Service instances are signed by the identity of their hosting Genesis II Container. (The X.509 identity for the Genesis II Container is also used as the SSL server-socket identity for HTTPS communication to/from that container.) The certificate for the Genesis II Container is typically signed by a global Certificate Authority (CA) that is “trusted” by all Grid participants.

User-principal Identity

User-principal tokens are security credentials that state different facts about you. For example, one security credential may claim that you are “John Smith” as vetted by State University, and another that indicates you are a member of the Astronomy Department. When using Genesis II you can “carry” as many different identity tokens as you want.

User-principal tokens are used by Genesis II resources to perform access-control. When performing an operation on a Genesis II resource, the user-principal credentials are conveyed within the request message and checked against that resource’s security policy to decide whether to allow or deny the operation.

Existing Identities

Genesis II is very flexible with regard to user-principal tokens. In many cases, users wishing to participate in a Genesis II Grid will already possess an X.509 identity (digital certificate and public/private keypair), supplied from their organization. The Genesis II login commands make it simple to “carry” this credential for grid use. For example, you can use the login tool to acquire an X.509 credential stored within the Windows keystore or other popular keystore formats (e.g., PKCS12, JKS, etc.). The corresponding X.509 digital certificate is your identity and is conveyed within outgoing messages, but the private key is only used to sign messages and never leaves your process’s address space.

Additionally, GenesisII can also virtualize directory identities, such as those from Kerberos, MyProxy, NIS/YP, LDAP, etc.

The login command also allows users to convey Username/Password credentials within outgoing messages.

Delegated Identities

For security reasons, it is never a good idea to let the private key for a corresponding security token credential leave your machine/device. As such, Genesis II provides a mechanism to “delegate” credentials that have associated public/private keypairs.

When you acquire an X.509 identity (e.g., Andrew Grimshaw) by logging into a local keystore (e.g., the Windows keystore or a .pfx keystore file), you are actually delegating that identity to the Grid Shell process (or IFS process, or OGRSH process), which itself has its own X.509 identity. Your private key is used to sign an SAML document indicating “Andrew Grimshaw says Grid Shell XYZ can be Andrew Grimshaw for 24 hours”. The login tool has options that limit the duration and number of subsequent delegations allowable for an identity credential. When your Grid Shell (or IFS or OGRSH server) subsequently makes a Web Service request on a remote Grid resource, the identity conveyed is the X.509 digital certificate “Andrew Grimshaw”, but the security credential is actually an enclosing SAML document saying “Andrew Grimshaw says Grid Shell XYZ can be Andrew Grimshaw for 24 hours, Grid Shell XYZ says Queue 123 can be Grid Shell XYZ”. Hence Queue 123 can perform duties on behalf of Andrew Grimshaw, such as scheduling the job on an available BES when the time is appropriate.

Identity Provider Resources

IDPs for New Identities

New identities can be created and managed using Identity Provider (IDP) resources. An IDP resource is a Grid resource that delegates security credential(s) to the caller. The IDP service interface is defined by the WS-Trust standard. Each Genesis II Container hosts an IDP Web Service instance that can be used to create and manage individual IDP resources.

By creating new IDP resources using the create-user Grid Shell tool, one can create new security credentials that can be used to indicate facts about a user-principal, such as identities (e.g., “Jane Smith”), roles (e.g., “Faculty”), privileges (e.g., “Level 5”), etc. IDP resources are typically given names and linked into the RNS namespace.

In order to be delegated a security credential from an IDP (i.e., login to it), you must be allowed “execute” permission on that IDP resource. Typically an IDP resource has been configured to accept users conveying a specific Username/Password credential.

IDPs for Delegating Existing Identities

There are many scenarios in which a user-principal may wish to operate as Andrew Grimshaw, but may not want to expose the corresponding private key to the local Geneisis II installation, portal, etc. For example, a mobile user may be accessing the Grid from many different Genesis II installations over a period of time. In this case, the user can use the create-user-delegate command create an IDP resource “GrimshawProxy” around a delegated credential for their Andrew Grimshaw identity: “Andrew Grimshaw says IDP resource GrimshawProxy can be Andrew Grimshaw for 30 days”. If execute-access on the IDP resource “GrimshawProxy” is then configured to allow callers who carry a particular Username/Password credential, then the user-principal can obtain a restricted “Andrew Grimshaw” credential from any location. To do so, they simply use the login tool along with the correct Username/Password to obtain the credential “Andrew Grimshaw says IDP resource GrimshawProxy can be Andrew Grimshaw for 30 days, GrimshawProxy says Grid Shell 123 can be GrimshawProxy for 24 hours”.

Unfortunately, other OGSA-compliant Web Service –based grid resources are not, at present time, likely to understand our SAML delegated-credential format. Consider the scenario in which a Genesis II Queue “123” is configured to submit jobs to a non-Genesis II BES container “Bar”. The delegated SAML credential containing the original owerner’s identity may not be understood, but the run-job message additionally conveys the caller’s X.509 certificate (in this case, the “Queue 123” identity) as well as any Username/Password tokens in accordance with the WS-I Basic Security Profile.

IDPs for Kerberos, MyProxy, InCommon, NIS, LDAP, etc.

Genesis II also allows administrators to configure identity provider service endpoints that virtualize the identities managed within an external JNDI-compatible directory system (e.g., NIS, LDAP, etc.).

As an example, the interface of a NIS-configured IDP service endpoint is an RNS directory whose entries are IDP resources for the individuals who have NIS accounts in the specified NIS domain. A NIS IDP resource is similar to an #IDPs for a New Identity in that a new X.509 certificate for the virtualized NIS account is created that identifies the user, the user's NIS UID, and the Grid NIS endpoint. In order to acquire a delegated security credential from a NIS IDP (i.e., login to it), the user must carry a specific Username/Password token that can be used to authenticate the password hash of their NIS account.

Using IDPs for Single-Sign-On

In many cases, a user may wish to acquire multiple security credentials for their Grid session. It may be tedious and inconvenient to individually use the login command to obtain delegated credentials from every identity, group, and role IDP resource that the user-principal belongs to. To provide single-sign-on capability, our IDP resources implement the RNS directory interface. For example, given an IDP resource “GrimshawProxy”, one can link other IDP resources such as “FacultyGroup” and “QueueAdministrators” into the “GrimshawProxy” directory. If the “Andrew Grimshaw” identity has been granted execute-access on the IDP resources “QueueAdministrators” and “GrimshawProxy”, a user-principal logging into “GrimshawProxy” will obtain delegated credentials for all three restricted identities.

Access Control

It is important for users who provide Grid resources to be able to specify the security policies that restrict access to their resources as they see fit. In an “administrator-less” grid, each resource provider is responsible for ensuring that their resources are configured to allow only the desired access. This principle of “site autonomy” is fundamental to the Genesis II philosophy.

Each Genesis II Grid resource maintains a set of three access-control lists: a read-access list, a write-access list, and an execute-access list. These lists can be populated with user-principal identities to allow varying degrees of access to different caller-entities bearing different security credentials. For example, one can use the chmod or authz Grid Shell tools to add the “FacultyGroup” IDP resource to a ByteIO resource “Foo”s read-access list. This has the effect of granting read-access of “Foo” to all users carrying the “FacultyGroup” credential. The chmod and authz tools can add Username/Password identities to these access-control lists, as well as identities from X.509 .cer certificate files that may be stored in the local filesystem or in the RNS Grid namespace.

When a user creates a Grid resource (e.g., an exported directory, an IDP resource, a Queue resource, etc.), the new resource’s R/W/X access control lists are initially populated with the identities of the security credentials that the user was in possession of at the time of creation.

As discussed in the previous section, Genesis II supports “group credentials” by allowing individuals to acquire multiple credentials, some of which can be used to logically indicate group roles or privileges. Genesis II also supports another method of identity grouping that exploits the certificate-chain hierarchy conveyed within a user-principal’s digital certificate. For example, one can configure the read-access list for file “Foo” to include the “UVa PKI Standard Assurance” identity (perhaps imported from an X.509 .cer certificate file). This has the effect of granting read-access to all users carrying security credentials whose certificate chains have been signed by “UVa PKI Standard Assurance”.