Using NMI Components in MGRID: A Campus Grid Infrastructure

Using NMI Components in MGRID: A Campus Grid Infrastructure

Andy AdamsonCenter for Information Technology Integration

University of Michigan, USA

Outline

• MGRID: Background and Motivation

• MGRID Architecture

• NTAP: A Grid Application

• Distributed Authorization Issues

• What's Next

MGRID

• Michigan Grid Research and Infrastructure Development is a collaborative effort of many parts of the University of Michigan focused on developing and deploying grid computing for the University of Michigan.– Characterize and optimize the UM network

– Assist in the development of Grid security middleware

– Determine the requirements for a production Grid site within the UM

– Develop and test Grid Applications

Why MGRID

• Multiple Grid efforts at the U of M– Clusters

– Automated network configuration and testing

– Remote instrument operation

• Middleware issues are difficult– Single solution

– Leverage existing security services

• Potentially large user base for Grid services

U of M Security Services

• Uniqname– Unique campus wide user name and UID

• Kerberos V5 (multiple cells)

• KX509

• Group Services– AFS PTS

– LDAP (email groups)

MGRID Architecture

mod ssl

mod kx509

mod kct

CHEF

Apache

Tomcat

KCT

GateKeeper

Service

Grid Service

KCA

Browser

kx509

libpkcs11

kinit

User Workstation

KDC

Kerberos V5

SSL – Client Certificate required

GSI

Kerberos

Kerberos

Grid-Mapfile

LDAPSASL

Web Server

1

2

3

4

5

6

7

6

Group Services

Resource MngAuthorization

8

mod jk

mod php

MGRID Portal

• Proxy KX509 credentials, keep the Globus client off workstations

• Ease of use for U of M faculty, staff, and students– Kerberos + kx509 + browser = Grid access

• Single point for PKI management– CA self-signed keys

– CA policy files

• Single entry point for MGRID services

MGRID Portal

• User workstation– KX509 to obtain user X509 credentials

– KX509 Certificate available to browser

• Additions to OpenSSL, required on Web Server– SSL handshake recorded

• Web server SSL configured to require user X509 credentials

MGRID Portal

• SSL Handshake transcript– Contains all packets exchanged

– Allows KCT to repeat user certificate verification

– Handshake time stamp used

• Apache module, mod_kct– Sends ssl handshake transcript to KCT service

– Requests KCA Kerberos service ticket

MGRID Portal

• Apache module, mod_kx509– Uses the KCA TGS

– Obtains user proxy KX509 credentials

– Places them in a ticket file

• Apache module, mod_php – Creates RSL, uses KX509 credentials

• CHEF runs in Tomcat– Communicates with Apache through mod_jk

– Creates RSL, uses KX509 or MyProxy credentials

MGRID Architecture

mod ssl

mod kx509

mod kct

CHEF

Apache

Tomcat

KCT

GateKeeper

Service

Grid Service

KCA

Browser

kx509

libpkcs11

kinit

User Workstation

KDC

Kerberos V5

SSL – Client Certificate required

GSI

Kerberos

Kerberos

Grid-Mapfile

LDAPSASL

Web Server

1

2

3

4

5

6

7

6

Group Services

Resource MngAuthorization

8

mod jk

mod php

MGRID NTAP Project

• NTAP: Network Testing and Performance• Globus Service to run network test and

performance tools• Purpose: Help build and maintain a secure and

functional network at UMICH

• Runs on multi homed nodes placed in a VLANed network

MGRID NTAP Architecture

Web Portal

Router 1

Host A

Router 2 Router 3

Host B

NTAP 1 NTAP 2 NTAP 3

GSI GSI GSI

Group Services

MGRID NTAP Project

• Based on GARA: General-purpose Architecture for Reservation and Allocation

• GARA bandwidth reservation – Adds and removes configuration stanza's in network

hardware

– Includes scheduler for future reservations

• Security of communications and the ability to support roles is required

MGRID NTAP Project

• Added fine grained authorization

• Added signed group membership RSL payload

• Extended bandwidth reservation to be able to run arbitrary programs at a Grid service endpoint

• Designed to easily add functionality

• Network testing tools being run

– Iperf, traceroute, ping, owamp, etc

MGRID NTAP Architecture

Web Portal

Router 1

Host A

Router 2 Router 3

Host B

NTAP 1 NTAP 2 NTAP 3

GSI GSIGSI

Group Services

Local Domain

Cross-domain Authorization

• Implemented with Policy based software

• Policy engine makes authorization decision– Input <attribute name, value> are matched against

resource specific policy rules

– Input attribute names are matched to policy attribute names by a string compare

• Cross-domain attribute name space is therefore required

Cross-domain Authorization

• Attributes include– Group membership from group services

– Resource request parameters: bandwidth, number of CPU's, etc from RSL

– Environment parameters: time of day, CPU load, etc

• Use of existing local group services is required– U of M has 100,000+ active uniqnames to manage– Avoid replicating data and management tasks

Cross-domain Authorization

• Our first design in use today uses a modular group membership call-out and the KeyNote Policy Engine

• Group membership determined by– Secure RX call to AFS PTS

• Fine-grained authorization expressed in KeyNote policy rules

• Works across U of M campus

MGRID Architecture

mod ssl

mod kx509

mod kct

CHEF

Apache

Tomcat

KCT

GateKeeper

Service

Grid Service

KCA

Browser

kx509

libpkcs11

kinit

User Workstation

KDC

Kerberos V5

SSL – Client Certificate required

GSI

Kerberos

Kerberos

Grid-Mapfile

LDAPSASL

Web Server

1

2

3

4

5

6

7

6

Group Services

Resource MngAuthorization

8

mod jk

mod php

Authorization: Where?

• Earlier is better

• At the portal– RSL, group membership, and some

environment attributes available

– Can remove load from Grid Service

• At the Grid Service– Needed when policy has components that can

only be satisfied at end service

• Both (divided policy)

PERMIS

• Similar functionality to KeyNote

– Attributes and policy rules

• Follows XACML standard

• Signed policy stored in LDAP

• Signed user attributes stored in LDAP

– Current design requires new database of users

MGRID: Whats Next?

• Use XACML to exchange authorization data– XACML front end to existing UMICH group services

• Replace grid-mapfile with LDAP call out– Central administration

– Dynamic local cluster accounts

• Investigate NFSv4 as a grid file system

Summary

• Kx509, CHEF, and PERMIS (XACML) NMI components are being integrated and tested by MGRID

• We would like mod_kct and mod_kca to be considered for NMI-5

• Construction and management of a shared attribute name space is the largest problem facing cross-domain authorization

http://mgrid.umich.edu

Any Questions?