Why do we need PGI The Nordu Grid ARC

Скачать презентацию Why do we need PGI The Nordu Grid ARC

5d55a04465485c8dff0569004941f08f.ppt

Количество слайдов: 47

OGF IPR Policies Apply • • • “I acknowledge that participation in this meeting is subject to the OGF Intellectual Property Policy. ” Intellectual Property Notices Note Well: All statements related to the activities of the OGF and addressed to the OGF are subject to all provisions of Appendix B of GFD-C. 1, which grants to the OGF and its participants certain licenses and rights in such statements. Such statements include verbal statements in OGF meetings, as well as written and electronic communications made at any time or place, which are addressed to: • • • the OGF plenary session, any OGF working group or portion thereof, the OGF Board of Directors, the GFSG, or any member thereof on behalf of the OGF, the ADCOM, or any member thereof on behalf of the ADCOM, any OGF mailing list, including any group list, or any other list functioning under OGF auspices, the OGF Editor or the document authoring and review process Statements made outside of a OGF meeting, mailing list or other function, that are clearly not intended to be input to an OGF activity, group or function, are not subject to these provisions. Excerpt from Appendix B of GFD-C. 1: ”Where the OGF knows of rights, or claimed rights, the OGF secretariat shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the GFSG of the relevant OGF document(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specification(s) under openly specified, reasonable, nondiscriminatory terms. The working group or research group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the OGF secretariat in this effort. The results of this procedure shall not affect advancement of document, except that the GFSG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the OGF Secretariat, and made available. The GFSG may also direct that a summary of the results be included in any GFD published containing the specification. ” OGF Intellectual Property Policies are adapted from the IETF Intellectual Property Policies that support the Internet Standards Process. © 2006 Open Grid Forum 2

ARC: a production Grid middleware • ARC provides reliable and efficient implementation of fundamental grid services (job execution, infosys, data, security layer) • Used in production since May 2001, middleware of choice of many large scale Grid deployments • Intensive development agenda driven by functionality and interoperability needs © 2006 Open Grid Forum 3

Capabilities and Standards • • Computing Data Information Security • Many standrads adopted and even more rejected • Standards conformance described in “Know. ARC Standards Conformance Roadmap” http: //www. knowarc. eu/documents/Knowarc_D 3. 3 -1_08. pdf © 2006 Open Grid Forum 4

Computing capability: status • Production ARC uses x. RSL and JSDL for job description • Development ARC uses JSDL – subset is used • Core JSDL • • Total. CPUTime, Individual. CPUTime Total. CPUCount, Individual. CPUCount Total. Physical. Memory, Individual. Physical. Memory Data. Staging © 2006 Open Grid Forum 5

Computing capability: status • ARC specific JSDL extensions • Is. Executable – attached to input files to specify if file should be executable • Run. Time. Environment – request for execution of job in predefined environment • Middleware – which middleware stack to use. Mostly usable for requesting specific version. • Remote. Logging – endpoint for reporting information about job. Used if user wants to report information to some project-specific database. • Processing. Start. Time – delay job processing till specified time. © 2006 Open Grid Forum 7

Computing capability: status • ARC specific JSDL extensions • Access. Control – GACL XML document describing who can manipulte job. Used for collaborative job management. • Notify – turns on e-mail notifications of job changes. • Session. Life. Time – how long job stays known in computing service after it finished. • Join. Outputs – merges stdout and stderr • Reruns – how many times job can be rerun after failure. Used rather for safety • Credential. Server – endpoint of service which provides credentials delegated by client, like My. Proxy. © 2006 Open Grid Forum 8

Computing capability: status • ARC implements BES and extends it • X. 509 credentials delegation • Direct access to activitie's working directory • Job state change operation • Additional job sub-states: • • • Preparing – data pre-staging Prepared – pre-staging finished Submiting – communication to batch system Executing – running in batch system Executed – execution in batch system finished • Finishing – data post-staging © 2006 Open Grid Forum 9

Computing capability: wishlist • ARC’s PGI wishlist: • Important activity states • Data staging • Activity suspension • Extra BES operations • Credentials delegation • State change on request • Runtime access to activity working directory • Extra functionality • Access control • Unified data staging © 2006 Open Grid Forum 10

Data capability: status • ARC supports numerous data related protocols in pluggable way • HTTP/HTTPS • FTP/Grid. FTP • LFC • LDAP • SRM • ARC Data Management System • New protcols are added by providing plugins with unified interface © 2006 Open Grid Forum 11

Data capability: wishlist • ARC’s PGI wishlist: • Definition of minimal set of required low level protocols - data transfer • Definition of minimal set of required higher level protocols – data management • More attention to non-Grid. FTP protocols • Profiling of complex protocols • E. g. if HTTP server should support parallel PUT operaions on same endpoint © 2006 Open Grid Forum 12

Information capability: status • Production ARC • LDAP server + Nordu. Grid own schema for presenting information about • Resources • Jobs • Users • LDAP servers with modified behavior for registering resources • Resources are registering to hierarchy of registration services • While looking for resources clients scan through hierarchy till actual resource is found • Each resource is queried for it's capabilities directly 13 • Clients know endpoints of top services of hierarchy © 2006 Open Grid Forum

Information capability: status • Development ARC • All services use unified interface • • WSRF interface GLUE 2 schema Authorization policies embedded Still under development • All services register to P 2 P cloud of registration services • ARC own interface • Minimal set of information can be assigned to registration record for preselection of services • Each clients knows at least one entry point to cloud © 2006 Open Grid Forum 14

Information capability: wishlist • Common information schema • Preferably GLUE 2 • Common way to publish information • Agreed interface to be used – BES? WSRF? • Agreed binding • Which part of GLUE 2 (if GLUE 2 is selected) • How to publish through selected interface • How to find/select the service • Minimal initial information • Solution suitable for multi-grid environment © 2006 Open Grid Forum 15

Security capability: status • Production ARC is based on X. 509 certificates • Uses DNs of X. 509 certificates and VOMS attributes for authorization decisions • Expandable using pluggable modules • LCAS support • LCMAPS support © 2006 Open Grid Forum 16

Security capability: status • Development ARC is fully modular. • Communication modules: • TLS/SSL • Information collection modules • X. 509 certificate properties • VOMS • WS-Security (selected functionality) • Username Token • X. 509 proxy restriction policy (ARC specific) © 2006 Open Grid Forum 17

Security capability: status • Information evaluation (authorization policies) • Simple DN lists • GACL • ARC specific policy language • XACML (work in progress) • Remote policy evaluation service • etc. © 2006 Open Grid Forum 18

Security capability: status • Credentials delegation for identity impersonation • X. 509 proxy with optional embedded policy (RFC 3820) • Delegation policy is enforced by services to limit access to resources • Delegation policy is part of critical extension – can't be used on services which do not support it • Unified (ARC specific) SOAP interface for accepting delegated credentials • Credentials delegation as part of service specific SOAP request © 2006 Open Grid Forum 19

Security capability: status • Services • Delegation service – stores credentials delegated by client • Short Life Certificate Service – converts Shibboleth token into X. 509 certificate • SAML 2 SSO service and user agent – uses Shibboleth Identity Provider for authenticating client © 2006 Open Grid Forum 20

Security capability: Wishlist • Defnition of supported delegation scenarios • For X. 509 proxies: • Supported proxy type • Way to embedd and process delegation restriction policies • Way to delegate proxies to services • For SAML tokens • SAML profiles and bindings for exchanging SAML tokens • For both • Definition of semantics for XML elements describing minimal set of objects, subjects, actions, etc. © 2006 Open Grid Forum 21

Security capability: Wishlist • Interoperability of delegation scenarios • Conversion of X. 509 proxies to SAML tokens • Technically easy • Information about internediate delegation actors is lost • Conversion of SAML Tokens to X. 509 proxies • Probably requires some service storing/producing delegated credentials © 2006 Open Grid Forum 22

Full Copyright Notice Copyright (C) Open Grid Forum (applicable years). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. The limited permissions granted above are perpetual and will not be revoked by the OGF or its successors or assignees. © 2006 Open Grid Forum 23

Security capability: state of the art • Security in ARC • Delegation • • Credential delegation in A-Rex Proxy certificate extension information Proxy client utility Compatibility about delegation in client utilities • Flexible access control © 2006 Open Grid Forum 25

Security capability: state of the art • Some other features implemented • Delegation Service • SAML 2 SSO profile • SLCS (short-lived credential service) service and client • WS-Security support © 2006 Open Grid Forum 26

Security in ARC Security functionalities (except those related to transport level security which functional as MCC) are provided as “handler” which can be plugged into and hosted by MCC/Service, e. g. WS-Security, Auth. Z Not-Change message: Authorization handler, etc. Change message: WS-Security handler, etc. Client side has similar architecture as service side © 2006 Open Grid Forum 27

Credential delegation in A-REX A-Rex client delegates X 509 credential to A-Rex service Message (SOAP) level delegation A-Rex service will then use the delegated credential to act on behalf of the delegator, e. g. do Grid. FTP operation such as globus-url-copy. Support for multiple-level delegation Convenient delegation Interface for extending to other service © 2006 Open Grid Forum 29

Credential delegation in A-REX deleg: Delegate. Credential. Init is provided as a specific SOAP operation Generated delegation token is provided as child of bes-factory: Create. Activity One delegation per-job Proxy certificate is identical to each job Proxy certificate complies to RFC 3820 © 2006 Open Grid Forum 31

Proxy certificate extension information Delegation policy Specified by credential delegator to restrict the usage (by delegatee) of this delegation credential Enforced by the service which consumes this delegation credential Delegation policy is in ARC specific format; Delegation policy is stored in extension part of proxy certificate © 2006 Open Grid Forum 32

Proxy certificate extension information VOMS Attribute VOMS ACs (Attribute Certificate) is verified on the service side Afterward, attributes is parsed and stored in session context, and could be used for making access control decision on different protocol levels, as well as different services (SOAP protocol level). © 2006 Open Grid Forum 33

Proxy client utility arcproxy: client utility for proxy generation Includes the functionality of grid-proxy-init, plus the embedding of delegation policy • Support RFC proxy Includes the functionality of contacting VOMS server, and generating proxy certificate with VOMS AC inside . /arcproxy --certificate=. /cert. pem --key=. /key. pem -trusted certdir=. /certificates --vomses=. /vomses -voms=knowarc. eu: /Role=my. Role --constraint proxy. Policy. File=policyfile © 2006 Open Grid Forum 34

Compatibility about delegation in client utilities Client utilities: arcsub, arcstat, arckill, etc. Client is compatible with different kinds service by recognize the prefix (ARC 0, ARC 1, CREAM) to service URL arcsub -c ARC 1: https: //localhost: 60000/arex job. jsdl Adapt to different delegation mechanisms from different types of services: ARC 0 <---> delegation based on GSI ARC 1 <--->delegation on SOAP level CREAM <---> delegation on SOAP level (CREAM delegation service) © 2006 Open Grid Forum 35

Flexible access control Policy support Gridmap-like policy GACL (Grid access control language) policy ARC policy Service level access control Collecting more requester's attributes (beside DN, voms attributes) for making decision © 2006 Open Grid Forum 36

SAML 2 SSO profile • An alternative for authentication and single sign on • Implement SAML 2 SSO profile • Service Provider • Client/User Agent • Utilize the Shibboleth Id. P for authentication • Make use of AAI (Authentication and Authorization Infrastructure) for Grid © 2006 Open Grid Forum 39

SAML 2 SSO profile • Some technical detail: • Username/password + TLS (non-client TLS) authentication • Client (API) which together with SP (service provider) service and Shibboleth Id. P, accomplish the SAML 2. 0 SSO profile • Each service container hosts one SP service and multiple general web services • SAML attributes returned by Id. P could be used for authorization on service side © 2006 Open Grid Forum 41

SLCS service and client • SLCS service acts as one specific ARC 1 service that is enhanced by the SAML 2. 0 SSO profile • SLCS service also acts as a CA that issues relatively short certificate • Utilize the community credential (Username/Password) to create short-lived X. 509 credential • Username/password ---> X. 509 Credential • The SAML assertion got from Id. P is put into certificate's extension part © 2006 Open Grid Forum 42

WS-Security • WS-Security implemented as “handler” • Username Token 1. 1 • X. 509 Token 1. 1 • SAML Token 1. 1 • Only self-signed token currently • Attribute Authority is needed for third-party issuing for SAMLToken • VOMS-SAML AA is an option (transport level authentication + SAML Attribute. Query profile) © 2006 Open Grid Forum 43

Some thinking about delegation profile for interoperability • Transport level delegation and authentication profile • Proxy certificate with VOMS AC and policy (format? ) extension • Required support: GSI support; basic RFC proxy certificate • Optional support: • Service side: delegation policy enforcement, AC verifying and parsing; those service without such support should just omit the cert extension. • Client side: delegation policy creation, AC insertion 44 © 2006 Open Grid Forum

Some thinking about delegation profile for interoperability • Message level delegation and authentication profile • SAML Token (be compatible with WSSecurity standard) with authentication assertion (required) attribute assertion (optional) • The way how to obtain SAML Token should not defined (could use others' work as reference: http: //xml. coverpages. org/Scavo. Ho. K-Motivation. html) © 2006 Open Grid Forum 45

Some thinking about delegation profile for interoperability • WS-Trust could be optional • Service side: optionally supports Secure WS -Addressing 1. 0 • Client side: optionally supports it. In ARC's side, it is at least possible to manually change the client configuration to use different authentication. © 2006 Open Grid Forum 46