Design Guide

	Table of Contents 1 Introduction 1.1 Abstract 1.2 Introduction 1.3 Background 1.3.1 caBIG TM and Grid Authentication 1.4 Dorian 1.4.1 Host/Service Credentials 1.5 Architectural Overview 1.5.1 Identity Federation Service (IFS) 1.5.2 Dorian Identity Provider 1.5.3 Dorian Certificate Authority 2 Identity Federation Service 2.1 Trusted Identity Providers 2.1.1 Trusted IdP Operations 2.2 Grid User Management 2.2.1 Grid User Management Operations 2.3 Proxy Creation 2.3.1 Create Proxy Operation 2.4 Managing Administrators 2.4.1 Manage Administrator Operations 2.5 Host Certificates 2.5.1 Host Certificate Operations 2.5.1.1 User Operations 2.5.1.2 Administrative Operations 3 Dorian Identity Provider 3.1 Registration 3.2 Authenticating 3.3 Management 3.3.1 DorianIdP Management Operations 4 SAML Authentication Assertions 4.1 Authentication Statement 4.1.1 Authentication Method 4.1.2 Subject 4.2 Attribute Statement 4.2.1 Local User Id 4.2.2 First Name 4.2.3 Last Name 4.2.4 Email 5 Appendix A References 5.1 Technical Manuals/Articles 5.2 Scientific Publications 5.3 caBIG Material 5.4 caCORE Material 6 Appendix B Dorian Schemas 6.1 Dorian WSDL 6.2 Dorian Common Schema 6.3 Dorian IFS Schema 6.4 Dorian IdP Schema 7 Appendix C Glossary 8 Index List of Figures Figure 1 Dorian Figure 2 Dorian Architecture Figure 3 Managing Trusted IdPs Figure 4 Grid User Search Screen Figure 5 User Management Screen Figure 6 Dorian IdP Registration Figure 7 Dorian IdP - Search for Users Figure 8 Dorian IdP - Editing User Account Figure 9 Authentication Statement Figure 10 Authentication Method Figure 5 Subject Figure 6 Attribute Statement

Introduction

Abstract

Identity management and federation is becoming an ever present problem in large multi-institutional environments. By their nature, Grids span multiple institutional administration boundaries and aim to provide support for the sharing of applications, data, and computational resources in a collaborative environment. One underlying problem is to enable participating institutions to manage the identities of their own members by leveraging existing institutional identity management systems, while at the same time facilitating the participation in larger Grids through the deployment of grid-wide user credentials. Those grid-wide identities are used for features such as single sign-on, secure communication, and are the basis for authorization decisions. In this document we will present the design and implementation of Dorian, a grid service infrastructure component that enables the federation of users across the collaboration.

Introduction

As Grid technologies gain acceptance and adoption, the transition from highly specialized Grids with only a few institutional participants to more general purpose Grids with dozens to hundreds of institutions is becoming a reality. Security is of primary importance in such environments, in particular in settings where sensitive data (e.g., patient medical information) needs to be accessed and exchanged. Mechanisms are needed for such functions as secure communication, authentication, and authorization. This paper is concerned with the management and federation of user identities and authentication in the Grid.

Identity management and federation is becoming a critical problem in enabling access to resources across multiple security domains. In such an environment, it is highly unlikely that participating institutions use the same mechanism for managing the identities of their members. A common application of identity federation in the business domain is to enable single sign-on between two interacting companies that employ different internal authentication mechanisms, and vouch for their access to resources without needing to adopt the same security technologies or maintain a shared, centralized system for managing member identities. The Grid introduces additional challenges since it aims to facilitate the sharing of resources in a collaborative environment that spans multiple institutional boundaries. As a consequence, a Grid environment has to facilitate access by its users to resources at disparate institutions, while enforcing authentication and authorization policies set forth by the different institutions.

When the number of institutions participating in a Grid environment reaches hundreds, the number of individuals wishing to join the Grid can be expected to be well within the neighborhood of thousands or tens of thousands. This creates a huge challenge in terms of managing users, creating and managing their Grid identities, and supporting authentication such that Grid services can be accessed securely. When the number of users is large, it would be neither desirable nor tractable to have a central system to manage the identities for all participants. It is also undesirable to require that each shared service or group of services in the Grid maintains separate identity management and authentication mechanisms. Therefore, a Grid-enabled infrastructure is needed to facilitate the federation of institutional identities. In this document we describe the design and implementation of Dorian, a Grid service infrastructure to address these issues.

Dorian provides a complete Grid-enabled solution, based on public key certificates and SAML, for managing and federating user identities and host/service identities in a Grid environment. Grid technologies have adopted the use of X509 identity certificates to support user authentication. The Security Assertion Markup Language (SAML) has been developed as a standard for exchanging authentication and authorization statements between security domains. Note that Grid certificates and SAML assertions serve different purposes. SAML is mainly used between institutions for securely exchanging authentication information coming from trusted identity providers. The primary use of the certificates is to uniquely identify Grid users, facilitate authentication and authorization across multiple resource providers, and to enable secure delegation of credentials such that a service or a client program can access resources on behalf of the user. A salient feature of Dorian is that it provides a mechanism for the combined use of both SAML [9] and Grid certificates to authenticate users to the Grid environment through their institution's authentication mechanism. Furthermore, Dorian also hides the complexities of creating and managing Grid credentials from the users.

Background

Our work is driven mainly by use cases and requirements gathered from the Cancer Biomedical Informatics Grid (caBIG^TM). The caBIG^TM Security Technology Evaluation White Paper serves as one of the motivating influences for the Dorian work.

caBIG^TM and Grid Authentication

The caBIG^TM program funded by the National Cancer Institute (NCI) was launched to meet the need for a more coordinated approach to informatics resource development, management and dissemination for cancer research. The goal is to speed the delivery of innovative approaches for the prevention and treatment of cancer by facilitating discovery, integration, and analysis of distributed information and sharing of results from multiple institutions.
Given the sensitivity of the medically related data and the number of institutions involved, security has quickly become a high priority issue in caBIG^TM. A key security challenge in caBIG^TM is to be able to implement an effective mechanism of authenticating users to caBIG^TM services, such that access to resources can be restricted to individual users or a group of users. This is a challenging issue because of the scale of caBIG^TM. Although the caBIG^TM effort is a relatively recent, it is expected that the caBIG^TM community will grow to consist of hundreds of organizations and thousands of cancer-research participants from geographically dispersed medical centers, universities, government agencies, and commercial companies.

The Grid software infrastructure of caBIG^TM, called caGrid is based on a service-oriented architecture and provides the implementation of the core services, toolkits and wizards for the development and deployment of community provided services. One of the primary design principles of caGrid is the leveraging of open Grid standards. The caGrid infrastructure is built on top of the Globus Toolkit, the most widely used reference implementation of the grid standards. The Globus Toolkit implements support for security via its Grid Security Infrastructure (GSI). SGSI utilizes X509 Identity Certificates for identifying a user. An X509 Certificate with its corresponding private key forms a unique credential or so-called "grid credential" within the Grid. These grid credentials are used to authenticate both users and services. Although this approach is very effective and secure, it is difficult to manage in a multi-institutional environment. Using the base Globus toolkit, the provisioning of grid credentials is a manual process, which is far too complicated for users. The overall process is further complicated if a user wishes to authenticate from multiple locations, as a copy of their private key and certificate has to be present at every location. Not only is this process complicated, securely distributing private keys is error prone and poses a security risk.

Dorian

One of the challenges in building an identity management and federation infrastructure is to create an architecture that incorporates multiple differing authentication mechanisms used by various institutions. In addressing this challenge we identify two possible approaches. The first is to build an infrastructure that would allow pluggable authentication modules, wherein a module would be developed for each authentication mechanism. In this architecture, a user's authentication information would be routed to the appropriate module that contains the logic for authenticating the user with its institution. Although this approach solves the problem, it requires at least one module be developed for each authentication mechanism. This would require the Grid infrastructure administrators to become intimately familiar with each institution's authentication mechanisms, and would increase the system's complexity with each new module added.

Another approach would be for the infrastructure to accept an institutionally supplied, standard "token" as a method of authentication. In this approach users would first authenticate with their institution's identity management system. Upon successfully authentication the institution's identity management system issues a token which can then be given to the federated grid identity management system in exchange for grid credentials. The benefit of this approach over the first is that it does not require writing a plug-in every time a new institutional authentication mechanism comes online. It does, however, require every institutional authentication system to agree upon and be able to provide a common token. As SAML has been adopted by many institutions, we have chosen that token format as the basis of the second approach for Dorian.
The Security Assertion Markup Language (SAML) is an XML standard for exchanging authentication and authorization data between security domains. Generally the exchange of authentication and authorization data is made between an Identity Provider (IdP) and another party. An institution's authentication system or identity management system is an example of an IdP. Dorian uses SAML authentication assertions as the enabling mechanism for federating users from local institutions to the grid.
Figure 1 illustrates an example usage scenario for Dorian. To obtain grid credentials or a proxy certificate, users authenticate with their institution using the institution's conventional mechanism. Upon successfully authenticating the user, the local institution issues a digitally signed SAML assertion, vouching that the user has authenticated. The user then sends this SAML assertion to Dorian in exchange for grid credentials. Dorian will only issue grid credentials to users that supply a SAML assertion from a Trusted Identity Provider. Dorian's grid service interface provides mechanisms for managing trusted identity providers; this will be discussed in greater detail later in this document. For example, in Figure 1 where a Georgetown user wishes to invoke a grid service that requires grid credentials, they first supply the application with their username and password to the Georgetown IdP as they would normally do. The application client authenticates the Georgetown user with the Georgetown IdP, receives a signed SAML assertion which it subsequently passes to Dorian in exchange for grid credentials. These credentials can then be used to invoke the grid services. This illustrates how Dorian can leverage an institution's existing authentication mechanism and bring its users to the grid.

To facilitate smaller groups or institutions without an existing IdP, Dorian also has its own internal IdP. This allows users to authenticate to Dorian directly, thereby enabling them to access the grid. It provides administrators with facilities for approving and managing users. All of the Dorian IdP's functionality is made available through a grid service interface. Details of the Dorian IdP are provided later in this document. Figure 1 illustrates a scenario of a client using the Dorian IdP to authenticate to the Grid. In this scenario, the unaffiliated User wishes to invoke a grid service. Given that this unaffiliated user has registered and been approved for an account, she is able to authenticate with the Dorian IdP by supplying their username and password. Upon successfully authenticating the user, the Dorian IdP issues a SAML Assertion just like institutional IdPs, which can be presented to Dorian in exchange for grid credentials. The credentials can be used to invoke the grid service.

Figure 1 Dorian

Host/Service Credentials

In order to run secure services securely, the container hosting the services must run with a host credential. A host credential consists of a X.509 certificate and private key. The caGrid CA/Dorian issues host certificates to users who possess a user certificate issued by the caGrid CA. Valid users may request a host certificate from caGrid CA/Dorian. To request a host certificate a user must (1) authenticate with caGrid CA/Dorian using their grid proxy (2) specify a host name for the certificate, and (3) generate a RSA public/private key pair which will make up the host credentials. From the key pair the public key is sent to caGrid CA/Dorian as part of the request, the private key should be securely maintained by the user. All certificate requests require approval of a caGrid CA/Dorian administrator. If a caGrid CA/Dorian administrator approves the certificate request a host certificate will be created and signed with the caGrid CA private key. The host certificate will contain the public key provided by the user and together with the private key securely maintained by the user will make up a host credential. Each host certificate issued by the caGrid CA/Dorian is bound to a user or owner, generally the users that requested it; however an administrator may assign a new owner. If the owner's account is revoked, compromised, or suspended any host certificates bound to them will be suspended as well.

Architectural Overview

The high level architecture is illustrated in Figure 2. Dorian is built on top of the Globus Toolkit and runs as a WSRF [14] compliant grid service. Clients communicate with Dorian though its web service interface. All communication between clients and Dorian is secured via Transport Level Security (TLS) or WS-SecureConversation, depending on the deployment configuration.

The Dorian architecture consists of two core components: the Identity Federation Service (IFS) and the Dorian Identity Provider (IdP). The IFS component handles all the identity federation and management aspects for Dorian including the management of grid user accounts and Trusted IdPs. Dorian's internal IdP component provides the functionality for registering, authenticating, and managing users. Dorian provides a complete client API which provides complete programmatic access to all operations. Dorian also provides a complete graphical user interface.
Figure 2 Dorian Architecture

Identity Federation Service (IFS)

The Identity Federation Service (IFS) component of Dorian facilitates the federation of the local user accounts from multiple institutions to the grid. Architecturally (Figure 2) the IFS consists of five components: the Trusted IdP Manager, the Certificate Authority, the Grid User Manager, the Group Manage, and the Host Certificate Manager. The Trusted IdP Manager component manages the list of Institutional IdPs from which Dorian will accept SAML assertions as a mechanism of authentication. The Certificate Authority component manages and issues user and host/service credentials. The Grid User Manager component manages the account information for each grid user. This information includes the user's identity provider, institutional user id, email address, and the user's account status. The Host Certificate Manager manages host credentials requests and issued host credentials. The Group Manager component manages internal groups for Dorian, an example of one such group is the Dorian administrators group. The Dorian administrators group consists of all the users that may administer Dorian.

The IFS exposes its functionality through Dorian's grid service interface. This functionality can be divided into two sub interfaces, the IFS user interface, and the IFS administrative interface. The IFS user interface allows local users to create grid credentials. The IFS administrative interface provides operations that allow administrators to manage Trusted IdPs and grid user accounts. Note that invoking an administrative operation requires a grid proxy of an administrative user.

Dorian Identity Provider

The Dorian Identity Provider (DorianIdP) gives developers, smaller groups, research labs, unaffiliated users, and other groups that don't have their own IdP, the ability to leverage Dorian. The DorianIdP provides a method for prospective users to register for an account and obtain grid credentials through Dorian. Architecturally (Figure 2) the Dorian IdP consists of three components, the DorianIdP User Manager, the SAML Asserter, and a certificate authority. The Dorian IdP User Manager provisions and manages local Dorian IdP accounts. The SAML Asserter component creates and signs SAML assertions for Dorian IdP users, which will be later consumed by the Dorian IFS in creating grid credentials. The Certificate Authority components is used by the SAML Asserter for signing assertions.

Dorian Certificate Authority

Dorian maintains its own certificate authority, which it uses to issues and manage user credentials, host credentials, and SAML asserting credentials. Depending on your deployment requirements, Dorian can either be configured to use an existing certificate authority or it can generate a new certificate authority. Dorian provides multiple approaches for creating and storing private keys, these approaches include the following:

• DBCA - User and CA private keys are created in memory and stored along with their corresponding certificates in Dorian's MySQL database.
• Eracom - User and CA private keys are generated and stored in a SafeNet Protect Server Gold Hardware Security Module (HSM)
• EracomHybrid - The CA private key is generated and stored in a SafeNet Protect Server Gold HSM. User private keys are generated in memory and wrapped by a 256 bit RSA key stored and maintained in a SafeNet Protect Server Gold HSM. The wrapped user private keys are stored in a database.

Identity Federation Service

The Identity Federation Service (IFS) component of Dorian facilitates the federation of the local user accounts from multiple institutions to the grid. The IFS exposes operations through Dorian's grid service interface for clients to interact with. The operations provide support for provisioning and managing of Trusted Identity Providers as well as support for user account provisioning and management. Invoking administrative operations requires clients to be Dorian IFS administrators, this requires clients to present a grid proxy of an Dorian IFS administrative user.

Trusted Identity Providers

The Institutional Identity Providers (IdPs) that Dorian is configured to trust are referred to as Trusted Identity Providers (Trusted IdPs). Dorian only creates credentials for users whose identity assertions come from a Trusted IdP. The set of Trusted IdPs can be managed by Dorian IFS administrators through its grid service interface. The Dorian grid service interface provides functionality for adding, modifying, and removing Trusted IdPs. The Trusted IdP information consists of the following: IdP Id, IdP Name, IdP Status, User Policy, Certificate, and acceptable authentication methods. The IdP Id is a unique id assigned by Dorian to identify the IdP. The IdP name is assigned by an administrator and provides human readable name to easily identify an IdP. The IdP Status specifies the current status of the IdP: Active or Suspended. Users associated with a "suspended" IdP will be refused access to Dorian. Each Trusted IdP is associated with a set of configurable User Policies that are applied to each user when they authenticate. These policies designate how Dorian should handle users from a specified Trusted IdP. As an example, a policy might dictate what to do when a new user tries to create grid credentials for the first time. An automatic approval policy would automatically register the user with Dorian and create a grid account for the user. A manual approval policy would automatically register the user but not enable the grid account until an administrator manually approves it. User policies can also be used to dictate what to do when a user's grid credentials expire. For example, an automatic renewal policy would enable automatic creation of a new set of credentials using the Dorian certificate authority, where as a manual renewal policy would require and administrator to do so. The User Policy framework is extensible; administrators can implement local policies.
Each Trusted IdP must also specify its own certificate. When Dorian receives a SAML assertion from a Trusted IdP it verifies that the assertion was signed with the private key that corresponds to the Trusted IdP's certificate. Finally, each Trusted IdP must be configured with a list of acceptable authentication methods. A SAML authentication assertion specifies the method in which the Trusted IdP authenticated the user. In order for the SAML assertion to be accepted by Dorian, the authentication method specified in the assertion must be specified as acceptable in the corresponding Trusted IdP.
Figure 3 is a screenshot taken from the Dorian Administrative GUI, illustrating the management of a Trusted Identity Provider.

Figure 3 Managing Trusted IdPs

Trusted IdP Operations

As mentioned earlier the Dorian grid service interface provides several administrative operations for managing Trusted Identity Providers. These operations are defined in the Dorian WSDL specification (Appendix B). The inputs and outputs type of each operation are defined in the Dorian Schemas (Appendix C). In this section we will provide details of the these operations, it is important to note, that only administrative users may invoke these operations.

• getTrustedIdPs() - This operation obtains a list of all the Identity Providers trusted by Dorian.

• Inputs
  • None
• Outputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: TrustedIdP[]

• addTrustedIdp() - This operation allows an administrator to add an Identity Provider to Dorian as a Trusted Identity Provider.

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: TrustedIdP

• Outputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: TrustedIdP

• updateTrustedIdp() - This operation allows an administrator to update a Trusted Identity Provider

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: TrustedIdP

• Outputs
  • None

• removeTrustedIdp() - This operation allows an administrator to remove a Trusted Identity Provider.

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: TrustedIdP

• Outputs
  • None

• getIFSUserPolicies() - This operation obtains a list of user policies that can be associate with a Trusted IdP.

• Inputs
  • None

• Outputs

• Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: IFSUserPolicies

Grid User Management

Dorian provides a mechanism for its administrators to manage individual grid user accounts. When a user first attempts to create a proxy using Dorian, a grid user account is created for them. The account includes user information, user status, and a set of grid credentials including the associated grid identity. The user information includes the user's local user id at their institution, the id of the Trusted IdP the user is associated with, their first name, their last name, and their email address. The user's status corresponds to the user's current status: Active, Suspended, Pending, or Expired. Only users with an "Active" status may access Dorian. A user's grid credentials consist of a certificate and private key that are used by Dorian to issue grid proxy certificates. A user's grid identity is compromised of the Certificate Authority's Subject DN (Distinguished Name), the IdP Id, and the user's id at his institution. When a user's grid account is created the initial status of the account is "Pending". As mentioned earlier, if the TrustedIdP has an Auto Approval User Policy in place, the status will automatically be changed to "Active", giving the user instant access to Dorian. Administrators can update a user's status and can renew a user credentials. Figure 4 and Figure 5 are screenshots taken from the Dorian Administrative GUI, illustrating grid user management.
Figure 4 Grid User Search Screen
Figure 5 User Management Screen

Grid User Management Operations

As mentioned earlier the Dorian grid service interface provides several administrative operations for managing grid users. These operations are defined in the Dorian WSDL specification (Appendix B). The inputs and outputs type of each operation are defined in the Dorian Schemas (Appendix C). In this section we will provide details of the these operations, it is important to note, that only administrative users may invoke these operations.

• findIFSUsers() - This operation allows administrators to search for a list of grid users whom Dorian manages.

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: IFSUserFilter

• Outputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: IFSUser[]

• udpateIFSUser() - This operation allows administrators to update a grid user's account.

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: IFSUser

• Outputs
  • None

• removeIFSUser() - This operation allows administrators to remove a grid user's account.

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: IFSUser

• Outputs
  • None

• renewIFSUserCredentials() - This operation allows administrators to renew a user's grid credentials.

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: IFSUser

• Outputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: IFSUser

Proxy Creation

Users authenticate with grid services using grid proxy certificate. Such a grid "proxy" is a short-term credential (private key and certificate) that is created from a user's long-term grid credentials. Dorian facilitates the creation of grid proxies for its users. To create a grid proxy the user supplies a proxy lifetime and the SAML assertion provided by their identity provider to the Dorian client. The Dorian client generates a new public/private key pair and sends the proxy lifetime, public key, and SAML assertion to the Dorian Grid Service. The Dorian Grid Service validates the SAML assertion and employs the user's previously stored grid credentials to create and sign a proxy certificate for the user-supplied public key. The proxy certificate is then returned to the user. The proxy certificate and locally generated private key can then be used as a grid proxy credential to invoke secure grid services. It is important to note that throughout this process no sensitive information, i.e. private keys, are passed over the network.

Create Proxy Operation

The Dorian grid service interface provides an operation enabling users to create grid proxies. This operations are defined in the Dorian WSDL specification (Appendix B). The inputs and outputs type for the operation are defined in the Dorian Schemas (Appendix C). Below we present the signature for the createProxy operation:

• createProxy()

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-common Name: SAMLAssertion
2. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: PublicKey
3. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: ProxyLifetime

• Outputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-common Name: X509Certificate

Managing Administrators

Only users that have been granted administrative access to Dorian will be able to access the administrative features of Dorian. The administrative features include Account Management, Managing Trusted Identity Providers, and the ability to grant administrative access to users. When Dorian is started for the first time, the dorian user or the default user will have administrative access. The dorian user can be used to assign administrative privileges to other users. It is important to note that being granted administrative access does allow the administration of the Local Dorian Identity Provider. The local Dorian Identity Provider provides a separate mechanism for assigning administrative rights.

Manage Administrator Operations

The Dorian grid service interface provides several administrative operations for managing its administrators. These operations are defined in the Dorian WSDL specification (Appendix B). The inputs and outputs type of each operation are defined in the Dorian Schemas (Appendix C). In this section we will provide details of the these operations, it is important to note, that only administrative users may invoke these operations.

• addAdmin () - This operation allows administrators to add an administrator.

• Inputs

1. Namespace: http://www.w3.org/2001/XMLSchema* *Name: String

• Outputs
  • None

• removeAdmin () - This operation allows administrators to remove an administrator.

• Inputs

1. Namespace: http://www.w3.org/2001/XMLSchema* *Name: String

• Outputs
  • None

• getAdmins () - This operation allows administrators to get a list of Dorian administrators.

• Inputs
  • None

• Outputs

1. Namespace: http://www.w3.org/2001/XMLSchema Name: String[]

Host Certificates

In order to run secure services securely, the container hosting the services must run with a host credential. A host credential consist of a X.509 certificate and private key. Dorian provides a means for users with a grid user account to request a host credential for their services. For each host credential request and each host credential issued Dorian maintains a host credential record. Dorian assigns each host credential record one of the following statuses:

1. *Pending -*Host credentials that have been requested but not yet issued because they require approval of an administrator.
2. *Rejected -*Host credentials that have been requested but were not issued because the request was rejected by and administrator.
3. *Active -*Host credentials that have been issued.
4. *Suspended -*Host credentials that were issued but have been temporarily revoked.
5. *Compromised -*Host credentials that were issued and are permanently revoked.

Host credentials issued by Dorian are bound to a grid user account managed by Dorian, most cases a host credential is bound to the user that requested the credential. This binding make users responsible for any host credentials bound to their account. If a user's account is suspended, any host credentials bound to their account will be revoked an listed in the Dorian CA URL. If a user's account is removed the status of all the host credentials bound to their account will be set to Compromised. Each host certificate record is an assigned an owner, or the user who the credential is bound to.

Host Certificate Operations

The Dorian grid service interface provides several operations for managing host certificates. Some of the operation provided allow user to request and manage host certificates. Other operation are restricted to administrators allowing them to approve, revoke, renew, and manage all host certificates issued by Dorian. These operations are defined in the Dorian WSDL specification (Appendix B). The inputs and outputs type of each operation are defined in the Dorian Schemas (Appendix C). In this section we will provide details of the these operations, below we divide the operations into two categories, "User Operations" and "Administrative Operations". "User Operations" are those operations which can be invoked by user's with a Dorian account. "Administrative Operation" are those operations which can only be invoked by Dorian administrators.

User Operations

• requestHostCertificate() - This operation allows a user to request a host certificate.

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: HostCertificateRequest

• Outputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: HostCertificateRecord

• getOwnedHostCertificates() - This operation allows a user a list of all the host certificates issued to them.

• Inputs
  • None

• Outputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: HostCertificateRecord[]

Administrative Operations

• approveHostCertificate() - This operation allows a Dorian administrator to approve a host certificate request.

• Inputs

1. Namespace: http://www.w3.org/2001/XMLSchema* *Name: Integer

• Outputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: HostCertificateRecord

• findHostCertificates() - This operation allows a Dorian administrator to list requested host certificates and issued host certificates.

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: HostCertificateFilter

• Outputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: HostCertificateRecord[]

• renewHostCertificate() - This operation allows a Dorian administrator to renew a host certificate.

• Inputs

1. Namespace: http://www.w3.org/2001/XMLSchema* *Name: Integer

• Outputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: HostCertificateRecord

• updateHostCertificate() - This operation allows a Dorian administrator to update a host certificate record.

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-ifs Name: HostCertificateUpdate

• Outputs
  • None

Dorian Identity Provider

The Dorian Identity Provider (DorianIdP) gives developers, smaller groups, research labs, unaffiliated users, and other groups that don't have their own IdP, the ability to leverage Dorian. The DorianIdP provides a method for prospective users to register for an account. The DorianIdP can be configured to automatically approve registration requests or can be configured to require an administrative approval. When users register they create a user id and password which they can subsequently use to authenticate with the Dorian IdP. When a user authenticates, the Dorian IdP provides the user with a SAML authentication assertion, which can then be used to authenticate with Dorian's IFS to create grid credentials. The DorianIdP provides mechanisms for administrators to manage users; this includes modifying user information (name, address, email, etc.), changing passwords, granting and revoking access, and other administrative actions. All operations provided by the Dorian IdP are made available through Dorian's grid service interface. Administrative operations require administrators to authenticate with a trusted grid proxy.

Registration

Prospective users can register with the DorianIdP by submitting an application using the registerWithIdP(), Figure 6 illustrates this using screenshot from the Dorian GUI. Registration requires the specification of some contact information as well as username and password. The username and password will be used to authenticate to the DorianIdP. Depending on the Dorian IdP's confiigured policy, registration may require administrative approval. In such a case the user will be informed and will have to wait until their account is approved before they can successfully authenticate. The registerWithIdP(). is defined in the Dorian WSDL specification (Appendix B). The inputs and outputs type for this operation are defined in the Dorian Schemas (Appendix C). Below we present the signature for the registerWithIdP() operation:

• registerWithIdP()
• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-idp* *Name: Application

• Outputs

1. Namespace: http://www.w3.org/2001/XMLSchema* *Name: string

Figure 6 Dorian IdP Registration

Authenticating

The authenticateWithIdP() operation provides a mechanism for users to authenticate with the Dorian IdP. To authenticate with the DorianIdP, the use must be registered. User authenticate with the Dorian IdP using their username and password. Upon successfully authenticating Dorian creates a signed SAML assertion which can later be consumed by the Dorian IFS in exchange for grid credentials. The authenticateWithIdP() is defined in the Dorian WSDL specification (Appendix B). The inputs and outputs type for the operation are defined in the Dorian Schemas (Appendix C). Below we present the signature for the authenticateWithIdP() operation:

• createProxy()

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-idp Name: BasicAuthCredential

• Outputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-common Name: SAMLAssertion

Management

The DorianIdP provides administrators a mechanism of administrating IdP users. Invoking any of the Dorian IdP administrative operations requires a grid proxy of a Dorian IdP administrator Administering Dorian IdP user accounts includes changing of contact info, changing of passwords, and creation and revocation of accounts. Figure 7 and Figure 8 are screenshots from the Dorian Admin GUI, illustrating the management of user accounts within the Dorian IdP.
Figure 7 Dorian IdP - Search for Users
Figure 8 Dorian IdP - Editing User Account

DorianIdP Management Operations

As mentioned earlier the Dorian grid service interface provides several administrative operations for managing Dorian IdP users. These operations are defined in the Dorian WSDL specification (Appendix B). The inputs and outputs type of each operation are defined in the Dorian Schemas (Appendix C). In this section we will provide details of the these operations, it is important to note, that only administrative users may invoke these operations:
findIdPUsers() - This operation allows administrators to search for a list of users whom have accounts with the DorianIdP.

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-idp Name: IdPUserFilter

• Outputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-idp Name: IdPUser[]

• updateIdPUser() - This operation allows administrators update the account information for a Dorian IdP user.

• Inputs

1. Namespace: http://cagrid.nci.nih.gov/1/dorian-idp Name: IdPUser

• Outputs
  • None

• removeIdPUser() - This operation allows administrators remove and IdP User account.

• Inputs

1. Namespace: http://www.w3.org/2001/XMLSchema Name: string

• Outputs
  • None

SAML Authentication Assertions

Dorian uses SAML 1.1 assertions as the enabling mechanism for federating users from local institutions to the grid. Under Dorian users authenticate with their local Institution's IdP. Upon successful authentication, the local Institution IdP will issue and sign a SAML Assertion, which can then be used to authenticate with Dorian and obtain grid credentials.
When Dorian receives a SAML Assertion from a user it verifies that the SAML Assertion was signed by a trusted IdP. In order for the verification process to be successful, it will make sure that the signer of the assertion is a registered Trusted IdP. This is accomplished by ensuring that the SAML Assertion is assigned with the private key that corresponds to the certificate that Dorian has registered with the trusted IdP.

The Dorian SAML Assertion (Error! Reference source not found.) consists of three main parts, the conditions, an authentication statement and an attribute statement. The conditions specify the timeframe that the assertion is valid for. The conditions element specifies a "NotBefore" and "NotOnOrAfter" attributes. The "NotBefore" attribute specifies the date and time for the beginning of the time frame that the assertion for, the "NotOnOrAfter" attribute specifies the ending date and time. Dorian does not place restrictions on Identity Providers as to how long assertions should be valid for however Dorian will only except assertions that fall within the specified time frame. It is recommended that the time frame be minimized (with an acceptable buffer) to the amount of time needed for the user to receive the SAML assertions from the IdP and send it on to Dorian. The Authentication Statement specifies the identity of the user and how they locally authenticated. The Attribute Statement consists of several user attributes describing the user. The attributes are used as information by Dorian administrators in assisting them with user account management.

Authentication Statement

The Authentication Statement (Figure 9) consists of two relevant parts the Authentication Method and the Subject.

<AuthenticationStatement AuthenticationInstant="2006-08-14T13:06:00.401Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
 <Subject>
       <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"  NameQualifier="O=OSU,OU=BMI,OU=caGrid,OU=Dorian,OU=localhost,CN=Dorian IdP Authentication  Asserter">JohnDoe</NameIdentifier>
      <SubjectConfirmation>
        <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</ConfirmationMethod>
      </SubjectConfirmation>
</Subject>
  </AuthenticationStatement>

Figure 9 Authentication Statement

Authentication Method

The AuthenticationMethod, shown in bold text in Figure 9, specifies the method in which the user used to authenticate to the IdP. The following is a list of acceptable authentication methods as define by SAML (see SAML 1.1 specification for more details):

1. urn:oasis:names:tc:SAML:1.0:am:password
2. urn:ietf:rfc:1510
3. urn:ietf:rfc:2945
4. urn:oasis:names:tc:SAML:1.0:am:HardwareToken
5. urn:ietf:rfc:2246
6. urn:oasis:names:tc:SAML:1.0:am:X509-PKI
7. urn:oasis:names:tc:SAML:1.0:am:PGP
8. urn:oasis:names:tc:SAML:1.0:am:SPKI
9. urn:oasis:names:tc:SAML:1.0:am:XKMS
10. urn:ietf:rfc:3075
11. urn:oasis:names:tc:SAML:1.0:am:unspecified

<AuthenticationStatement AuthenticationInstant="2006-05-11T16:21:24.575Z"
    *AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"*>
  <Subject>
<NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"  NameQualifier="O=OSU,OU=BMI,OU=caGrid,OU=Dorian,OU=localhost,CN=Dorian IdP Authentication  Asserter">JohnDoe</NameIdentifier>
      <SubjectConfirmation>
        <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</ConfirmationMethod>
      </SubjectConfirmation>
    </Subject>
  </AuthenticationStatement>

Figure 10 Authentication Method

Subject

Dorian requires the subject element in both the Authentication and Attribute statements. Within the subject element Dorian requires a NameIdentifier and SubjectConfirmation. Dorian does not use the NameIdentifier element, therefore it does not place any restrictions on the format or value of the NameIdentifier element. Dorian does require the NameIdentifier specified in the AuthenticationStatement to "strongly match" the NameIdentifier element specified in the AttributeStatement. The SubjectConfirmation should contain the ConfirmationMethod for a bearer assertion. The subject element for the AuthenticationStatement is illustrated in bold black text in Figure 11.

  <AuthenticationStatement AuthenticationInstant="2006-05-11T16:21:24.575Z"
    AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
     *<Subject>*
       *<NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="O=OSU,OU=BMI,OU=caGrid,OU=Dorian,OU=localhost,CN=Dorian IdP Authentication Asserter">JohnDoe</NameIdentifier>*
      *<SubjectConfirmation>*
        *<ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</ConfirmationMethod>*
      *</SubjectConfirmation>*
    *</Subject>*
  </AuthenticationStatement>

Figure 11 Subject

Attribute Statement

The Attribute Statement (Figure 12) consists of a set of attributes describing the user and a subject identifying the user. The subject is required to strongly match the subject in the Authentication Statement (Section 3.1.2). Dorian requires four attributes: local user id, first name, last name, and email address. In order to facilitate interoperability with many differing IdPs, Dorian is flexible in the attributes it can accept from IdPs. In caBIG Dorian abstractly defines the need for the attribute localUserId, first name, last name, and email address. Dorian requires the localUserId attribute because it requires that IdP have a way of uniquely identifying it users. Dorian does not care of what an IdP calls its localUserId or the format of it. Dorian can be configured to use an individual IdPs representation for a given attribute. For example take the localUserId attribute, which specifies a User's Identity. When registering an IdP we can configure Dorian to look for the attribute that IdP uses for a User's Identity. For example a Shibboleth based IdP would use eduPersonPrincipalName, where as another IdP may use UID. Since Dorian is flexible with regards to attributes, this specification is also flexible and will abstractly define the attributes required. This specification will also specify format constraints on the attribute values where necessary.

Local User Id

This specification requires all Identity Providers to be able to uniquely identify each of its users that it asserts. The Local User Id attribute contains the value of this unique identity. Dorian uses the Local User Id attribute to uniquely Identify a user within an IdP. The Local User Id Attribute is required to be specified every time an assertion is made to Dorian. The value of the Local User Id must always be the same each time an assertion is made an may never change. The format of the local user id attribute, is any string no more than 255 characters. An example of the local user id attribute is highlighted in bold green text in Figure 12.

First Name

This specification requires all Identity Providers to be able to provide the first name of the user that the IdP is asserting. The format of the first name attribute's value, is any string no more than 255 characters. An example of the first name attribute is highlighted in bold black text in Figure 12.

Last Name

This specification requires all Identity Providers to be able to provide the last name of the user that the IdP is asserting. The format of the last name attribute's value, is any string no more than 255 characters. An example of the last name attribute is highlighted in bold blue text in Figure 12.

Email

This specification requires all Identity Providers to be able to provide the email address of the user that the IdP is asserting. The format of the email attribute's value should conform to RFC 2822. The length of the value can be no more than 255 characters. An example of the email attribute is highlighted in bold red text in Figure 12.

<AttributeStatement>
   <Subject>
      <NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="O=OSU,OU=BMI,OU=caGrid,OU=Dorian,OU=localhost,CN=Dorian IdP Authentication Asserter">JohnDoe</NameIdentifier>
      <SubjectConfirmation>
        <ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</ConfirmationMethod>
      </SubjectConfirmation>
    </Subject>
<Attribute AttributeName="localUserId"    AttributeNamespace="http://cabig.nci.nih.org/dorian">
<AttributeValue>jdoe</AttributeValue>
</Attribute>
<Attribute AttributeName="urn:mace:dir:attribute-def:givenName"    AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
<AttributeValue>John</AttributeValue>
</Attribute>
<Attribute AttributeName="urn:mace:dir:attribute-def:sn " AttributeNamespace=" urn:mace:shibboleth:1.0:attributeNamespace:uri ">
<AttributeValue>Doe</AttributeValue>
</Attribute>
<Attribute AttributeName="urn:mace:dir:attribute-def:mail" AttributeNamespace=" urn:mace:shibboleth:1.0:attributeNamespace:uri ">
<AttributeValue>jdoe@osu.edu</AttributeValue>
</Attribute>
</AttributeStatement>

Figure 12 Attribute Statement

Appendix A References

Technical Manuals/Articles

1. I. Foster, C. Kesselman, S. Tuecke., "The Anatomy of the Grid: Enabling Scalable Virtual Organizations", International J. Supercomputer Applications, 15(3), 2001.
2. I. Foster, C. Kesselman, J. Nick, S. Tuecke, "The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration", 2002.
3. The Globus Toolkit, http://www.globus.org
4. V. Welch, F. Siebenlist, I. Foster, J. Bresnahan, K. Czajkowski, J. Gawor, C. Kesselman, S. Meder, L. Pearlman, S. Tuecke, "Security for Grid Services", Twelfth International Symposium on High Performance Distributed Computing (HPDC-12), IEEE Press, to appear June 2003.
5. I. Foster, C. Kesselman, S. Tuecke, J. Volmer, V. Welch, R. Butler, D. Engert, "A National-Scale Authentication Infrastructure.", IEEE Computer, 33(12):60-66, 2000.
6. S. Langella, S. Oster, S. Hastings, T. Kurc, J. Saltz, "caGrid 0.5 Security Infrastructure". July 2005.
7. OASIS Security Services (SAML) TC, http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=security
8. Ken Lin, Gary Daemer, "caBIG™ Security Technology Evaluation White Paper". January 2006.
9. Web Services Resource Framework (WSRF), http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf
10. S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson, Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile

Scientific Publications

caBIG Material

1. Cancer Biomedical Informatics Grid (caBIG^TM), https://cabig.nci.nih.gov.
2. Cancer Biomedical Informatics Grid (caBIG^TM), https://cabig.nci.nih.gov/workspaces/Architecture/caGrid/

caCORE Material

1. caCORE: http://ncicb.nci.nih.gov/core
2. caBIO: http://ncicb.nci.nih.gov/core/caBIO
3. caDSR: http://ncicb.nci.nih.gov/core/caDSR
4. EVS: http://ncicb.nci.nih.gov/core/EVS
5. CSM: http://ncicb.nci.nih.gov/core/CSM

Appendix B Dorian Schemas

The various Dorian schemas are located in the Dorian project under the schema/Dorian directory. They can also be located in the subversion repository at https://ncisvn.nci.nih.gov/svn/cagrid/branches/caGrid-1_4_release/Software/core/caGrid/projects/dorian/schema/Dorian

Dorian WSDL

The 1.4 Dorian WSDL can be obtained from: https://ncisvn.nci.nih.gov/svn/cagrid/branches/caGrid-1_4_release/Software/core/caGrid/projects/dorian/schema/Dorian/Dorian.wsdl

Dorian Common Schema

The Dorian Common Schema defines types used by both the Dorian IdP and Dorian IFS.

The 1.4 Dorian Common Schema can be obtained from: https://ncisvn.nci.nih.gov/svn/cagrid/branches/caGrid-1_4_release/Software/core/caGrid/projects/dorian/schema/Dorian/dorian-common.xsd

Dorian IFS Schema

The 1.4 Dorian IFS Schema can be obtained from: https://ncisvn.nci.nih.gov/svn/cagrid/branches/caGrid-1_4_release/Software/core/caGrid/projects/dorian/schema/Dorian/dorian-ifs.xsd

Dorian IdP Schema

The 1.4 Dorian IdP Schema can be obtained from: https://ncisvn.nci.nih.gov/svn/cagrid/branches/caGrid-1_4_release/Software/core/caGrid/projects/dorian/schema/Dorian/dorian-idp.xsd

Appendix C Glossary

Following is an example list of terms and their definitions.

Term	Definition
{jboss-home}	The base directory where JBoss is installed on the server
API	Application Programming Interface
caArray	cancer Array Informatics
caBIG	cancer Biomedical Informatics Grid
caBIO	Cancer Bioinformatics Infrastructure Objects
caCORE	cancer Common Ontologic Representation Environment
caDSR	Cancer Data Standards Repository
caMOD	Cancer Models Database
cardinality	Cardinality describes the minimum and maximum number of associated objects within a set
CDE	Common Data Element
CGAP	Cancer Genome Anatomy Project
CMAP	Cancer Molecular Analysis Project
CN	Common Name
CS	Classification Scheme
CSI	Classification Scheme Item
CSM	Common Security Module
CTEP	Cancer Therapy Evaluation Program
CUI	Concept Unique Identifier
CVS	Concurrent Versions System
DAML	DARPA Agent Markup Language
DAO	Data Access Objects
DARPA	Defense Advanced Research Projects Agency
DAS	Distributed Annotation System
DL	Description Logic
EA	Enterprise Architect
EBI	European Bioinformatics Institute
EVS	Enterprise Vocabulary Services
GAI	CGAP Genetic Annotation Initiative
GEDP	Gene Expression Data Portal
HIPPA	Health Insurance Portability and Accountability Act
HLGT	High Level Group Term
HLT	High Level Term
HTTP	Hypertext Transfer Protocol
ISO	International Organization for Standardization
JAAS	Java Authentication and Authorization Service
JAR	Java Archive
Javadoc	Tool for generating API documentation in HTML format from doc comments in source code (http://java.sun.com/j2se/javadoc/)
JDBC	Java Database Connectivity
JET	Java Emitter Templates
JMI	Java Metadata Interface
JSP	JavaServer Pages
JUnit	A simple framework to write repeatable tests (http://junit.sourceforge.net/)
LDAP	Lightweight Directory Access Protocol
LLT	Lowest Level Term
LOINC	Logical Observation Identifier Names and Codes
MAGE	MicroArray and Gene Expression
MAGE-OM	MicroArray Gene Expression - Object Model
MedDRA	Medical Dictionary for Regulatory Activities
metadata	Definitional data that provides information about or documentation of other data.
MGED	Microarray Gene Expression Data
MMHCC	Mouse Models of Human Cancers Consortium
MO	MGED Ontology
multiplicity	Multiplicity of an association end indicates the number of objects of the class on that end may be associated with a single object of the class on the other end
NCI	National Cancer Institute
NCICB	National Cancer Institute Center for Bioinformatics
OIL	Ontology Inference Layer
OilEd	Ontology editor allowing you to build ontologies using DAML+OIL
OLLT	Obsolete Lower Level Terms
OMG	Object Management Group
ORM	Object Relational Mapping
PT	Preferred Term
RDBMS	Relational Database Management System
SDK	Software Development Kit
Semantic connector	A development kit to link model elements to NCICB EVS concepts.
SOC	System Organ Class
SPORE	Specialized Programs of Research
SQL	Structured Query Language
SSC	Special Search Categories
UI	User Interface
UID	User Identification
UML	Unified Modeling Language
UMLS	Unified Medical Language System
UPT	User Provisioning Tool
URL	Uniform Resource Locators
VD	Value Domain
WAR	Web Application Archive
WSDL	Web Services Description Language
XMI	XML Metadata Interchange (http://www.omg.org/technology/documents/formal/xmi.htm) - The main purpose of XMI is to enable easy interchange of metadata between modeling tools (based on the OMG-UML) and metadata repositories (OMG-MOF) in distributed heterogeneous environments
XML	Extensible Markup Language (http://www.w3.org/TR/REC-xml/) - XML is a subset of Standard Generalized Markup Language (SGML). Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML

Index

It is very easy to generate an index and extremely helpful to the manual user. See the Technical Style Guide located at: [https://cabig.nci.nih.gov/working_groups/Training_SLWG/Documents/Technical_Pubs_Style_Guide_021405_jbh.pdf|https://cabig.nci.nih.gov/working_groups/Training_SLWG/Documents/Technical_Pubs_Style_Guide_021405_jbh.pdf] for directions for inserting index markers and generating an index in MS Word (PC).

Glossary, 67
References
caCORE material, 37