RoleBased Access Control for Grid Database Services

1
Role-Based Access Control for Grid Database
Services

• Anil L. Pereira, Vineela Muppavarapu and Dr. Soon
  M. Chung
• Dept. of Computer Science and Engineering
• Wright State University
• Dayton, OH 45435

2
Contribution

• Objective
• - To provide efficient access control for
  heterogeneous databases across the Grid
• Method
• - A Role-based Access Control method for
  accessing databases across the Grid

3
Overview

• OGSA-DAI
• Community Authorization Service
• Our Proposed Role-based Access Control Method
• Implementation Details
• Performance Analysis
• Conclusion

4
OGSA-DAI
5
Open Grid Services Architecture Data Access and
Integration

• OGSA-DAI provides a grid-enabled implementation
  of interfaces and services to access and control
  data sources (relational and XML databases)
• Supports access to heterogeneous physical data
  resources through a common interface

6
OGSA-DAI

• Grid Data Service (GDS)
• A transient service which represents a client
  session with the data resource
• Grid Data Service Factory (GDSF)
• A persistent service which exposes a database
  resource and creates a GDS
• DAI Service Group Registry (DAISGR)
• A registry service which advertises the presence
  of GDSFs

7
Accessing a Data Resource through OGSA-DAI
ltltExposesgtgt
Grid Data Service Factory
DAISGR
3. Creates a GDS
2. Request for creation of a GDS
1. Gets the information about the GDSFs
registered
Grid Data Service
Client
4. JDBC Connection based on the mapping in role
map file
5. Queries and results submitted and received
using XML documents.
8
OGSA-DAI

• OGSA-DAI currently uses a role-map file to
  perform the mapping of the user to a local
  database account
• Example entry in a role-map file
• ltDatabase namejdbcmysql//130.108.17.1765432/
  ogsadaigt ltUser dnOGrid/OUGlobusTest/OUsimp
  leCA-motive.cs.wright.edu/OUcs.wright.edu/CNVine
  ela Muppavarapu useridogsadai
  passwordAaJd432RaNd /gt lt/Databasegt

9
Drawback with Current Authorization

• Substantial administration overhead for resource
  providers in Virtual Organizations (VOs)
• Both users and resources are dynamic in VOs
• Users and resource providers may belong to
  multiple VOs
• Multiple entries in multiple role-map files may
  need to be updated when access privileges change

10
Community Authorization Service
11
Community Authorization Service (CAS)

• A resource provider delegates a set of rights to
  the community server and the server is
  responsible for managing the fine-grain access
  control of the users within the community
• CAS grants rights on resources for usergroups
• For Example
• All users of userGroup1 have read right on
  ftp//130.108.17.176/globus/

12
Our Proposed Role-Based Access Control Method
13
Using Role-Based Access Control

• Access control decisions are based on roles
  possessed by individuals in an organization
• A role has certain permissions associated with it
  and users are granted memberships on roles
• When members join/leave an organization or their
  positions within it change, one only has to
  grant/revoke their membership on roles

14
Specifying VO Roles Using CAS

• The permission to access a resource is granted to
  the usergroup in the CAS server by denoting a
  service type and an action.
• The action describes the operation (e.g., read,
  write or execute program).
• The service type defines the namespace in which
  the action is defined (e.g., file).

15
Specifying VO Roles Using CAS Contd

• A method proposed by S. Cannon et al., represents
  a VO role as a resource and gives a usergroup
  group (service type) membership (action) on
  that role.
• The method further represents a VO role in the
  form VO name / Role name
• For Example
• Alpha/admin would represent the administrator
  role in project Alpha.

16
Drawback of the Method
user2
user1
user3
user1
userGroup1
userGroup2
read
membership
membership
read
ftp//localhost/tmp/fileB.txt
ftp//localhost/tmp/fileA.txt
Alpha/guest
Alpha/developer
UserGroup1 with membership on Role
Alpha/developer and read Access to
ftp//localhost/tmp/fileA.txt
UserGroup2 with membership on Role Alpha/guest
and read Access to ftp//localhost/tmp/fileB.txt
17
Our Proposed Method
user2
user1
user Group1
membership
privileges
Alpha/admin
dbadmin
VO Role
Local Role
18
Implementation of Our Method

• The client delegates a CAS credential instead of
  the normal proxy credential
• The server has been modified to recognize the CAS
  credential delegated by the client and obtain the
  role from the CAS extension
• Perform the mapping based on the role via the
  role-map file
• The role-map file has been extended to include
  the mapping from a role to a database username
  and password

19
Implementation Details
20
(No Transcript)
21
Accessing a Data Resource through OGSA-DAI using
a CAS Credential
ltltExposesgtgt
Grid Data Service Factory
4. Creates a GDS
DAISGR
3. Request for creation of a GDS
2. Gets the information about the GDSFs
registered
Grid Data Service
Client
1. Client makes assertions to CAS and receives
capability
5. JDBC Connection through mapping in role map
file based on the capability provided in the CAS
credential
6. Queries and results submitted and received
using XML documents.
CAS Server
22
CAS Extension
ltAuthorizationDecisionStatement Decision"permit"
Resource"roleNamespaceAlpha/admin"gt ltSubjectgt
.lt/Subjectgt ltAction Namespace"group"gtmembersh
iplt/Actiongt lt/AuthorizationDecisionStatementgt
Authorization Information Present in the CAS
Credential Specifying the Users VO Role
23
Modified OGSA-DAI

• Maps the VO roles to local accounts
• Example modified role-map file
• ltDatabase namejdbcmysql//130.108.17.1765432/o
  gsadaigt ltUser dnOGrid/OUGlobusTest/OUsimple
  CA-motive.cs.wright.edu/OUcs.wright.edu/CN
  Vineela Muppavarapu useridogsadai
  passwordAaJd432RaNd /gt
• ltUser dnOGrid/OUGlobusTest/OUsimpleCA-motive
  .cs.wright.edu/OUcs.wright.edu/CN Alpha/admin
  useridogsadai passwordAaJd432RaNd /gt
• lt/Databasegt

24
Typical User Session

• Initiate a User Proxy
• grid-proxy-init
• Your identity /OGrid/OUGlobusTest/OUsimpleCA-m
  otive.cs.wright.edu/OUcs.wright.edu/CNVineela
  Muppavarapu
• Enter GRID pass phrase for this identity
• Creating proxy... Done
• Your proxy is valid until Wed Mar 1 203053
  2005

25

• Initiate a CAS Proxy
• cas-proxy-init -c http//130.108.17.1768080/ogsa
  /services/base/cas/CASService -f
  /home/vinny3k/admin -t tag
• File admin with user specific request for CAS
  credential used above
• Resource roleNamespaceAlpha/admin group
  membership

26

• Contacting a specific GDSF using CAS
  capabilities
• java uk.org.ogsadai.client.Client -mls -t tag
  factory
• http//130.108.17.1768080/ogsa/services/ogsadai/S
  ecureGridDataServiceFactory examples/GDSPerform/JD
  BC/query/select1Row.xml

27
Perform Document

• The Perform document contains the query that has
  to be executed on the database

ltgridDataServicePerform xmlns"http//ogsadai.org.
uk/namespaces/2003/07/gds/types"
xmlnsxsi"http//www.w3.org/2001/XMLSchema-insta
nce" xsischemaLocation"http//ogsadai.org.uk/na
mespaces/2003/07/gds/types ../../../../schema/ogsa
dai/xsd/activities/activities.xsd"gt
ltdocumentationgt Performs a simple SELECT
statement. lt/documentationgt ltsqlQueryStatement
name"statement"gt ltexpressiongt select
from littleblackbook where id10
lt/expressiongt ltwebRowSetStream
name"statementOutput"/gt lt/sqlQueryStatementgt
lt/gridDataServicePerformgt
28
Performance Analysis
29
Performance Analysis

• Profiling Details
• Java method System.currentTimeMillis()
• Apache log4j logger
• Request made for a single row from a 10,000 row
  MySQL database table distributed with OGSA-DAI

30
System Configuration

• OGSA-DAI Release 4.0 was deployed on a Jakarta
  Tomcat 5.0.27/ Globus Toolkit 3.2.1 (GT3) stack
  running on a Linux machine with a 2.60 GHz Intel
  Pentium IV processor and 1 GB of RAM
• For more accuracy and to avoid caching tomcat has
  been shutdown and restarted before each run

31
Security Configurations on the Grid Data Services

• GDS enforcing GSI Secure Conversation with
  Signature (Signature)
• This enforces message integrity to be established
  between the client and server
• GDS enforcing GSI Secure Conversation with
  Encryption (Encryption)
• This enforces message privacy to be established
• GDS which does not enforce any security (None)
• The GDS does not provide a secure conversation

32
Client-side Security
33
Server-side Security
34
Security Overheads on the Server-side
35
Mapping and Database Connection
36
Conclusion

• CAS brings significant advantages to the
  authorization frame work of OGSA-DAI by
  supporting RBAC for multiple VOs.
• The number of entries to be managed in the
  role-map file is reduced dramatically
• When users join/leave a VO, CAS can grant/revoke
  their memberships on VO roles without involving
  the resource providers
• Resource providers can maintain ultimate
  authority over their resources by restricting
  access to specific users
• Performance analysis shows that very little
  overhead is added to the existing security
  infrastructure

37
Future Work

• Specifying privileges at the VO level to permit
  finer levels of granularity (such as operations
  on a specific table in a database) and to allow
  for role hierarchies
• Specifying timing constraints on roles at the VO
  level and enforcing them at the local level

38
Questions ?
39
Thank You