review report v1.0 - Amazon S3 · Review Report - Grid Authentication and Authorization Technologies 3 State of the Art Review on Grid Authentication and Authorization Technologies

Review Report - Grid Authentication and Authorization Technologies

1

Review Report

Grid Authentication and Authorization Technologies

Wei Jie

Feb 2008


2

Content

Part I

1 Introduction....................................................................................................... 3

2 Grid Authentication Technologies and Infrastructures................................... 4

2.1.1 Public Key Infrastructure (PKI).......................................................... 4

2.1.2 Kerberos ............................................................................................ 6

2.1.3 Athens................................................................................................ 7

2.2 Comparison of Grid Authentication Technologies and Infrastructures......... 8

3 Grid Authorization Technologies and Infrastructures .................................... 9

3.1 Authorization Interface ............................................................................... 9

3.2 Typical Grid Authorization Technologies and Infrastructures.................... 10

3.2.1 Grid-map file.................................................................................... 10

3.2.2 CAS ................................................................................................. 11

3.2.3 VOMS ............................................................................................. 13

3.2.4 PERMIS........................................................................................... 14

3.2.5 Akenti .............................................................................................. 16

3.3 Comparison of Grid Authorization Technologies and Infrastructures ........ 17

4 Shibboleth Authentication and Authorization Technology ............................19

4.1 Introduction to Shibboleth......................................................................... 19

4.2 Shibboleth Architecture and Protocol........................................................ 19

4.3 Features, Advantages and Limitations of Shibboleth ................................. 20

4.4 Shibboleth Related Projects....................................................................... 21

5 Conclusions .......................................................................................................23

Part II

1 Introduction......................................................................................................27

2 Use Case ............................................................................................................27

3 Security Requirements .....................................................................................28

3.1 Authentication Issue.................................................................................. 28

3.1.1 Establish Shibboleth federation for e-social science community ....... 29

3.1.2 Integrate Shibboleth with the Sakai portal ........................................ 30

3.2 Authorization Issues.................................................................................. 30


3

State of the Art Review on

Grid Authentication and Authorization Technologies

Abstract

Grid computing facilitates resource sharing in distributed Virtual Organizations. The multi-

institutional nature of a Grid environment introduces challenging security issues, especially,

authentication and authorization. This report presents a state of art review of major Grid

authentication and authorization technologies. In particular, Shibboleth, a promising

technology for authentication and authorization to support inter-institutional sharing of

remote resources subjected to access control, is discussed in terms of its architecture, features,

advantages, limitations, and projects and applications in a Grid environment. The evidence

suggests that Shibboleth is the best available security scheme for a Grid environment.

1 Introduction

Advances in technology have always affected the way research is conducted regardless of the

research domain. The case of Grid computing is no different in that it has drastically changed

research methods by providing high performance computing infrastructure which can provide

high capacity storage solutions, support for computationally intensive jobs and also facilitate

jobs involving exotic resources. Grid computing, however, is challenged by complex

problems with security being one of the most important due to the value of the resources

involved in such an arrangement [1, 2]. A Grid provides a flexible and decentralized access to

distributed resources to achieve quality of service. It allows resources or services (both terms

are interchangeably used in this report) to be shared between members of a Virtual

Organisation (VO) [3]. It is this sharing of hardware and software resources which is the

source of the VO’s value to its participants. Furthermore, the resource or service provider

should be able to explicitly define what is shared, to whom it is shared and for what time

period it will be shared. This type of environment should overcome some potentially

cumbersome relationships between VO participants, which makes the security problem more

complex and non-trivial. An example of this could be the problem of establishing trust in

remote resources that are controlled by different authorities. In this context, the importance of

basic security concepts, i.e., Authentication, the assurance that an entity (e.g., a user) is

indeed who they claim to be, and Authorization, determining the level of access to an

authenticated entity, becomes even more exacerbated and therefore need to be addressed

explicitly.

The e-Infrastructure for social science project aims to build a Grid infrastructure to provide

integrated access to a variety of resources (including datasets, tools and services) for social

science research through an easy-to-use user environment. This e-infrastructure is achieved

through a joint programme of activities including Grid-enabled datasets, metadata and service

registration, workflow tools, simulation tools, portal architecture and support service, etc. The

security activity in the e-infrastructure project runs as a horizontal integration activity related

to all the research activities, providing a security infrastructure thus making the users access

the e-infrastructure in a secured manner.

In this review, we discuss the authentication and authorization technologies available for use

in Grid environments and compare them so as to evaluate the most appropriate mechanism to

solve the security problem for Grids. We also describe the Shibboleth security system which

promotes the concept of federation, a collection of institutions which trust each other to

authenticate their users properly, and therefore, extends the local authentication and


4

authorization mechanisms and thereby allowing the participants of a federation to trust each

other’s local security procedures. A user can use the same local login information to access

remote resources, thus facilitating the authentication and authorization across organizational

boundaries. The rest of the report is organized as follows: Section 2 reviews Grid

authentication technologies and infrastructures. Section 3 reviews Grid authorization

technologies and infrastructures. Section 4 discusses the Shibboleth authentication and

authorization infrastructure. Finally, Section 5 concludes the report with a discussion of

towards Shibboleth security in a Grid environment.

2 Grid Authentication Technologies and Infrastructures

There have been continuous efforts in the development of authentication infrastructures in a

Grid environment and as with any other developing technology, most of these use already

established security techniques such as PKI, Kerberos, etc as the underlying authentication

mechanisms. In this section, we will describe the major authentication technologies that can

be used in a Grid environment followed by a comparison of these technologies based on

authentication criteria we will define.

2.1 Typical Grid Authentication Technologies and Infrastructures

The authentication technologies we discuss here include Public Key Infrastructure (PKI),

Kerberos and Athens.

2.1.1 Public Key Infrastructure (PKI)

One of the technologies playing a prominent role in Grid authentication is Public Key

Infrastructure (PKI) [4, 5], derived from the concept of Public Key Cryptography which is the

underlying technology for PKI. It provides binding between public keys and entities, enables

other entities to verify these bindings and also provides key management services in a

distributed framework. Typically a PKI arrangement will enable users of a distributed system

to be authenticated with each other and ensure secure communication using encryption and

decryption techniques. A typical PKI would have some fundamental components: a

Certification Authority (CA) is the basic building block. It is like a notary to confirm the

identities of the entities involved in a communication; similarly, a Registration Authority

(RA) is an entity trusted by the CA to register the identity of users to a CA.

In a typical PKI, whenever two entities, for example, Alice and Bob from organizations A and

B respectively, want to communicate, such as, to carry out a business transaction, each of

them generates two public-private key pairs, one for signature and the other for encryption.

Then they contact their organization’s RA with their signature public key and a photo-id for

verification. After verification, the RA vouches for the identity of, for example, Alice to the

CA associated with that organization which issues a public key certificate which normally

contains the public key for the requesting entity, information about the entity having the

private key for this public key, the operational period for the certificate and also CA’s own

digital certificate. Typically, Alice first computes a hash of the data that she intends to send to

Bob using a strong hash algorithm such as SHA1 [6]. This is to ensure the integrity property

as a strong hash algorithm guarantees that a hash computed for two different messages can

never be the same, also known as the strong collision resistance property. Alice then signs the

hash concatenated with the original data with her signing private key. She then generates a

secret key e.g. an AES [7] key and encrypts the message. She then uses Bob’s public key,

after verifying it from Bob’s CA, to encrypt the secret key and then sends the signed and

encrypted message with the encrypted AES key to Bob as illustrated in Figure 1 [5]. Bob first

uses his private key to retrieve the AES key and then uses this key to decrypt the message.

Now Bob can read the message but not before he confirms Alice’s identity from Alice’s CA.


5

After verifying that the certificate of Alice is genuine and valid, Bob can verify the digital

signature on the message. If the signature validates, Bob knows that the message has came

from Alice but to ensure integrity, Bob uses the same hash algorithm on the data and

compares the resulting hash with the one sent by Alice. Due to the strong collision resistance

property of the hash functions, if the two hashes match it guarantees that the message has not

been tampered with since it was created by Alice. This process as illustrated in Figure 2 [5],

thereby guarantees integrity, confidentiality and authentication.

Figure 1. Alice using the digital signature to send data to Bob

Figure 2. Decryption of data and hash comparison by Bob

The most popular PKI is defined by the IETF’s PKIX working group, which defines a

security system used for identifying entities through the use of X.509 identity certificates [8].

In this PKI, a highly trusted CA issues X.509 certificates where essentially a unique identity

name and the public key of an entity are bound through the digital signature of that CA.

In a Grid environment, the Grid Security Infrastructure (GSI) [9] in the Globus Toolkit [10] is

a typical example of PKI based authentication. The GSI is a security framework in which

authentication is performed using PKI based X.509 identity certificates. A certificate asserts a

user’s identity which is expressed as a unique Distinguished Name (DN). A X.509 certificate,


6

in conjunction with an associated private key, forms a unique credential set that a Grid entity

uses to authenticate itself to other Grid entities like service providers. The GSI also allows for

the creation of delegated privileges by issuing proxy certificates [11] and brings added

benefits of Single Sign-On (SSO) over distinct domains.

Whilst the PKI addresses user authentication issues, it has certain limitations as follows:

• It can be a demanding work to obtain X.509 certificates from a trusted Certification

Authority, especially for inexperienced users, as this requires them to follow a tedious

process for obtaining the certificates and converting them into appropriate formats before

they are then able to access the Grid resources.

• PKI also raises the issues of scalability and flexibility with the growth of Grid VOs, as

this technology is unable to deal with dynamically changing users, along with

management of users’ rights and permissions.

• PKI also brings privacy concerns due to the release of personal information for user

authorization decisions.

2.1.2 Kerberos

The basic Kerberos authentication process, as described in [12] and shown in Figure 3,

proceeds as follows: a client sends a request to the AS (Authentication Server) for credentials

for a given server. The AS responds with these credentials, a ticket for the server and a

session key, encrypted in the client’s key. The client transmits the ticket, which contains the

client’s identity and a copy of the session key, all encrypted in the server’s key to the server.

The session key is used to authenticate the client and may optionally be used to authenticate

the server. This session key exists for the time period of the communication between the

client and the application server and can be used to support secure communication between

the two using this key for encryption and decryption purposes. This, however, is an optional

feature and is not much used in practiced as Kerberos is mostly used for initiation of a

network connection.

Figure 3. Basic Operation of Kerberos

With the basic form of Kerberos, we assume all the components of the Kerberos setup are in

the same organizational or administrative domain. In a distributed environment like Grid, it is

often the case that a user is using services offered by an administrative domain different from

its parent domain. In such cases the user needs to be authenticated by the application server

present in the remote domain or organization. To facilitate this, Kerberos provides cross-

Client

Authentication

Server

Ticket Generating

Server

Application

Server

AS_REQ

AS_REP

TGS_REQ

TGS_REP

AP_REQ

AP_REP


7

realm operation. A client in one organization can be authenticated to a server in another. Each

organization that decides to run a Kerberos server establishes its own realm. In order to

represent the origin of a client, the client’s name includes its own name along with the name

of the realm in which it is registered so that the end service can decide whether to honor a

request. The cross-realm authentication is facilitated by providing inter-realm keys, shared

between the administrators of the two realms. After these keys are exchanged, the Ticket

Granting Service (TGS) of each side can then verify and hence trust any ticket generated by

the remote TGS. A client is then able to obtain a Ticket Granting Ticket (TGT) for the remote

realm’s ticket-granting service from its local realm. When that TGT is used, the remote ticket-

granting service uses the inter-realm key to decrypt the TGT which verifies that the ticket was

issued by the client’s own TGS. Tickets issued by the remote ticket-granting service will

indicate to the end-service that the client was authenticated from another realm.

Kerberos technology presents some limitations as well. Kerberos is only meant to provide

authentication services on a network by using authentication servers and ticket generating

servers. Kerberos does not, by itself, provide authorization and in order to achieve the

required level of security, we must deploy authorization mechanisms that can work in

conjunction with Kerberos authentication mechanism. In addition, Kerberos requires a client

to go through an initial phase of generating credentials for each service that it is willing to use.

This process becomes more time and bandwidth consuming when used for a Grid

environment. Also a particular client in a Grid environment may communicate with a very

large number of service providers which makes things even worse.

2.1.3 Athens

The Athens Access Management System [13] is an advanced authentication infrastructure that

has been developed for UK higher education to control access to a wide range of digital

resources using a secure Single Sign-On process. Athens credentials are recognized by

premium web content providers, which makes it a good choice and also facilitates an

organization to allow a single username to access all the subscribed Athens protected

resources. This is a strong step forward from the traditional IP based access which restricted

the access from within the organization’s network.

Figure 4. Architecture of the Athens Access Management System

The Athens Access Management System comprises a couple of major components as

illustrated in Figure 4 [14]. The majority of these components are operated by Athens, while

DSP

Resource 1

DSP

Resource 2

DSP

Server

Software

Athens

Agent

Network

Athens

Accounts Server

DSP

Resource 1

DSP

Server

Software

Athens

Agent

Athens service Athens

Statistics Server


8

the Athens Agents must be operated by each participating DSP (Data Service Provider).

When a user tries to access a resource on the DSP site that is protected by Athens, the DSP

directs the user to the Athens Authentication Point (AAP) maintained by Athens. The AAP

provides a central login form for the user to input his/her Athens credentials. The user enters

username and password at the AAP, and is sent back to the DSP. Then the DSP decides if the

user has the correct permissions to access their site, using the Athens Agent Software to

communicate with the central Athens servers..

Although Athens has been established as a successful authentication infrastructure for UK

education sector, there are several reasons to move Athens to more advanced infrastructure

(e.g., Shibboleth which will be discussed later):

• Currently, service providers have to implement Athens on their systems to make their

services available to the UK community. The classic Athens system uses a separate

identifier and password for remote services. These may be difficult to remember

alongside other, locally-used, usernames and passwords. Whereas more advanced

infrastructures like Shibboleth relies on locally-used identity credentials, which are much

more likely to be remembered and kept confidential.

• Athens claims to provide Single Sign-On but it does not exhibit true Single Sign-On

capability as it only facilitates the use of single user name for multiple Athens protected

resources and the user has to sign-on every time he/she visits a different resource thereby

violating the Single Sign-On concept.

• Another limitation of Athens is the level of granularity in implementing access control

mechanisms. Once authenticated, Athens uses the identity of the organization to which

the user is affiliated and also the subscriptions made by the user. This provides a coarse

grained access control approach as opposed to the fine grained approach provided by

more advanced infrastructures like Shibboleth.

• Finally, there are increasing demands for more sophisticated security systems for enabling

access to resources driven by domains such as e-learning, regional collaborations, and

multi-institutional projects. More advanced infrastructures like Shibboleth provides a

good basis to meet these demands.

2.2 Comparison of Grid Authentication Technologies and Infrastructures

In last section, typical Grid authentication technologies and infrastructures have been

reviewed. We now present a brief comparison of these technologies. We base this comparison

on the requirements essential in a Grid environment, i.e., authentication mechanism, single

sign-on, delegation and authorization level as defined as follows (see Table 1).

• Authentication mechanism – the core concept/method used by an authentication system,

for example, digital certificate, ticket, username, etc.

• Single Sign-On: some authentication systems support Single Sign-on, enabling a user to

be authenticated once and gain access to multiple resources.

• Authentication delegation – a user may give authentication systems the permission to use

his/her credentials to access other resources on his/her behalf, that is, authentication

delegation.

• Authentication usability – usability in the context of authentication means how easy a

user interfaces with authentication systems.


9

• Authorization level – authentication systems may provide information for authorization

systems to make authorization decisions and thereby impact granularity of authorization.

PKI Kerberos Athens

Authentication

Mechanism

Digital

Certificates/Signatures

Tickets Usernames

Single Sign-On Proxy certificates Not provided Partial through

usernames

Authentication

Delegation

Through proxy

certificates

Cross-realm operation Not provided

Authentication

Usability

Cumbersome Process

of acquiring the

certificate

User friendly as the

process of ticket

generation is hidden

from user

User friendly process

of getting Athens

username

Authorization

Level

Coarse grained No authorization

mechanism provided

Coarse grained

Table 1. Comparison of Grid Authentication Technologies and Infrastructures

3 Grid Authorization Technologies and Infrastructures

Grid computing allows resources to be shared between members of VOs. However, resource

sharing necessitates authorization mechanisms which determine who is authorized to access

these resources in which ways, and who is not. Authorization is usually under control of the

resource provider and is thus an action performed by the resource provider. In this section, we

will first introduce the ISO generic authorization framework and the authorization interface

proposed by GGF (Global Grid Forum, now Open Grid Forum or OGF) [15]. Then major

authorization technologies and infrastructures for a Grid environment will be discussed.

Finally, these authorization technologies and infrastructures are compared and how

authorization technologies will evolve will be discussed.

3.1 Authorization Interface

The ISO Access Control Framework standard [16] defines a generic framework of

authorization (see Figure 5). In this model, the initiator attempts to access a target in a remote

domain. There are two key components to support authorized access to the target: a Policy

Enforcement Point (PEP), described in Figure 5 as the Access control Enforcement Point

(AEF), and a Policy Decision Point (PDP), described in Figure 5 as the Access control

Decision Function (ADF). The core idea of the authorization framework is that the PEP

ensures that all requests to access the target go through the PDP and the PDP makes the

authorization decision based on a set of rules or policies.

In accordance with the generic framework of authorization, the SAML (Security Assertion

Markup Language) specification [17] issued by OASIS [18] has provided a Web service

interface that could be used to connect a PDP to a Grid based PEP such as Globus Toolkit.

SAML is a general purpose language that allows different types of security assertions about

principals to be passed between clients and servers, in the format of XML messages. Three

standard types of assertions about principals were specified in SAML: authentication

assertions, attribute assertions and authorization decision assertions. It is authorization

assertions that are passed between the PDP and PEP. The OASIS SAML AuthZ specification

defines a message exchange between a PEP and PDP consisting of an


10

AuthorizationDecisionQuery going from PEP to PDP, and an assertion returned contain a

number of AuthorizationDecisionStatements. Figure 6 shows the interactions supported by

this API [19]. Using this API, a generic policy enforcement engine can be constructed that

can be used by arbitrary Grid services.

Figure 5. Generic Access Control Framework

Figure 6. GGF SAML AuthZ API

3.2 Typical Grid Authorization Technologies and Infrastructures

There are a few existing Grid authorization technologies and infrastructures. In this section

we will discuss typical ones including Grid Map-file, CAS, VOMS, PERMIS and Akenti.

3.2.1 Grid-map file

The GSI of the Globus Toolkit is one of the earliest efforts aiming to realize authorization in

Grid VOs in the form of the Grid-map file. The central idea behind the Grid-map file is the

Access Control Lists (ACLs) mechanism. This file simply stores a list of the authenticated

distinguished names of the Grid users and the equivalent local user account names that they

are to be mapped into. Access control to a resource is then left up to the local operating

system and application access control mechanisms. However, this authorization mechanism

does not allow local resource administrators to set a policy for access control, which results in

very limited authorization functionality. In addition, the Grid-map file mechanism is not

scalable and flexible in terms of describing Grid users’ rights and privileges in the scenarios

Policy

Decision

Point

Grid

Client

Container

Service

s

Signed

ACs

2. SAML-

AuthorizationQueryDecision

3. SAML-

AuthorizationQueryDecision

1. Service Request

4. Response/results

AEF Target

ADF

Initiator

Submit

Access

Request

Present

Access

Request

Decision Decision

Request

User

Domain

Target

Domain


11

of large-scale VOs, and consequently, the local resource administrators’ workload cannot be

minimized or distributed throughout the VO [20].

OGSA-DAI (Open Grid Services Architecture – Data Access and Integration) [21] is another

typical system that uses similar authorization mechanism. OGSA-DAI support access control

via ACL held in a role-map file that maps individual Grid users to local database usernames

and password (see Figure 7). It indicates that each resource provider has to maintain a role-

map file to authorize access to its resources. Similar to the Grid-map file, this role-map file

access control method is not suitable for large-scale VOs in terms of scalability and flexibility,

because both users and resources are dynamic in VOs. Multiple entries in multiple role-map

files may need to be updated if new users are allowed to access multiple data resources or if

the access privileges of current users change. This puts an unnecessary burden on resource

providers in managing the role-map files, especially when both the users and resource

providers belong to multiple VOs. Furthermore, there are overheads whenever users make

invalid requests, because users are authenticated, mapped and connected without first

verifying their requests against their access privileges [22].

Figure 7. Authorization Model in OGSA-DAI

3.2.2 CAS

The Community Authorization Service (CAS) [23] was the next attempt by the Globus team

to improve upon the manageability of user authorization. The main idea of CAS is that a

resource owner delegates the allocation of authorization rights to the community

administrator and lets the community administrator determine who can use this allocation.

This is achieved by having a CAS server, which acts as a trusted intermediary between VO

users and resources. In particular, the CAS server will decide whether a user has sufficient

privileges and give the user the right to perform the requested actions depending on user’s

role in the community, i.e., role based access control (RBAC).

Figure 8 illustrates the authorization model in CAS. A CAS server keeps track of its

membership information in a particular community. It also contains the access control policy

statements which define “who is allowed what type of access on which resources”. The CAS

introduces the concept of rights in the form of ‘capability’ which a user can use as a proof of

RoleMapper

OGSA-DAI

Services

Admin

Oracle MySQL Postgres

…

Users


12

allowance to use a particular resource (the CAS server has a backend database to store users’

capabilities). In order to access a CAS-managed resource, a user has to first request a

capability to use that resource. The CAS server then responds with an appropriate capability

(the intersection of the set of rights granted to the community by the resource provider and the

set of rights defied by the capabilities granted to the user by the community). Following this,

user can present the capability to the resource provider responsible for that resource. The

resource provider verifies the rights for both the community and the capability to grant access

to the user to the resource.

Figure 8. Authorization Model in CAS

For finer grained access control, the local resource owner can additionally apply its own local

policy to determine the amount of access granted, and still maintain the ultimate authority

over their resources. This substantially reduces the work of the resource administrator.

Further, determining who should be granted capabilities by the CAS server is the task of other

managers in the VO community, so this again relieves the burden of resource managers.

The CAS architecture builds on the authentication and delegation mechanism provided by the

Globus Toolkit’s GSI. If a user of a community needs to gain access to a resource, the user

generates a proxy credential signed by his/her won user credential. The proxy credential is

presented to the CAS sever, which returns a new credential, known as CAS proxy credential.

This credential contains the CAS policy assertions to represent the user’s capabilities and

restrictions as an extension. SAML authorization decision statements are used to express the

CAS policy assertions. The CAS proxy credential is presented to the resource provider. The

resource provider then verifies the validity of the proxy credential and parses the CAS policy

assertions to obtain the restrictions imposed by the CAS server. Thus, the CAS credential

facilitates the mapping of the user to a local account, and the restrictions determine the

operations the user is allowed to perform.

CAS provides scalability in terms of the number of users and VOs. Each user needs to be

known and trusted by the CAS server, but not by each provider. Similarly, each resource

provider needs to be known and trusted by the CAS server, but not by each user. However, in

terms of the actual number of access requests on resources, using a single CAS server may

not be very scalable. A single CAS server can be a bottleneck if a large number of users

attempt to access it at the same time, and it can be a single point of failure. In addition, VO

What rights does

the community

grant to this user?

CAS Server

User

Is the request authorized

for the community?

Does the capability

authorize this request?

Resource Server

User

CAS maintained

community policy

database

Capability

Capability

Local policy

information

CAS reply

with Resource

request with

CAS request

authenticated

with user

credentials


13

administrator needs to maintain all users’ capabilities, and the authorization management load

may consequently be heavy.

3.2.3 VOMS

The EU DataGrid and DataTAG projects developed the Virtual Organisation Membership

Service (VOMS) [24] as a way of delegating the authorization of users to an administrator in

the VO. A VO administrator maintains a centralized database containing all the information

about users of the VO and gives users appropriate attributes needed to access resources across

the VO. The VOMS System is composed of the following components:

• User Server: receives requests from a client and returns information about the user.

• User Client: contacts the server presenting a user’s certificate and obtains a list of groups,

roles and capabilities of the user.

• Administration Client: used by the VO administrators (adding users, creating new groups,

changing roles, etc...)

• Administration Server: accepts the requests from the clients and updates the Database.

The basis of authentication and authorization in a VOMS system is an Attribute Certificate

also known as a Pseudo-Certificate. This is similar to a proxy certificate used in Globus

Toolkit’s GSI but is different in that it also contains the authorization information obtained

from the VOMS server, e.g., the role the user is entitled to or the group that s/he belongs to,

etc. This certificate is signed by the VOMS server so as to ensure the integrity of its contents.

The operation of VOMS system defines two different operations for user and administrator

[25]. The user operation deals with the process of acquiring the proxy certificate which will

be then validated by the Gatekeeper before access is granted, whereas the administration

operation deals with administrative functionalities.

Figure 9. VOMS User operations

The process starts when both the user and the VOMS server authenticate each other using

their certificates with the Globus API. The user then sends a signed request to the VOMS

Server which responds with the required information signed by it after verifying the user’s

identity. After ensuring the validity of this message, the user creates the proxy certificate

using this information into an extension. The user can optionally repeat this process for

multiple VOMS Servers and the information used to generate the proxy certificate may also

1. Authentication

2. User signed request Auth

DB

V

O

M

S

U

S

E

R

Query

4. Signed requried information

VOMS

pseudo

-cert 3. Checks correctness of request

5. Check validity of information

C=xx/ O=xx

/L=xx

/CN=xxxx

VOMS

pseudo-

cert 6. Create the proxy certificate


14

include information supplied by user such as the Kerberos tickets, etc. This process is

depicted in Figure 9.

The proxy certificate generated after the above operation is then validated by the Gate Keeper,

i.e., the Grid interface to the fabric in Globus based Grids after which an external service is

used to extract authorization information from the proxy certificate in order to process the

authorization information. In addition to this, as the VOMS information is included as a non-

critical extension of the original certificate, this enables it to be used by even the Gate

Keepers that do not have the support of VOMS. The Administration Server provides

administration functionalities and uses SOAP for connections to be convertible into an OGSA

service. It consists of five routines namely: Core, Admin, History, Request and Compatibility.

The Core provides the basic functionality for clients, the Admin provides methods to perform

administrative tasks on the database, the History routine provides the logging and auditing

functions, the Request routine enables mechanisms for integrated requested handling and the

Compatibility routine provides a simple access to the user list for the mkgridmap utility [24].

VOMS has similar limitations to the CAS system. For example, VO admin manages user

membership and attributes. This necessarily places a large burden on VO administrator. In

addition, a centralized VOMS server needs to run, thus it does not scale well for large VOs.

3.2.4 PERMIS

PERMIS (PrivilEge and Role Management Infrastructure Standard) [26] is an advanced

authorization infrastructure based on the X.509 Privilege Management Infrastructure (PMI)

[27], which has an analogy to the PKI. In PMI, Attribute Authority (AA) issues X.509

attribute certificates (ACs) [28] to users and an AC is used as a credential to store a binding

between a user’s unique DN and the user’s privilege attributes. The root of trust of the PMI is

called the Source of Authority (SOA).

PERMIS differs from other RBAC authorization systems in that access control decisions are

made based upon users’ attributes, not just upon their organisational roles as in conventional

RBAC. This authorization model is named as attribute based access control (ABAC).

PERMIS can support ABAC model as the basis of the PMI is user attributes stored in ACs:

administrators issue ACs to users which reflect users’ the attributes and roles, and service

providers publish policies that detail the access rights granted to each role or attribute. In

other words, service providers determine a user’s access right based on the user’s attributes

issued by administrators.

The components of PERMIS architecture is depicted in Figure 10 which also illustrates the

authorization model of PERMIS [20]. The PERMIS authorization decision engine consists of

the Policy Decision Point (PDP) and the Credential Validation Service (CVS). This decision

engine is superior to conventional decision engines in that it has the ability to validate user

credentials performed by the CVS. When a user requires access to a PERMIS protected

service, the Policy Decision Point (PDP) informs the Policy Enforcement Point (PEP) about

the credentials required for access. The PEP then collects these credentials either from the

Credential Issuing Service (CIS) or the attribute Repository (AR) following which the user’s

request is directed to the target which has initialized the Credential Validation Policy (CVP)

and Access Control Policy (ACP). The CVP defines which attributes are trusted from which

authority whereas the ACP defines the privileges given to attributes. After validation by the

CVS, the user attributes are passed to the PDP which takes the decision based on the ACP

which is then enforced by the PEP.


15

Figure 10. Components and Authorization Model of PERMIS

Comparing with other traditional authorization infrastructures, PERMIS offers a couple of

advantages highlighted as follows:

• In PERMIS, user attributes are held in attribute certificates which describe a user’s rights

and the target services then read the user’s AC to see if the user is allowed to perform the

action being requested. This approach de-couples users’ privileges from their local

identity and thus enables scalability and flexibility of access control, especially for large-

scale VOs with a big number of user, service providers and access requests.

• In PERMIS, each site administrator throughout a VO can act as attribute authorities and

assign attributes to site members. Therefore the task of allocating entitlements in the form

of ACs is distributed throughout the VO, which indicates the workload of VO

administrator is relieved greatly. This is especially meaningful for large-scale and

dynamic VOs which may contain a number of participating sites and site members are

changing frequently.

• PERMIS is policy-driven authorization system in that a service provider makes

authorization decisions using policies or rules. Service providers have the flexibility to

write multi-grain and conditional access policy on the basis of user attributes, either in

XML format or X.509 signed certificate.

• PERMIS can provide both the PDP and PIP functionality required by the Globus Toolkit

(PERMIS CVS is a PIP according to the Globus model, whilst the PERMIS PDP is a

PDP), and it can be easily integrated into the generic access control framework described

earlier. This indicates that service providers only need to specify access control policy,

and leave the PERMIS to enforce their policy on their behalf. This reduces service

provider’s authorization workload significantly.

Environment Environment

PEP PEP

PDP

Subject Target

CVS PDP

DIS AR

Policy

Editor

Policy

Editor

AR=Attribute Repository DIS=Delegation Issuing Service CVS=Credential Validation Service

PDP=Policy Decision Point PEP=Policy Enforcement Point SOA=Source of Authority

Subject

SOA

Attribute

Authority

Target

SOA 0

0

0 0

PERMIS

Authorization

System

0

1

3 4 5 6

2 10

8 9 11 12


16

3.2.5 Akenti

Akenti is an authorization infrastructure aiming to provide scalable security services for

highly distributed network environments such as Grids. The approach followed by Akenti

uses digitally signed certificates, capable of carrying user identity authentication, resource

usage requirements, attribute certificates and delegated authorization [29]. Akenti is very

much similar to PERMIS authorization infrastructure in that both have a gateway controlling

user access to resources, both of them write their policies in XML, and store their policies in

certificates and both of them can store their user credentials as certificates in LDAP

directories (see Figure 11).

The Akenti policy is distributed and hierarchical and consists of two components i.e. Use-

Condition Certificates and Policy Certificates. A Use-Condition certificate places

requirements on the attribute certificates (ACs) and public key certificates (PKCs) that users

must have in order to gain access to a resource whereas a Policy Certificate states the overall

policy for controlling access to a resource, and holds the trusted Certification Authorities

(CAs) and Stakeholders, and URLs for searching for Use-Condition certificates that are

applicable [30]. Akenti defines a stakeholder as a special kind of authority that is trusted to

issue Use-Condition certificates and subordinate policies. Furthermore, each stakeholder can

impose his own access control requirements independently of other stakeholders. Policy

Certificates comprise a root policy certificate, and optionally subordinate policy certificates

that inherit from the root policy. With Akenti, each target is treated as a tree of resources,

where each of the branches can have its own sub-policy in addition to the policy of the

superior branch. Each of the policies can be issued by different stakeholders.

Figure 11: Authorization Model of Akenti

Use-Condition certificates contain the name of a target resource, conditions on its use, a

critical flag, the trusted issuing, plus a list of privileges that are granted if the conditions are

satisfied. Conditions define the attributes a user must have, which can be identity attributes

from PKCs , role or group memberships, attributes from ACs, and environmental parameters

e.g. time of day. Rights are comma separated lists of actions on targets. An Akenti Policy

Certificate comprises the name of the resource to which this policy applies, information about

the trusted CAs, the trusted stakeholders and URLs to search for Use-Condition certificates,

the caching time, and optionally URLs to search for user ACs [52]. The whole policy is

signed by one of the stakeholders and must be stored securely to stop it being switched for

another one.

Client Resource

Gateway Akenti

Policy

Certificates


17

In Akenti there can be multiple stakeholders participating in administering the resource. All

the stakeholders can issue Use-Condition certificates, and one of them creates and signs the

root policy and places it in a secure store. The root policy lists the other stakeholders who are

trusted to issue subordinate policies and Use-Condition certificates. In Akenti, ACs are issued

to users, and hold their privileges either directly or indirectly via an attribute or role. These

certificates can be stored in LDAP, HTTP or a file repository. A user is identified via his

LDAP DN and the DN of the CA issuing his public key certificate.

Akenti only operates in single step decision making mode, but is able to make different types

of decisions. The client can ask “What can a user do?”, as well as the traditional “Can this

user perform this action on this target?” Akenti always embeds its response in a Capability

Certificate which contains the privileges for the user. A Capability Certificate contains the

public key of the user, the DN of the user and his CA’s DN, the name of the resource, and the

privileges for the user, optionally with a list of conditions attached to each of them. The

Capability Certificate is then signed by Akenti and given to the client i.e. either a user or a

gatekeeper. The user then presents this certificate to a gatekeeper which checks the signature

of the capability and then ask the user to sign a challenge for access control decision.

3.3 Comparison of Grid Authorization Technologies and Infrastructures

In this section, we compare Grid authorization technologies and infrastructures in terms of the

following aspects:

• Authorization model – the authorization decision can be made based on user name, user

group, user role, user attributes, etc. However, different authorization method may

considerably affect the service providers’ administration work. Ideally, the service

providers should simply determine what type of access to grant to the different categories

of user, and then leave the authorization infrastructure to enforce this policy.

• Authorization mode – generally, there are two types of authorization modes. A

centralized authorization mode has a central authorization entity for allocating rights for

all the users in a particular community, while a distributed authorization mode has no

centralized entity to do rights allocation.

• Authorization delegation – the resource owner should be able to delegate to other partners

in the VO the ability to identify and nominate the users from their respective domain who

are to be allowed to use his/her resource, leaving him/her to simply determine what type

of access to grant to the different categories of user.

• Authorization granularity: an authorization infrastructure should allow each resource

provider to write the policy determining which user is authorized to do what. Furthermore,

an authorization infrastructure should provide flexibility for resource owners to define

multi-grained (coarse grained or fine grained) policies for access control.

• Performance scalability – for a service protected by authorization infrastructure, the

overheads incurred by authorization procedure should be acceptable, comparing with the

case without security at all. Furthermore, the overheads incurred by the authorization

infrastructure to make authorization decisions should not increase significantly with the

growth of Grid VO, e.g. increasing number of users, requests, or service providers.

• Authorization manageability – the administrative work of each service provider is

expected to be simple and easy. Service providers should not be expected to individually


18

identify and name each VO user who is allowed to access their resources, as this make

administration work costly to manage. An authorization infrastructure should have

appropriate mechanisms such as delegation of authorization, to reduce the burden of

service providers.

• Authorization usability – an important factor in the success of an authorization

infrastructure is its usability. Usability in the context of authorization can be evaluated by

the ease of specifying the access control policy. Usually resource owners expect an

authorization infrastructure to provide an easy-to-use interface to define and manage

access control policy without sacrificing the expressiveness of policy and without

affecting the performance of system.

• Credential confidentiality – some authorization infrastructures employ certain form of

credentials (e.g. attribute certificates) to carry the information used as the basis for

authorization decision-making. The basic security principle requires that these credentials

should be kept with the authorization systems rather than the end users thereby avoiding

the misuse of credentials.

• Communication confidentiality – information communication between an authorization

infrastructure and its clients must be carried out using encryption. Through some well-

established cryptographic technologies like TLS [31], MLS [32], SAML, confidentiality

on communication could be achieved.

Grid-map file CAS VOMS PERMIS Akenti

Authorization

Model

Based on user identity

Based on user role

Based on user attribute



Authorization

Mode

Distributed

authorization mode

Centralized AuthZ

mode; need to run a centralized CAS

server

Centralized

AuthZ mode; need to run a

centralized

VOMS server

Distributed

authorization mode

Distributed

AuthZ mode defined by Stake

holders

Authorization

Delegation

No authorization delegation

SP partially delegate

authorization to

VO admin.

SP partially delegate AuthZ

to VO admin.

SP only need to specify policy,

and leave AuthZ

infrastructure to enforce policy.

Can be achieved by using

stakeholders

appropriately

Authorization

Granularity

Coarse grained

access control

list; SP cannot

set fine-grain policy; not

policy driven

access control

VO admin

asserts rather

coarse-grain

policy based on user role, while

each SP defines

fine-grain policy.

VO admin

manages user

membership and

attributes, while SP can define

fine-grain policy

based on user attributes.

Multi-grain

access policy

based on user

attributes; policy driven access

control

Multi-grain

access policy

based on user

attributes, policy driven access

control

Performance

Scalability

Each SP needs to maintain a

Gridmap file;

neither scalable nor flexible

Not scale well in case of large

number of

access; single point of failure

on CAS server.

Not scale well for large scale

Grid VO; a

single point of failure on CAS

server.

Scale well for large scale Grid

VO.

Scale well for large scale Grid

VO.

Authorization

Manageability

Each SP needs dynamically

maintain a Grid-

map file, and has heavy load on

user AuthZ

VO admin needs to maintain all

users’ capabilities,

and has heavy load on AuthZ

management.

VO admin needs to maintain all

users’ rights, and

has heavy load on AuthZ

management.

Independent AuthZ

infrastructure

enforces AuthZ policy on SP’s

behalf., making

SP’s AuthZ work

reduced greatly.

Achieved using the delegation

capabilities


19

Authorization

Usability

Easy-to-use

policy but lack of

expressiveness.

Plain as

extension to proxy certificates

Not addressed Easy-to-use

interface for specifying

policy; formatted

policy in XML

or signed X.509

GUI to create

Policy Certs, Resource use-

condition Certs

and user ACs

Credential

Confidentiality

Not applicable ACs are kept

with users.

ACs are kept

with users.

ACs kept with

AuthZ engine.

ACs kept with

AuthZ engine.

Communication

confidentiality

Communication

through TLS/MLS

Communication

through SAML

Communication

through SAML

Communication

through SAML

Communication

through SAML

* AuthZ=Authorization SP=Service Provider Cert=Certificate Admin=Administrator

Table 2. Comparison of Authorization Technologies and Infrastructures

Table 2 summarizes the features of the authorization infrastructures discussed. We can see

that, to facilitate authorization in large-scale Grid VO environments, an ideal authorization

infrastructure is expected to have delegation capability, low management cost, high scalability,

fine granularity, good usability and confidentiality. Some advanced authorization

infrastructures such as PERMIS and Akenti are representatives of this trend.

4 Shibboleth Authentication and Authorization Technology

In this section, we will review the Shibboleth authentication and authorization technology in

terms of its architecture and protocol, features and advantages. We will also discuss some

typical Shibboleth projects.

4.1 Introduction to Shibboleth

Shibboleth [33] is an authentication and authorization architecture to support inter-

institutional sharing of resources. Shibboleth is based on SAML protocol for the secure

passing of identity information between users’ institutions and resource providers. Shibboleth

is an attribute based mechanism, and enables fine grained authorization which is the demand

of complex systems like Grid environments.

Shibboleth promotes the idea of building federations of the collaborating institutions that trust

each other to authenticate their users properly. In this way, it extends the local authentication

and authorization mechanisms and allows the participants of a federation to trust each other’s

local security procedures whereby a user can use the same local login information to access

remote resources.

4.2 Shibboleth Architecture and Protocol

The Shibboleth architecture defines several components which are necessary to achieve the

integration of collaborating sites to form a federation. The major components include an

Identity Provider (IdP), a Service Provider (SP) and an optional Where Are You From

(WAYF) service. The IdP is installed at the user’s home organization whereas the SP is

installed at the resource provider’s site. Figure 12 illustrates the Shibboleth architecture and

its components.

The invocation of a Shibboleth protected service can be briefly described as follows [34].

When a user makes a request to a resource provider, Shibboleth redirects the user to a WAYF

service presenting the user with a list of institutions from which the user can select his/her

home institution. After that, the user is redirected to the home organization’s IdP, and enters

credentials as the user would normally do. The IdP then sends the browser back to the

resource provider along with an SAML assertion message saying that the user has


20

successfully signed on. The SP validates this assertion message and requests additional

attributes such as role from the organization’s IdP. On receiving these attributes, the SP

provides them to the resource provider which in turn uses these attributes and the access

policy to decide whether access is permitted or not.

Figure 12. Shibboleth Architecture and Components

An important fact to note is that all this process is transparent to users, i.e., the transfer of

attributes and assertion messages between the IdP and SP is transparent to the end users.

4.3 Features, Advantages and Limitations of Shibboleth

Through above discussion, we can see that the main feature of Shibboleth is that it relies on

the institution to establish identify (i.e., authentication), and on the resource provider to

determine access rights (i.e., authorization). That is to say, Shibboleth separates the user

authentication that is performed by users’ respective home institution, and the authorization

that is performed by the resource providers based on users’ attributes that have been passed to

it. Table 3 summarizes the features and advantages that Shibboleth offers.

However, Shibboleth also has limitations. The major limitation of Shibboleth when deployed

in a dynamic environment such as a Grid environment is its static relationships. Shibboleth

requires that the participants of a federation have already decided the attributes to be used for

authentication and authorization purposes. This is in contrast with the dynamic nature of Grid

computing where VOs can be dynamically created thereby linking disparate resources at run

time.

In addition to this, there are a few other challenges when applying Shibboleth in Grid

environments. These mainly lie on the harmonization of the Grid and Shibboleth as being the

integration with existing access control approaches e.g. grid-map files, centralized

management of X.509 certificates and finally the issue of trust, i.e., collaborating sites need to

ensure that local security procedures are efficient enough to provide resilient authentication

services [35]. In the following section, we will discuss some projects that address these

chanllenges.

SP

Resource

Provider

WAYF

7. SP sends

attributes to

RP

3. User logs in

at home

institution

8. User is notified whether

access is permitted

1. User makes a request to RP

2. User selects home institution

4. IdP sends assertion message to SP

5. SP requests additional attributes

6. IdP sends requested attributes to SP


21

Issues Features Advantages Implications

User

Authentication

� Shibboleth devolves all

responsibility for user

AuthN to the users’

respective institutions, i.e.

user AuthN only happens

at the users’ home

institutions.

� Remove the need for

authenticating users at every

instance of remote service

provision

� Realize SSO AuthN across

multiple SPs

� Make user AuthN scalable with

the growing size of the VO

� Involves less integration work to bring in a new institution or

user

� A trust model between the

AuthN institution and the

remote SPs

� User home institution should

have a robust and up-to-date

AuthN system in place.

� The need for trust requires the

formation of federations which

define similar groups agreeing to a common set of policies.

User Privacy � Users’ home institutions

only pass info about

users’ status (attributes) to SP rather than their

personal identity.

� Users’ home institutions control what attributes get

released to remote SPs

� Users’ personal identity

information is protected

� Release the minimum amount of info about users required by

the remote SP for AuthZ and to

balance the needs of the SP to make valid AuthZ decisions

with the desire to preserve as

much of the users’ privacy as

possible.

� A federation needs to define

the users’ attributes required to

be released. Each institution must adhere to the policy.

� Users’ home institutions and

SP must negotiate the actual attributes about user required to

make valid AuthZ decisions.

Access

Authorization

� SPs have the freedom to

define their own AuthZ

policy and decide upon what attributes are needed

for AuthZ decisions to

access services.

� Make AuthZ management

more flexible over the

traditional approach of using users and group identifiers.

� Enable SPs to implement

multi-grained access control

and effectively control access

based on users’ attributes

� SPs need to adopt an

appropriate AuthZ model

which makes AuthZ decisions based on users’ attributes

* SP=Service Provider AuthN=Authentication AuthZ=Authorization

Table 3. The Shibboleth Features, Advantages and Implications

4.4 Shibboleth Related Projects

There are a variety of projects related to Shibboleth technology. These projects can be put

into two categories, i.e. integration of Shibboleth with Grid technologies, and the application

of Shibboleth on different domains. Table 4 and Table 5 list some typical projects in these

two categories, and also give a summary of these projects.

Project Name Organization Project aims & objectives

GridShib NCSA, Uiversity

of Chicago, ANL,

US

GridShib [36] focuses on interoperability between GT with Shibboleth. It

addresses the issue of allowing Grid services to obtain attributes from

Shibboleth servers to facilitate authorization decisions. However, this

approach doesn’t directly address Shibboleth SSO to a Grid environment.

ShibGrid University of

Oxford, UK

The ShibGrid project [37] aims for Shibboleth-based access to UK National

Grid Service (NGS) [38]. ShibGrid also presents a solution to one of the

main issues of SSO systems; how to dependably link users' identity in two

different security domains (Shibboleth/SAML and Grid Security

infrastructure/X.509). ShibGrid integrates Shibboleth, GSI and myProxy [39]. Users will be able to access internal/external recourses seamlessly by a

single institutionally controlled identity.

SHEBANGS University of

Manchester, UK

The SHEBANGS (Shibboleth Enabled Bridge to Acess the National Grid

Service) project [40] develops a bridge enabling a user authenticated by a

trusted Shibboleth IdP to acquire (or delegate) temporary credentials to access resources on the National Grid Service. It makes use of a standard

MyProxy server, requires no modifications to Shibboleth or Globus

middleware, but may necessitate minor modifications to a Web portals.

ShibVomGSite

University of

Manchester, UK

This ShibVomGSite project presents an authentication and authorization framework that integrates Shibboleth and VOMS to allow users access to

GridSite [41] protected resources anywhere and anytime. In ShibVomGSite,

VOMS is used as an attribute repository and Shibboleth retrieves VOMS attributes and presents to GridSite to make resource authorization decisions.

GridShibPERMIS

University of

Kent, UK

The GridShibPERMIS project [42] integrates the identity federation and attribute assignment function of Shibboleth with the policy based

enforcement function offered by the PERMIS access control infrastructure to


22

authorize Grid jobs running with Globus Toolkit in order to provide policy

driven role-based access control decision making to Grid jobs.

FAME-PERMIS University of

Manchester, UK

The FAME-PERMIS (Flexible Access Middleware Extensions to PERMIS)

project [43] aims to develop middleware capable of supporting a wide range

of authentication methods and integrate it with Shibboleth, and feed the

authentication strength into PERMIS so as to enable authentication strength

linked access control based on PERMIS.

ESP-Grid Oxford University,

UK

The ESP-Grid (Evaluation of Shibboleth and PKI for Grids) [44] project

investigates how PKI and Shibboleth can fulfil the functional requirements

of Grids with regard to security, authentication and authorization

Condor-Shib University of

Wisconsin and

Georgetown

University, US

The Condor-Shib project [45] aims to integrate Condor job scheduler with

Shibboleth technology, and provides Grid access to computational resources

using role based authorization. The merger of Condor and Shibboleth will

create a scheduler capable of consuming roles attributes in a framework that

allows rapid, scalable control of the utilization of computational resources

for collaborations which span administrative domains

Sakai VRE UK universities One activity of the Sakai VRE project [46] is Shibboleth integration which

allows VRE (Virtual Research Environment) users to authenticate in the

same way as they do to see various resources. It aims to demonstrate the

effectiveness of Shibboleth in providing integration between institutional and

national information environments, via Sakai, portals and portlets. Other efforts in the integration of Shibboleth with portal frameworks include

SPIE and PERSEUS. SPIE (The Shibboleth-enabled Portals and Information

Environments) project [47] integrates Shibboleth within an institutional information environment, including both a portal environment and single

sign-on authentication system. PERSEUS (Portal-Enabled Resources via

Shibbolized End-User Security) project [48] addresses the key challenge of Shibboleth-based access management to information resources via an

institutional portal, using the uPortal [49] Open Source portal toolkit.

Table 4. The Integration of Shibboleth with Grid Technologies

Project

Name

Organization Project aims & objectives

UK Access

Management

Federation

UK JISC UK Access Management Federation for Education and Research [50] aims to

build a Shibboleth based access management infrastructure for the UK

educational sector which allows students and staff to access to a wide-range of resources by using their institutional username and password.

Similar initiatives in other countries to establish Shibboleth-based access

management federation include the Meta-Access management System (MAMS) [51] and VeRSI (Victorian eResearch Strategic Initiative) [52] in

Australia, SWITCH (Swiss Education & Research Network) Authentication

and Authorization Infrastructure (AAI) [53] in Switzerland, etc.

DyVOSE University of Glasgow

and University of Kent,

UK

The DyVOSE (Dynamic Virtual Organizations in e-Science Education) project [54] aims to build advanced security infrastructure in

education domain. Overall goal is to explore how dynamic Grid VO could be

established building upon advance authentication and authorization infrastructures, especially through Shibboleth and PERMIS technology.

SEE-GEO EDINA National Data

Centre, University of

Edinburgh, UK

The SEE-GEO (SEcurE access to GEOspatial) project [55] aims to make national data centre data available on the NGS using OGSA-DAI. A specific

objective of the project is to demonstrate the use of Shibboleth to securely

access geospatial Web services using open interoperability standards running

on the NGS.

IMPETUS University of Leicester

and De Montfort

University, UK

The IMPETUS (Infrastructure for Multi-Professional Education and Training

Using Shibboleth) project [56] focuses on the implementation and testing of

Shibboleth in the context of multi-professional healthcare education and training Centre, in order to enable resource sharing.

IAMSECT Universities of

Durham, Newcastle

and Northumbria, UK

The IAMSECT (Inter-institutional Authorization Management to Support e-

Learning with reference to Clinical Teaching) project [57] focuses on

implementing Shibboleth based inter-institutional authentication and authorization management services to access medical Virtual Learning

Environment using a rich set of authorization attributes.

E-

Infrastructure

for social

science

National Centre for e-

Social Science, UK

The e-infrastructure for social science project [58] aims to build a Shibboleth

based security framework that enables secure access to various e-social

science resources.

Table 5: Shibboleth Applications Projects


23

5 Conclusions

The Grid is a large scale distributed system that supports the formation of Virtual

Organizations from scattered communities and thereby realizes resource sharing among VO

members. Resource sharing necessitates a security infrastructure to underpin the overall Grid

infrastructure. A Grid security infrastructure needs to address two critical issues of security in

a Grid environment, i.e., authentication and authorization. This report reviews major

authentication and authorization technologies and infrastructures used in a Grid environment

and compare them in detail. In particular, we discuss the Shibboleth authentication and

authorization technology, as well as a few typical projects that use Shibboleth technology as

the core security infrastructures (and integrate other authentication / authorization

technologies, in some cases) to solve a variety of issues related to Grid security. Based on

these discussions, we can see the evolvement of Grid authentication and authorization

technologies, and in conclusion, Shibboleth provides a promising solution for the security

infrastructure Grid environment, because it addresses the critical security issues in a Grid

environment:

• Scalability of security infrastructure – Shibboleth promotes the concept of federation, a

collection of institutions which trust each other to authenticate their users properly.

Shibboleth based Grid security infrastructure extends local authentication mechanisms

and allows the participants of a federation to trust each other’s local security procedures,

thus facilitating the authentication and authorization across organizational boundaries. By

devolving all responsibility for user authentication to the users’ respective institutions, a

Shibboleth based security infrastructure can scale well with large scale Grid VO, and also

bring flexibility for authentication.

• Heterogeneity of authentication systems – existing authentication systems developed by

the Grid community is largely based on the use of digital certificates, however, in a Grid

VO, each participating site/user may use different authentication systems. When working

as security infrastructure in a Grid environment, Shibboleth manages user authentication

at Grid VO layer, ‘glues’ various local authentication systems at Grid site layer, and

allows a user to use the local authentication mechanisms to achieve Grid VO wide

authentication. In other words, Shibboleth based Grid security infrastructure introduces a

two-layer authentication scheme and is capable of supporting a wide range of

heterogeneous authentication methods, and allows a user to gain authentication using

local authentication system.

• Granularity of authorization – many Grid applications have security requirements on the

protection of confidential nature of data and results, and it can only be achieved by having

fine-grained access control mechanisms. Shibboleth technology implements secure

transfer of user's attributes from users’ home sites to remote service providers, and these

attributes can be fed to appropriate authorization infrastructures (like PERMIS, CAS,

VOMS, etc) to make fine-grained authorization. This indicates that Shibboleth

architecture provides technical basis and linkage for the provision of fine-grained access

control in a Grid environment: when integrated with appropriate underlying authorization

mechanisms, Shibboleth based Grid security infrastructure can realize fine-grained access

control.

All these arguments suggest that, today, Shibboleth is the best available security scheme for a

Grid environment. This has been demonstrated by the projects and applications that

successfully use Shibboleth technology to solve various security issues in a Grid environment.

However, it should be noted that authentication and authorization in a Grid environment is a

complex issue and security requirements are diverse, therefore it is unlikely that Shibboleth

will become a universal solution, no matter how Shibboleth has been exciting in the area of

authentication and authorization.


24

References

1. M. Surridge. A Rough Guide to Grid Security. Technical Report, IT Innovation

Centre, V1.1a, 2002.

2. P.J. Broadfoot and A.P. Martin. A Critical Survey of Grid Security

Requirements and Technologies. Technical Report, Oxford University

Computing Laboratory, PRG-RR-03-15, 2003.

3. I. Foster and C. Kesselman, The Anatomy of the Grid: Enabling Scalable

Virtual Organizations. International Journal of High Performance Computing

Applications. 15: p. 200-222, 2001.

4. J. Weise. Public Key Infrastructure Overview. Available from

http://www.sun.com/blueprints/0801/publickey.pdf.

5. D.R. Kuhn, et al. Introduction to Public Key Technology and the Federal PKI

Infrastructure. National Institute of Standards and Technology, 2001.

6. D. Eastlake and P. Jones. RFC3174: US Secure Hash Algorithm (SHA1).

Available from http://www.faqs.org/rfcs/rfc3174.html.

7. K. Raeburn. RFC 3962: Advanced Encryption Standard (AES) Encryption for

Kerberos 5. Available from http://www.ietf.org/rfc/rfc3962.txt?number=3962.

8. C.C.I.T.T. Recommendation X.509. The Directory - Authentication Framework.

C.C .I .T .T., 1988.

9. I. Foster, et al. A Security Architecture for Computational Grids. ACM

Conference on Computers and Security, 1998.

10. Globus Toolkit. Available from http://www.globus.org.

11. S. Tuecke, et al. Internet X.509 Public Key Infrastructure Proxy Certificate

Profile. IETF, 2001.

12. C. Neuman, et al. RFC 4120: The Kerberos Network Authentication Service

(V5). Available from http://www.ietf.org/rfc/rfc4120.txt?number=4120.

13. Athens for Education. Available from http://www.athens.ac.uk.

14. Incorporating ATHENS into ROADS. Available from

http://www.ukoln.ac.uk/metadata/roads/athens/.

15. Open Grid Forum. Available from http://www.ogf.org.

16. ITU-T Rec X.812|ISO/IEC 10181-3:1996. Security frameworks for 475, open

systems: access control framework. 1995.

17. OASIS Security Services Technical Committee. Security Assertion Markup

Language (SAML) v1.1. OASIS Standard 200308. Available from

http://www.oasisopen.org/specs/index.php#samlv1.1.

18. Organization for the Advancement of Structured Information Standards.

Available from http://www.oasis-open.org.

19. V. Welch, et al. Use of SAML for OGSA Authorization. 2004; Available from

https://forge.gridforum.org/projects/ogsa-authz.

20. D.W.Chadwick, A. Novikov, and A. Otenko, GridShib and PERMIS Integration.

Campus-Wide Information Systems. 23(4): p. 297-308, 2006.

21. OGSA-DAI Project. Available from http://www.ogsadai.org.uk/.

22. A.L. Pereira, V. Muppavarapu, and S.M. Chung, Managing Role-Based Access

Control Policies for Grid Databases in OGSA-DAI Using CAS. Journal of Grid

Computing. 5(1): p. 65-81, 2007.

23. L. Pearlman, et al. A Community Authorization Service for Group

Collaboration. IEEE 3rd International Workshop on Policies for Distributed

Systems and Networks, 2002.


25

24. R. Alfieri. Managing Dynamic User Communities in a Grid of Autonomous

Resources. Conference for Computing in High Energy and Nuclear Physics,

2003.

25. R. Alfieri, et al., From gridmap-file to VOMS: Managing Authorization in a

Grid Environment. Future Generation Computer Systems 21(4): p. 549-558,

2005.

26. D.W. Chadwick, A. Otenko, and E. Ball, Role-based Access Control with X.509

Attribute Certificates. IEEE Internet Computing: p. 62-69, 2003.

27. ISO 9594-8/ITU-T Rec. X.509, The Directory: Public-key and Attribute

Certificate Frameworks. 2001.

28. S. Farrell and R. Housley. An Internet Attribute Certificate Profile for

Authorization. Internet-draft 2002.

29. Akenti Distributed Access Control. Available from http://dsd.lbl.gov/Akenti.

30. D. Chadwick and O. Otenko. A Comparison of the Akenti and PERMIS

Authorization Infrastructures in Ensuring Security in IT Infrastructures. ITI First

International Conference on Information and Communications Technology

(ICICT), 2003.

31. T. Dierks and C. Allen. The TLS Protocol Version 1.0. Available from

http://www.ietf.org/rfc/rfc2246.txt.

32. Message Level Security. Available from

http://www.globus.org/toolkit/3.0/ogsa/docs/message_security.html.

33. Shibboleth Project. Available from http://shibboleth,internet2.edu.

34. R.L.B. Morgan, et al. Federated Security: The Shibboleth Approach. Educause

Quarterly, 2004.

35. R.O. Sinnott, et al. Shibboleth-based Access to and Usage of Grid Resources.

7th IEEE/ACM International Conference on Grid Computing, 2006.

36. GridShib Project. Available from http://gridshib.globus.org.

37. ShibGrid Project. Available from

http://www.oesc.ox.ac.uk/activities/projects/index.xml?ID=ShibGrid.

38. UK National Grid Service. Available from http://www.grid-support.ac.uk/.

39. J. Basney, M. Humphrey, and V. Welch, The MyProxy Online Credential

Repository. Software- Practice & Experience. 35(9): p. 801-816, 2005.

40. SHEBANGS Project. Available from

http://www.rcs.manchester.ac.uk/research/shebangs.

41. GridSite Project. Available from http://www.gridsite.org.

42. GridShibPERMIS Project. Available from

http://www.jisc.ac.uk/uploaded_documents/GRIDShibPermis.pdf.

43. FAME – PERMIS Project. Available from http://www.cs.man.ac.uk/fame-

permis.

44. ESP-GRID Project. Available from http://labserv.nesc.gla.ac.uk/projects/esp-

grid/index.html.

45. Condor-Shib Project. Available from http://hendrix.arc.georgetown.edu/condor-

shib/index.html.

46. Sakai VRE Project. Available from http://tyne.dl.ac.uk/Sakai/.

47. SPIE Project. Available from http://www.oucs.ox.ac.uk/rts/spie.

48. PERSEUS Project. Available from http://www.angel.ac.uk/PERSEUS.

49. uPortal Project. Available from http://www.uportal.org.

50. UK Access Management Federation for Education and Research. Available

from http://www.ukfederation.org.uk.


26

51. Meta-Access management System. Available from

http://www.melcoe.mq.edu.au/projects/MAMS.

52. Victorian eResearch Strategic Initiative. Available from

http://versi.edu.au/index.html.

53. Authentication and Authorization Infrastructure. Available from

http://www.switch.ch/aai.

54. DyVOSE Project. Available from http://labserv.nesc.gla.ac.uk/projects/dyvose/.

55. SEE-GEO Project. Available from http://edina.ac.uk/projects/seesaw/index.html.

56. IMPETUS Project. Available from http://ribble.dmu.ac.uk/impetus/index.html.

57. IAMSECT Project. Available from http://iamsect.ncl.ac.uk/.

58. M. Daw and R. Procter. Developing an e-Infrastructure for Social Science.

Third International Conference on e-Social Science, 2007.


27

Use Case and Security Requirements of the e-Infrastructure for

Social Science Project

1 Introduction

This is the 2nd

part of the review report as the deliverable D3.2.1 of the e-

infrastructure for social science project. This report firstly discusses a use case that we

intend to adopt as a demonstrator for the e-infrastructure for social science project, i.e.,

the GEODE system. Then we analyze security requirements raised by the use case,

and discuss the technical challenges and issues we need to address in order to fulfil

the security requirements.

2 Use Case

The main use case investigated is the GEODE (Grid Enabled Occupational Data

Environment) system [1] developed by the University of Stirling. GEODE is a project

investigating the application of Grid technology in the field of social science. The

focus of this project is to create a security enabled data grid that links disparate

occupational data resources from across multiple domains, in order to publish,

discover, access, and analyze occupational information.

GEODE aims to improve the current utilisation of occupational data by leveraging the

Grid technology [2, 3]. The goal of this project is to create a virtual community where

disparate occupational data resources that may come from different administrative

sites can be virtualised, indexed, and uniformly accessed by users from the social

sciences in a secure manner, thus making occupational information can be discovered,

exchanged and collaborated on. Additionally, occupational data researchers who are

the members of this virtual community can have their occupational data resources

abstracted, described and deployed in a grid environment, thus standardising the

practice of publishing quality datasets.

The high level architectural design of GEODE is depicted in Figure 1. The GEODE

system has a pool of Grid services, mainly a centralized index service, various data

services and application services running at different joining sites of the virtual

community, as well as distributed occupational date resources. Users interact with the

grid indirectly through the GEODE portal as their web interface.

• Index service - The GEODE Index Service is core service of the virtual

community. It is used to discover services and resources in the virtual community.

It is deployed on the default index service supplied by Globus Toolkit 4. This

index aggregates registration information from services and data resources, where

the respective metadata is propagated by each registering service or date resource.

• Data services - Based on OGSA-DAI configurable data services and appropriate

drivers, the GEODE data services provide the data abstraction on occupational

data to overcome issues of heterogeneity of data sets including relational tables

and text files. Data resources are deployed dynamically and register with the index

service where discovery could be made.


28

• Application services - The application services are grid services developed using

GT4 to provide specific data analysis functions on the data resources. The

application services access the data resources and render specified results to the

user via the portal. At the first stage, only the CAMSIS score linking service is

implemented.

Figure 1. GEODE Architecture

3 Security Requirements

The security requirements raised by the e-infrastructure for social science project can

be categorized into two aspects, i.e., authentication and authorization. In the following

we will discuss security requirements in these two aspects, and outline the issues we

intend to address in order to fulfil the security requirements.

3.1 Authentication Issue

Authentication will take place before users gain access to the e-infrastructure. That is,

users will logon the e-infrastructure Sakai portal [4], type in user name and password,

and the e-infrastructure needs to check the identity of users to ensure that they are

allowed access to the services provided by the e-infrastructure. We will leverage the

widely accepted Shibboleth technology to address the authentication issue in the e-

infrastructure. Shibboleth is an authentication and authorization architecture to

support inter-institutional sharing of resources (or services) that are subject to access

control. Basically we will address two key issues related to Shibboleth based

authentication for the e-infrastructure.


29

3.1.1 Establish Shibboleth federation for e-social science community

We will build up a Shibboleth federation consisting of the institutions of e-social

science community. As illustrated in Figure 2, users from participating sites of the

federation will access the e-infrastructure resources/services through a Shibboleth

enabled Sakai portal. Using Shibboleth, participating sites in the federation are

expected to trust local authentication infrastructures in establishing the identity of

users and there associated privileges. To establish the federation, each participating

site needs to set up several key components of the Shibboleth architecture and

associated protocols. These include the Identity Provider (IdP), Service Providers

(SPs) and the optional inclusion of a Where Are you From (WAYF) service.

Shibboleth offers several advantages for the security of the e-Infrastructure for social

sciences. First, end users will have single usernames and passwords at their own

institution which will provide for seamless access to a range of resources at

collaborating institutions and services providers. That is, single sign-on via

authentication at a home site and subsequent acceptance and recognition of the

authentication to remote sites. Second, Shibboleth separates the user authentication

that is performed by users’ respective home domains from the authorization that is

performed by the resource providers to be accessed based on users’ attributes.

Institutions can thus establish their own trust federations and agree and define their

own policies on attribute release, and resource providers can decide upon what

attributes and attribute values are needed to make authorization decisions for their

resources.

Figure 2. e-IP federation

Currently, the GEODE system can support two types of users: named users and guest.

Name users can perform a wider range of operations such as search data, download

End Users

e-IP Sakai

Portal

Site X …

Site Y

Data

Resources

Services

Data

Resources

Services

Site Admin

Site

Admin


30

data, use data matching service, deposit data, and manage data resources previously

deposited, and so on. Guest can only perform operations like data searching,

downloading, and marching service. When the GEODE authentication moves to

Shibboleth, named users will come from the participating sites of the Shibboleth

federation of e-social science community, however, some participating sites may user

their legacy authentication systems like Athens and the GSI of the Globus toolkit. As

such we may need to build gateways between Shibboleth infrastructure and other

authentication systems.

The guest users of the GEODE system will come from the non-participating

institutions of the federation of e-social science community. The centralized

authentication model based on username/password which is provided by the current

GEODE system can still be used for the users from non-participating sties, if those

sites would not set up Shibboleth.

3.1.2 Integrate Shibboleth with the Sakai portal

As Sakai is adopted as the e-infrastructure portal and Shibboleth is used as

authentication infrastructure, we need to incorporate Shibboleth into the Sakai portal,

or make Sakai Shibbolized. Three projects are currently under investigation as

possible solution for Shibboleth and Sakai integration, i.e., Sakai VRE, Guanxi, and

Mondo.

• In Sakai VRE demonstrator project [5], there are some activities on Shibboleth

deployment for Sakai VRE demonstrator, aiming to provide access control across

the Sakai VRE Demonstrator partner sites. Unfortunately, the project was

terminated halfway, and there is no useful outcome.

• The Mondo project [6] conducted at Stockholm University has developed Sakai

Shibboleth patches (a set of patches against Sakai enabling Shibboleth

authentication). They claim that they have been using it in production for some

time using Sakai 2.4.* and Shibboleth 1.3.x. The Bestgrid.org also provides a

BeSTGRID Shibbolized Sakai solution [7].

• Sakai Guanxi Shibb Kit (GSK) [8] is a portal that works in conjunction with the

main Sakai portal to allow users to log into Sakai using Shibboleth. Normal Sakai

users are not affected as the normal authentication and authorization mechanisms

of Sakai are not affected by the shibboleth portal. The shibboleth portal acts as a

holding area for users while they are authenticated by their Identity Provider and

their attributes gathered by the shibboleth portal.

We need to set up Shibboleth, Sakai, and those Shibboleth & Sakai integration

packages on the e-infrastructure project servers. Through experiments, we can further

evaluate the existing work and therefore find out the most appropriate solution and

problems if any.

3.2 Authorization Issues

The fine-grain authorization for grid-enabled datasets is a key security issue for the e-

infrastructure project. Social science applications heavily use various datasets, but


31

existing solutions of fine-grain authorization for grid-enabled datasets are still

application dependent. We will design an attribute based authorization infrastructure

for grid-enabled datasets based on the PIP/PDP framework, and incorporate VOMS

and PERMIS as authorization engine at VO layer and service provider layer,

respectively. We may liaise with Glasgow e-Science Centre (Richard Sinnott, John

Watt, etc) for their work on Shibboleth and PERMIS integration.

Currently, the GEODE system has not implemented an authorization infrastructure.

We assume that:

• There is a VO administrator who is responsible for the membership management

at the federation / VO layer;

• Each participating site has a site administrator, who has ultimate control over

users and data resources within that site, e.g. the site administrator may only allow

certain users to access some data resources or perform certain activities on the

services. In addition, each site administrator throughout a Grid VO can act as an

attribute authority and assign attributes to his/her site members/users. Thus the

allocation of entitlements (or ACs) is distributed throughout the entire VO.

Our analysis shows that there are basic authorization requirements for the GEODE

system as below:

• The GEODE is expected to implement access control mechanisms which reflect

data resource owners’ privileges, and protect diverse occupational data resources

by only allowing authorized accesses.

• The authorization infrastructure should provide data resource owners flexibility to

define their access control policy (be it coarse-grain or fine grain), as well as

modify or extend their current policy with ease.

To realize attributed-based authorization, (1) a set of attributes describing the users of

the GEODE needs to be defined, and these user attributes must be negotiated between

domain site administrators of a GEODE Grid VO. (2) We need to write the

authorization policy stating the rules for assigning roles to users and permissions to

roles. (3) An authorization engine should be designed to make access control

decisions, and manage user attributes and authorization policies.

The fine-grain authorization infrastructure designed will be combined with Shibboleth

as a whole authentication and authorization infrastructure. In this way, we introduce

Shibboleth as the method which authentication asserts identity within a federation,

and allocates the role, allowing the user access to a variety of e-infrastructure facilities.

We can offer scalable and flexible Grid VO-wide authentication as well as policy-

driven, role-based, multi-grained authorization for access to and usage of the e-

infrastructure resources.

Reference

[1] GEODE project, http://www.geode.stir.ac.uk/.


32

[2] Larry Tan, Vernon Gayle, Paul Lambert, Richard Sinnott and Ken Turner,

GEODE - Sharing Occupational Data Through The Grid, the 5th UK e-Science

All Hands Meeting, Nottingham, September 2006.

[3] Paul Lambert, Larry Tan, Ken Turner, Vernon Gayle, Ken Prandy, Richard

Sinnott, Developing a Grid Enabled Occupational Data Environment', 2nd

International Conference on e-Social Science, 2006.

[4] Sakai Project, http://sakaiproject.org/.

[5] Sakai VRE demonstrator project, http://tyne.dl.ac.uk/Sakai/.

[6] Mondo project, http://devel.it.su.se/pub/jsp/polopoly.jsp?d=2376&a=21472

[7] BestGrid Shibbolized Sakai,

http://www.bestgrid.org/index.php/BeSTGRID_Shibbolized_Sakai_Installation.

[8] Sakai Guanxi Shibb Kit,

http://www.guanxi.uhi.ac.uk/drguanxi/index.php/Sakai_Guanxi_Shibb_Kit.

Documents

review report v1.0 - Amazon S3 · Review Report - Grid Authentication and Authorization Technologies 3 State of the Art Review on Grid Authentication and Authorization Technologies