1. © 2006 Open Grid Forum Why do we need PGI? The NorduGrid/ARC perspective Aleksandr Konstantinov, Balazs Konya, Weizhong Qiang, on behalf of the NorduGrid Collaboration

2. © 2006 Open Grid Forum 2 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 specific specification(s) under openly specified, reasonable, non- discriminatory 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.

3. © 2006 Open Grid Forum 3 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

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

5. © 2006 Open Grid Forum 5 Computing capability: status Production ARC uses xRSL and JSDL for job description Development ARC uses JSDL – subset is used Core JSDL TotalCPUTime, IndividualCPUTime TotalCPUCount, IndividualCPUCount TotalPhysicalMemory, IndividualPhysicalMemory DataStaging

6. © 2006 Open Grid Forum 6 Computing capability: status POSIX JSDL Executable, Argument CPUTimeLimit WallTimeLimit MemoryLimit Input, Output, Error

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

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

9. © 2006 Open Grid Forum 9 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

10. © 2006 Open Grid Forum 10 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

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

12. © 2006 Open Grid Forum 12 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-GridFTP protocols Profiling of complex protocols E.g. if HTTP server should support parallel PUT operaions on same endpoint

13. © 2006 Open Grid Forum 13 Information capability: status Production ARC LDAP server + NorduGrid 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 Clients know endpoints of top services of hierarchy

14. © 2006 Open Grid Forum 14 Information capability: status Development ARC All services use unified interface WSRF interface GLUE2 schema Authorization policies embedded Still under development All services register to P2P 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

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

16. © 2006 Open Grid Forum 16 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

17. © 2006 Open Grid Forum 17 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 Token X.509 proxy restriction policy (ARC specific)

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

19. © 2006 Open Grid Forum 19 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

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

21. © 2006 Open Grid Forum 21 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.

22. © 2006 Open Grid Forum 22 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

23. © 2006 Open Grid Forum 23 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.

24. © 2006 Open Grid Forum 24 Weizhong's slides

25. © 2006 Open Grid Forum 25 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

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

27. © 2006 Open Grid Forum 27 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, AuthZ  Not-Change message: Authorization handler, etc.  Change message: WS-Security handler,etc. Client side has similar architecture as service side

28. © 2006 Open Grid Forum 28 Security in ARC 22/1/2009

29. © 2006 Open Grid Forum 29 Credential delegation in A-REX A-Rex client delegates X509 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 GridFTP operation such as globus-url-copy. Support for multiple-level delegation Convenient delegation Interface for extending to other service

30. © 2006 Open Grid Forum 30

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

32. © 2006 Open Grid Forum 32 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

33. © 2006 Open Grid Forum 33 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).

34. © 2006 Open Grid Forum 34 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=myRole --constraint proxyPolicyFile=policyfile

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

36. © 2006 Open Grid Forum 36 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

37. © 2006 Open Grid Forum 37 Delegation service A dedicated web service for delegation Can be configured as “hanlder” of ARC client and service Multiple-level delegation support

38. © 2006 Open Grid Forum 38

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

40. © 2006 Open Grid Forum 40

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

42. © 2006 Open Grid Forum 42 SLCS service and client SLCS service acts as one specific ARC1 service that is enhanced by the SAML2.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 IdP is put into certificate's extension part

43. © 2006 Open Grid Forum 43 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 AttributeQuery profile)‏

44. © 2006 Open Grid Forum 44 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

45. © 2006 Open Grid Forum 45 Some thinking about delegation profile for interoperability Message level delegation and authentication profile SAML Token (be compatible with WS- Security 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- HoK-Motivation.html)‏

46. © 2006 Open Grid Forum 46 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.

47. © 2006 Open Grid Forum 47