Andy adamson center for information technology integration university of michigan usa
Download
1 / 25

Using NMI Components in MGRID: A Campus Grid Infrastructure - PowerPoint PPT Presentation


  • 65 Views
  • Uploaded on

Andy Adamson Center for Information Technology Integration University of Michigan, USA. Using NMI Components in MGRID: A Campus Grid Infrastructure. Outline. MGRID: Background and Motivation MGRID Architecture NTAP: A Grid Application Distributed Authorization Issues What's Next. MGRID.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Using NMI Components in MGRID: A Campus Grid Infrastructure' - nau


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Andy adamson center for information technology integration university of michigan usa

Andy Adamson

Center for Information Technology Integration

University of Michigan, USA

Using NMI Components in MGRID: A Campus Grid Infrastructure


Outline
Outline

  • MGRID: Background and Motivation

  • MGRID Architecture

  • NTAP: A Grid Application

  • Distributed Authorization Issues

  • What's Next


Mgrid
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
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
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
MGRID Architecture

Web Server

User Workstation

Apache

SSL – Client Certificate required

mod ssl

Browser

3

mod kct

libpkcs11

Kerberos V5

4

KCT

mod kx509

kx509

Kerberos

2

5

KCA

kinit

mod

jk

mod

php

Kerberos

KDC

1

6

Tomcat

GSI

Grid Service

LDAP

CHEF

6

SASL

Grid-Mapfile

GateKeeper

7

Resource Mng

Authorization

Group Services

Service

8


Mgrid portal
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 portal1
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 portal2
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 portal3
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 architecture1
MGRID Architecture

Web Server

User Workstation

Apache

SSL – Client Certificate required

mod ssl

Browser

3

mod kct

libpkcs11

Kerberos V5

4

KCT

mod kx509

kx509

Kerberos

2

5

KCA

kinit

mod

jk

mod

php

Kerberos

KDC

1

6

Tomcat

GSI

Grid Service

LDAP

CHEF

6

SASL

Grid-Mapfile

GateKeeper

7

Resource Mng

Authorization

Group Services

Service

8


Mgrid ntap project
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
MGRID NTAP Architecture

Host A

Host B

Router 1

Router 2

Router 3

Web Portal

GSI

GSI

GSI

NTAP 1

NTAP 2

NTAP 3

Group Services


Mgrid ntap project1
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 project2
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 architecture1
MGRID NTAP Architecture

Host A

Host B

Local Domain

Router 1

Router 2

Router 3

Web Portal

GSI

GSI

GSI

NTAP 1

NTAP 2

NTAP 3

Group Services


Cross domain authorization
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 authorization1
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 authorization2
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 architecture2
MGRID Architecture

Web Server

User Workstation

Apache

SSL – Client Certificate required

mod ssl

Browser

3

mod kct

libpkcs11

Kerberos V5

4

KCT

mod kx509

kx509

Kerberos

2

5

KCA

kinit

mod

jk

mod

php

Kerberos

KDC

1

6

Tomcat

GSI

Grid Service

LDAP

CHEF

6

SASL

Grid-Mapfile

GateKeeper

7

Resource Mng

Authorization

Group Services

Service

8


Authorization where
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
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
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
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


Any questions
Any Questions?

http://mgrid.umich.edu