Using NMI Components in MGRID: A Campus Grid Infrastructure Andy Adamson Center 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 ( 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 Grid-Mapfile LDAP SASL Web Server Group Services Resource Mng Authorization 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 Grid-Mapfile LDAP SASL Web Server Group Services Resource Mng Authorization 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 2Router 3 Host B NTAP 1NTAP 2NTAP 3 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 2Router 3 Host B NTAP 1NTAP 2NTAP 3 GSI Group Services Local Domain

Cross-domain Authorization Implemented with Policy based software Policy engine makes authorization decision –Input 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 Grid-Mapfile LDAP SASL Web Server Group Services Resource Mng Authorization 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

Any Questions?