1 / 47

Outline

caGrid Security Architecture Version 0.5 caBIG Architecture Workspace Face to Face Georgetown University August 17, 2005 Stephen Langella Ohio State University langella@bmi.osu.edu. Outline. Security Architecture Components Grid Security Infrastructure (GSI) Authorization Manager

zorina
Download Presentation

Outline

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. caGrid Security Architecture Version 0.5caBIG Architecture Workspace Face to FaceGeorgetown UniversityAugust 17, 2005Stephen LangellaOhio State Universitylangella@bmi.osu.edu

  2. Outline • Security Architecture Components • Grid Security Infrastructure (GSI) • Authorization Manager • Grid User Management Service (GUMS) • caGrid Attribute Management Service (CAMS) • Future

  3. Security Architecture Components • Core Components • Grid Security Infrastructure (GSI) • Authorization Manager • Grid User Management Service (GUMS) • Attribute Management Service (CAMS) • External Components • Local Authentication/Authorization Systems • General Authorization Systems (ie PERMIS) • Grid Authorization Services • Future Components? • Grid Virtual Organization Service (GVOS)

  4. Grid Security Infrastructure (GSI) • Security Component of the Globus Toolkit • http://www.globus.org • Motivations • The need for secure communication (authenticated and perhaps confidential) between elements of a computational Grid. • The need to support security across organizational boundaries, thus prohibiting a centrally-managed security system. • The need to support "single sign-on" for users of the Grid, including delegation of credentials for computations that involve multiple resources and/or sites. • Usage in caGrid • Single Sign On / Authentication / Identification • Secure Communication • Delegation

  5. Grid Security Infrastructure (GSI) • Single Sign On • Certificates • Identifies Users and Services • Signed and certified by a Certificate Authority (CA) • Proxy • Short term certificate, signed by the user • Used as credentials, to authenticate to the grid. • Delegation • Allows services or users to act on another’s behalf.

  6. Grid Security Infrastructure (GSI) • Configuring Services to use GSI • Trusted Certificate Authorities • Allows the service to specify which CAs it trusts • Valid Users must have a certificate from a trusted CA • Service Credentials/Proxy • Specifies which user the service runs as. • Globus Security Descriptor • Allows the specification of authentication requirement on individual methods of a grid service. • Authorization Type • Needs to be configured if using globus authorization mechanisms

  7. Grid Security Infrastructure (GSI) • Configuring Trusted Certificate Authorities • Server Container (All Services) • Method 1 - Place trusted certificate in /etc/grid-security/certificates naming it with a .digit extension (e.g. trusted-cert.1) • Method 2 – Add the following parameter to the globusConfiguration block of the server-deploy.wsdd <parameter name="trustedCertificates" value="<CA certificate locations>"/> • Grid Service • Add the following parameter to the service block of the grid service’s server-deploy.wsdd <parameter name="trustedCertificates" value="<CA certificate locations>"/> • Client • Place trusted certificate in USER_HOME/.globus/certificates naming it with a .digit extension (e.g. trusted-cert.1)

  8. Grid Security Infrastructure (GSI) • Configuring Service Credentials/Proxy • Server Container (All Services) • Method 1 (Certificate) – Add the following parameter to the globusConfiguration block of the server-deploy.wsdd <parameter name=“containerCert" value="<certificate file>"/> <parameter name=“containerKey" value="<unencrypted key file>"/> • Method 2 (Proxy) – Add the following parameter to the globusConfiguration block of the server-deploy.wsdd <parameter name=“containerProxy" value="<proxy file>"/> • Grid Service • Method 1 (Certificate) – Add the following parameter to the service block of the grid service’s server-deploy.wsdd <parameter name=“serviceCert" value="<certificate file>"/> <parameter name=“serviceKey" value="<unencrypted key file>"/> • Method 2 (Proxy) – Add the following parameter to the service block of the grid service’s server-deploy.wsdd <parameter name=“serviceProxy" value="<proxy file>"/>

  9. Grid Security Infrastructure (GSI) • Configuring the Globus Security Descriptor • Allows the specification of authentication requirement on individual methods of a grid service. • Persistent Services - Add the following parameter to the service block of the grid service’s server-deploy.wsdd <parameter name="securityConfig" value="my-security-config.xml"/> • Transient Services - Add the following parameter to the service block of the grid service’s server-deploy.wsdd <parameter name="instance-securityConfig" value="my-security-config.xml"/> <securityConfig xmlns="http://www.globus.org" xmlns:ogsi="http://www.gridforum.org/namespaces/2003/03/OGSI"> <method name="ogsi:findServiceData" > <auth-method> <none/> </auth-method> </method> <method name="ogsi:subscribe" > <auth-method> <none/> </auth-method> </method> <!-- default auth-method for any other method --> <auth-method> <gsi/> </auth-method> </securityConfig>

  10. Grid Security Infrastructure (GSI) • Configuring Authorization Type • If using the grid map mechanism provided by globus, add the following parameter to the service’s server-deploy.wsdd • <parameter name="authorization" value=“gridmap"/> • If using AuthorizationManager mechanism , add the following parameter to the service’s server-deploy.wsdd • <parameter name="authorization" value=“none"/>

  11. Authorization Manager • Authorization Manager Overview • Extends the Globus Toolkit to provide more dynamic authorization • Abstracts away some globus related details. • A general interface in which a caGrid service calls to determine if a user is authorized to perform operation X on resource Y. public void authorize(Subject peerSubject, QName name, String resource) throws AuthorizationException • A caGrid service is configurable to use a specific implementation of the AuthorizationManager interface. • Authorization Managers can be used to integrate grid security with external authentication/authorization systems. • Local/Legacy systems • Other authorization systems. • Authorization Managers enable authorization in a diverse ever changing dynamic environment. • ie. Allow this user access from his work computer during work hours and from his home computer during non work hours.

  12. Authorization Manager Globus3.2.1 Integration • Globus 3.2.1 Authorization framework only supports gridmap for security. A gridmap is basically an ACL (Access Control List) that allows us to specify what users have access to a service (not method), which is not sufficient for our purposes. • Add Additional ServiceAuthorization implementation to SOAP Workflow (CABIGServiceAuthorization) • Creates callback to Authorization Manager implementation, specified in the caBIGAuthorizationManager service parameter (services, wsdd) • Maps Globus Authorization into calls into the Authorization Manager • Instantiates and Authorization Manager and calls into it. • Provides operations level authorization, Does NOT provide resource level authorization.

  13. Authorization Manager • Authorization Manager and Resource Level Authorization • Authorization Manager is obtained and called from the grid service implementation gov.nih.nci.cagrid.security.SecurityManager sm = gov.nih.nci.cagrid.security.SecurityManager.getInstance(); AuthorizationManager am = sm.getAuthorizationManager(); am.authorize(user,operation,resource); • Allows application specific decisions to be made on resources etc.

  14. Authorization Manager • Configuring a Service to use the Authorization Manager • Add SOAP handler to request flow in service’s wsdd <requestFlow> <handler type="java:gov.nih.nci.cagrid.security.handlers.CaBIGAuthorizationHandler“/> </requestFlow> • Creates callback to Authorization Manager implementation specified in service’s wsdd parameter : <parameter name="caBIGAuthorizationManager" value="gov.nih.nci.cagrid.security.UnPermissiveAuthorizationManager"/>

  15. Grid User Management Service (GUMS) • Grid Service for the management and creation of grid users and grid user credentials. • Features: • Configurable Registration System • Manages simpleCA Certificate Authority • Creates and Manages Accounts including Grid Credentials • In-depth Administrative System • Runs as a Secure Grid Service • Rich client API • GUMS Portal GUI

  16. Grid User Management Service Architecture • GUMS runs as a Globus Grid Service. • Grid Service implementation interacts with Server through in memory server API calls. • Uses globus simpleCA for Certificate generation and management. • Utilizes the Attribute Management Service (CAMS) to store required attributes. • MySQL is used for account persistence. • Requires an SMTP mail server for mailing user’s information regarding their account.

  17. Grid User Management Service Architecture • GUMS exposes the functionality of three sub interfaces. • Registration • User • Administration • Registration Interface • Provides methods for an anonymous person or service to request an account. • Communication between applicant and GUMS is secured with GSI message level encryption.

  18. Grid User Management Service Architecture • User Interface • Provides methods for a user to access their account. • Create/Get/Destroy Proxies • Manage Account Information • Communication between applicant and GUMS is secured with GSI message level encryption. • Requires a GUMS username and password or the user’s proxy

  19. Grid User Management Service Architecture • Administration Interface • Review Applications • Approve/Reject • Manager Users • Give/Revoke Privileges • Attach Notes • Review Notes • Manage Required Attributes • Define attributes that are required to register for an account. • Communication between applicant and GUMS is secured with GSI message level encryption. Requires a User Proxy, where the owner of the proxy is a GUMS administrator.

  20. Interacting with GUMS • Globus Client • GUMS can be interacted with through the Globus Client API • GUMS Client API • Rich API for interacting with GUMS, consist of three core classes. • GumsRegistrationClient – Implement Registration interface, provides operation for registering with GUMS. • GumsUserClient – Implements User Interface, provides method for performing user operations on GUMS (Create,Get,Destroy Proxy). • GumsAdministratorClient – Implements Administrative Interface, provides methods for administering GUMS.

  21. Interacting with GUMS • Command Line Tools (Uses Client API to allow command line functionality) • GridProxyInit – Creates and obtains a proxy for GUMS and stores it locally for use with other Grid Services. • GetGridProxy – Gets an already existing grid proxy on GUMS and stores it locally for use with other Grid Services. • GridProxyInfo – Gets information about a user’s existing grid proxy on GUMS. • GridProxyDestroy – Destroys the user’s proxy both on GUMS and locally. • GUMS Portal GUI • Graphical User Interface for interacting with GUMS. • Built using the GUMS Client API.

  22. Registering with GUMS • Registration requires users to supply information such that a decision can be made whether or not to give the user account. • Required Information • Information required by GUMS to logically operate. • Username • Password • Email • Required Attributes • Information required by an administrator or by the grid to validate the user. • Required Attributes can be defined and Configured by an administrator • Required Attributes are defined by XML schemas • Instances of required attributes are represented by XML documents. • Once a user sends their application to GUMS, GUMS will send them an email with the results of an administrators review of their application.

  23. Registering using the GUMS Portal • The registration screen contains fields for entering information required by GUMS and a table containing a list of attributes required for registration. From the table you can click to bring up a screen that will solicit the information for a required attribute.

  24. Using GUMS • Proxy Management • Create a Proxy – Allows the user to create a proxy for a user specified number of hours. • Requires a username and password • Proxy is created and store on the GUMS Server, a copy of the proxy is returned to the user. • Get a Proxy – Obtains an already create proxy from GUMS. • Requires a username and password • Get Proxy Information – Obtains information about a user’s proxy on the GUMS Server. • Requires a username and password or a proxy • Destroy Proxy – Destroys a users proxy on the GUMS Server. • Requires a username and password or a proxy

  25. Creating a Proxy Using the GUMS Portal • Creating a proxy requires a username, password, and number of hours. The result shows the information for the proxy created. • Executing other proxy management commands is similar.

  26. Illustrating the Client API - Creating a Proxy • Creating a proxy via the GUMS Client API //Create Basic Authentication Login BasicAuthCredential auth = new BasicAuthCredential(); auth.setUsername(“langella”); auth.setPassword(“password”); //Create a User Client Object and call createProxy() String service = http://localhost:8080/ogsa/services/cagrid/gums; GumsUserClient client = new GumsUserClient(service, auth); GlobusCredential proxy = client.createProxy(12);

  27. Administering GUMS • Application Management • Manage Required Information – Administrator can add and remove required attributes. This is done at GUMS Required Attributes must be specified by the applicant at registration time. • Attributes are defined in XML schemas • Attributes are represented by XML documents. • Schemas most be defined an stored in the Global Model Exchange (GME) • Get Applications – Provides an Administrator with methods for searching and obtaining applications. • Process Application – Allows Administrators to accept or reject a user’s application. • An email is sent to the user with the administrators decision along with any notes the administrator wanted to pass along to the user. • If the application is accepted an account is created on GUMS.

  28. GUMS Portal – Reviewing Applications

  29. Administering GUMS • User Management • Get Users - Provides a method for searching for users in the GUMS system. • Update User – Allows the administrator to make updates to a user account. • Revoke and grant access to the system. • Change a user’s role within the system. • Change a user’s password or email. • Can attach notes to a user’s account. • User Notes • Notes attached to a user that give insight to a user’s account. • Notes are automatically generated by the system whenever a user’s account is update. • Administrators can attach notes to a user’s account.

  30. GUMS Portal – Managing Users

  31. caGrid Attribute Management Service • Grid Service for the management of user/virtual organization attributes. • Attributes are well defined XML documents each conforming to and XML schema • Users/Services may request attributes of a given user or VO. • Requestor must be authorized to view the requested attributes. • Authorization Managers can use CAMS for requesting attributes for making dynamic decisions.

  32. CAMS Architecture • Runs as a Globus Grid Service • Grid Service implementation makes calls into the CAMS server API • CAMS uses Mobius Mako XML DB for storing attributes. • User attributes are organized into XML collections • An XML collection is created for each user. • Mako uses the Global Model Exchange to resolve XML schemas for validating attributes. • CAMS uses mysql to manage access control permissions on attributes.

  33. CAMS Architecture • CAMS has a well defined interface for exposing its functionality. • Implemented both by the client and server sides. • Communication between applicant and GUMS is secured with GSI message level encryption. • Operations • Adding Attributes • Removing Attributes • Obtaining Attributes By Owner • All • Type • XPath • By Instance or ID • Permissions • Methods for setting and revoking permissions on attributes • Methods for introspecting permissions on attributes.

  34. Interacting with CAMS • Globus Client • CAMS can be interacted with through the Globus Client API • CAMS Client API • Rich API for interacting with CAMS. • AttributeManagementClient • Complete implementation for invoking all CAMS operations. • CAMS Portal • Graphical User Interface for interacting with CAMS. • Uses CAMS Client API to invoke CAMS operations.

  35. CAMS - Adding Attributes • Required Input • Owner’s Grid Id. • XML Instance representing the attribute. • Schema for the attribute must exist and be registered to a GME • Grid Credentials of the submitter • Submission Requirements • Submitter must have write permissions for the attribute type being submitted.

  36. Finding/Browsing Attributes • CAMS supports multiple methods for obtaining attributes • Obtain all attributes for a given grid user. • Obtain all attributes of a given type for a given user. • Obtain all attributes that satisfy an XPath for a given user. • Obtain an attribute by its Attribute Identifier • Each attribute is given a unique id when it is submitted. • CAMS supports two retrieval policies. • Full attribute (get methods in client API) • Attribute Identifier (find method in client API).

  37. Obtaining All Attributes for a Given Grid User • Required Input • Owner’s Grid Id. • Grid Credentials of the submitter • Result of Query • All attributes for the owning grid user for which the submitting grid user has read access.

  38. Obtaining All Attributes of a given type for a Given Grid User • Required Input • Owner’s Grid Id. • Attribute Type • Namespace • Name • Grid Credentials of the submitter • Result of Query • All attributes of the specified type for the owning grid user that the submitting grid user has read access.

  39. Obtaining All Attributes for a Given Grid User that satisfy and XPath • Required Input • Owner’s Grid Id. • XPath • XPath Statement • Namespace Mappings • Grid Credentials of the submitter • Result of Query • All of the owners attributes satisfying the specified XPath and which the submitting grid user has read access.

  40. Managing Permissions • CAMS provides support for access control of attributes • Access Rights • Read Access (Finding/Obtaining Attributes) • Write Access (Adding and Deleting Attributes) • Admin Access (Setting Permissions) • Permissions • Each user has a set of permissions associated with their account. • A permission specifies access writes for a given user on a given attribute type (namespace, name). • Wildcards Supported

  41. Managing Permissions • Conflicting Permissions • Wildcards make managing permission easier and less complex. • Wildcards introduce conflicts • Permission Priorities • Resolve Permission Conflicts • If a higher priority permission exists it is always used.

  42. Setting Permissions • Required Input • Grid Id of user to whose account permission is being applied to. • Attribute Type • Namespace • Name • Access Rights • List of user’s that should be granted this permission • Result of Query • Permission is applied to the user’s account if the submitter has admin access.

  43. Browsing/Query/Editing/Revoking Permissions

  44. Illustrating the Client API – Obtaining a Attribute • Obtaining an Attribute using the CAMS Client API String service = http://localhost:8080/ogsa/services/cagrid/cams; AttributeManagementClient client = new AttributeManagementClient(new URL(service)); AttributeDescriptor des = new AttributeDescriptor() des.setNamespace(namespace);des.setName(name) Attribute[] atts = client.getAttributes(owner,des);

  45. Grid Virtual Organization Service (GVOS) • Manages a set of virtual organizations. • Administrators can create Virtual Organizations • Virtual Organization consist of users and other Virtual Organizations • Users which are members of a VO can request a proxy for the VO. • Users/Services can enquire whether or not a user is a member of a VO.

  46. Big Picture

  47. Future • Grid User Management Service (GUMS) • Add support for user life time issues (Expiring Credentials, etc.) • Add operation to the grid interface for managing required information? • Add operation to the grid interface for being able to obtain the CA’s certificate? • Extend functionality to support management of host certificates? • Add support for multiple CA type, currently only supports simpleCA. • caGrid Attribute Management Service (CAMS) • Evaluation of existing attribute/transmission technologies. • Support for user account management • Virtual Organization • Add Support to the security infrastructure for virtual organizations.

More Related