Security Design and Solution in ARC1

1. Security Design and Solution in ARC1 Weizhong Qiang University of Oslo April 9, 2008

2. Outline • New generation Advanced Resource Connector (ARC1) • HED (Hosting Environment Daemon) • Security Design and Solution in ARC1 • Secure communication • Proxy certificate profile (RFC3820) and single sign on • Authorization • SAML • WS-Security

3. ARC1 (next generation Advanced Resource Connector) • Next generation ARC (Advanced Resource Connector) middleware which will provide these characteristics: • Portability: Web Service interface; compatibility to variety of popular operating system platforms • Simplicity: simple self-healing system which requires little effort to install and to use • Virtualization: on-demand job execution environments as well as virtual hosting • Interoperability: interoperability with other grid solutions, through web service interface and grid gateways

4. Overview of internal structure of ARC1

5. HED (Host Environment Daemon) • Web Service container • Functionality: • Message Chain Component, MCC • SOAP parsing (SOAPMCC) • HTTP processing (HTTPMCC) • TLS/SSL communication (TLSMCC) • TCP communication (TCPMCC) • Message Chain Components can be configured and dynamic loaded • Other utility functionality, such as logging, loading and configuration, etc. • API for Web Service development

6. HED architecture and security

7. FTPMCC HED Internal structure of HED

8. Configuration file TCPMCC <Chain> <Component name="tcp.service" id="tcp"> <next id="tls"/> <tcp:Listen><tcp:Port>60000</tcp:Port></tcp:Listen> </Component> <Component name="tls.service" id="tls"> <next id="http"/> <KeyPath>./key.pem</KeyPath> <CertificatePath>./cert.pem</CertificatePath> <CACertificatePath>./ca.pem</CACertificatePath> <SecHandler name="identity.map" id="map" event="incoming"> <PDP name="allow.pdp"><LocalName>nobody</LocalName></PDP> </SecHandler> </Component> <Component name="http.service" id="http"> <next id="soap">POST</next> <next id="plexer">GET</next> </Component> <Component name="soap.service" id="soap"> <next id="plexer"/> </Component> <Plexer name="plexer.service" id="plexer"> <next id="a-rex">/arex</next> <next id="echo">/echo</next> </Plexer> <Service name="a-rex" id="a-rex"> <arex:endpoint>https://localhost:60000/arex</arex:endpoint> <arex:usermap><arex:defaultLocalName>sanjak</arex:defaultLocalName></arex:usermap> <arex:gmconfig>/etc/arc.conf</arex:gmconfig> </Service> <Service name="echo" id="echo"> <echo:prefix>[ </echo:prefix> <echo:suffix> ]</echo:suffix> </Service> </Chain> TLSMCC HTTPMCC SOAPMCC AREX Service Echo Service

9. Message flows and security plugins inside one MCC or service

10. Secure communication • SSL v3/TLS v1 protocol has been supported to guarantee transport confidentiality and authentication • Functionality is in TLSMCC, which can be plugged into the message chain by using the configuration file (service.xml)

11. Authentication and Single Sign On • Bases on SSL/TLS • Functionality also in MCCTLS • Support proxy certificate, which means the Single sign on concept defined in Globus GSI can be supported • The current code can only be supposed to talk with GSI legacy services (like gridFTP service, VOMS service) if there is globus related packages installed (because the current ARC1 authentication protocol is only based on pure SSL/TLS protocol, not the authentication protocol defined in GSS-API) • Probably, the limitation will be removed by implement some GSSMCC which will cover the GSS-API functionality

12. Proxy certificate profile • Proxy certificate profile (RFC3820) is supported by using openssl’s (version>0.9.7g) proxy certificate support (“proxy cert info” extension generation, and certificate verification with “proxy cert info” extension) • Credential class (ArcLib) : • Can be used to: • Generate RFC3820 proxy certificate and Globus GSI legacy proxy certificate (pre-RFC) • Insert certificate extension, e.g. voms certificate (Globus GSI legacy certificate with voms attribute certificate as one extension) • No strict openssl version limitation • Not yet been used for certificate verification in SSL session

13. Authorization • PDP is available, which can parse a specific xml policy and request • PDP has been integrated into service • Policy schema, request schema

14. Incoming message Outgoing message PDP AA PEP Context Handler Service SecHandler Credential Attributes Marshaled formatted Authz request Authz Decision Policy Authorization Architecture AA: Attribute Authority, e.g. VOMS PEP: Policy Enforcement Point PDP: Policy Decision Point

15. Authorization Architecture • For authorization decision request, there could be two types of attributes: service/application independent attributes, like PeerDN, PeerIPAddress; service/application dependent attributes, like operation to service • Context Handler is supposed to be responsible for collecting and marshaling these attributes into formatted authorization request which will be sent to PDP

16. Arc specific policy • Why do we propose a policy schema? • Easy to manage; non-GUI is tolerant • General, expressive • The difference with XACML • Similar but simplified schema: • No <Apply> <Obligation> <AttributeDesignator > <AttributeSelector> • Less complicated hierarchy

17. Arc specific policy <Policy xmlns="http://www.nordugrid.org/ws/schemas/policy-arc" PolicyId="sm-example:policy1" CombiningAlg="Deny-Overrides"> <Rule RuleId="rule1" Effect="Permit"> <Subjects> <Subject Type=“x509Name"> /O=Grid/O=Test/CN=CA </Subject> <Subject Type=“IPAddress">127.0.0.1 </Subject> <Subject Type=“x500Name">/vo.knowarc/usergroupA</Subject> <Subject> <Attribute Type=“x500Name">/O=Grid/OU=KnowARC/CN=XYZ</Attribute> <Attribure Type=“MACE">urn:mace:shibboleth:examples</Attribute> </Subject> <GroupIdRef Location="./subjectgroup.xml">subgrpexample1</GroupIdRef> </Subjects> <Resources> <Resource Type=“URI">file://home/test</Resource> </Resources> <Actions Type="string"> <Action>read</Action> <Action>stat</Action> <Action>list</Action> </Actions> <Conditions> <Condition Type=“Period“ Function=“time-in-range”>2007-09-10T20:30:20/P1Y1M</Condition> <GroupIdRef Location="./conditiongroup.xml">normalcondition</GroupIdRef> </Conditions> </Rule> </Policy>

18. Arc specific request expression <Request xmlns="http://www.nordugrid.org/ws/schemas/request-arc"> <RequestItem> <Subject> <Attribute AttributeId="urn:arc:subject:ip " Type=" IPAddress ">127.0.0.1</Attribute> <Attribute AttributeId=" urn:arc:subject:dn" Type=“x500Name">/O=Grid/O=Test/CN=CA</Attribute> </Subject> <Resource AttributeId="urn:arc:resource:file" Type=“URI">file://home/test</Resource> <Action AttributeId="urn:arc:action:file-action" Type="string">read</Action> <Action AttributeId="urn:arc:action:file-action" Type="string">copy</Action> <Context AttributeId="urn:arc:context:date" Type=“Period">2007-09-10T20:30:20/P1Y1M</Context> </RequestItem> </Request>

19. XACML and delegation • XACML as a standard policy solution should be considered • XACML is more flexible for policy definition • XACML start to support delegation (XACML administrative and delegation profile, in draft XACML 3.0), which is one of the aims of ARC1 • Development is under process

20. Delegation Scenario • Scenario: • ServiceA would delegate its File1’s read/write right to a VO’s administrator which then can assign the right to identity which has ATLAS attribute. • Policy1: • ServiceA says p can say x read/write ServiceA.File1 if pread/writeFile1 • ServiceA says pread/writeFile1 during [T1, T2] if p process VOAdmin • The identity which has VOAdmin would assign the subset right to identity which has ATLAS attribute • Policy2: • /O=UiO/CN=XYZ says x read ServiceA.File1 if x process ATLAS • AA (Attribute Authority) says /O=UiO/CN=XYZ process VOAdmin

21. T1<currentTime<T2 delegate-attr=VOAdmin group=ATLAS <PolicyIssuer> <Target> <Rule> <Target> <Rule> <Target> <Action> <Action> <Resource> <Delegate> <Action> <Resource> <Resource> action-id=Read/Write resource-id=File1 resource-id=File1 action-id=Read resource-id=File1 action-id=Read/Write <Subject> <Subject> <Condition> <Attribute> <Target> <Condition> Delegation Scenario —with XACML Policy <Policy1> <Policy2> delegate-id= /O=UiO/CN=XYZ delegate-attr= VOAdmin

22. subject-id=/O=Lund/CN=ABC group=ATLAS subject-id=/O=Lund/CN=ABC <Request> <Resource> <Action> <Delegate> <Resource> <Action> resource-id=File1 action-id=Read action-id=Read delegate-id= /O=UiO/CN=XYZ delegate-attr=VOAdmin resource-id=File1 <Subject> <Subject> Delegation Scenario — with XACML Request <Request> group=ATLAS Evaluate against Policy2 and get the right “Adminstrative” request; Then evaluate against Policy1, and get the final result

23. Issues about authorization delegation • In a distributed delegation scenario, policies are distributed. • Collect all the relative policies together • When a service make authorization decision, it collects the policy from other trusted entities which assigns/delegates the delegated rights to the third entity. • Some secure transferring mechanism for authorization policy or authorization decision is required • Put them as X.509 certificate extension • Generate SAML assertion for them (need support for “SAML 2.0 profile of XACML v2.0”)

24. SAML (Security Assertion Markup Language) • SAML will be used to exchange authorization policy, authorization decision, attribute assertion, etc. • SAML 2.0 profile of XACML v2.0 • OGSA Attribute Exchange Profile • how a principal that possesses an X.509 public key certificate is represented as a SAML Subject • In terms of identity federation, provide “service provider” functionality, then hopefully the existing “Identity provider” can be used.

25. WS-Security • Username Token profile 1.1 is supported for HPC Basic Profile 1.0 (GDF.114) • HPC Basic Profile • TLS/SSL using X.509 certificate based mutual authentication • TLS/SSL with Username Password client authentication

26. Thanks!