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

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

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

Overview of internal structure of ARC1

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

HED architecture and security

Internal structure of HED FTPMCC HED

Configuration file /key.pem./cert.pem./ca.pem nobody POST GET /arex /echo sanjak /etc/arc.conf [ ] TCPMCC TLSMCC HTTPMCC SOAPMCC AREX Service Echo Service

Message flows and security plugins inside one MCC or service

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)

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

Proxy certificate profile Proxy certificate profile Proxy certificate profile (RFC3820) is supported by using openssls (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

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

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

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

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 Less complicated hierarchy

Arc specific policy /O=Grid/O=Test/CN=CA /vo.knowarc/usergroupA /O=Grid/OU=KnowARC/CN=XYZ urn:mace:shibboleth:examples subgrpexample1 file://home/test read stat list T20:30:20/P1Y1M normalcondition

Arc specific request expression /O=Grid/O=Test/CN=CA file://home/test read copy T20:30:20/P1Y1M

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

Delegation Scenario Scenario: ServiceA would delegate its File1s read/write right to a VOs 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 p read/write File1 –ServiceA says p read/write File1 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

Delegation Scenario with XACML Policy resource-id=File1 action-id=Read/Write delegate-attr=VOAdmin resource-id=File1 action-id=Read/Write group=ATLAS resource-id=File1 action-id=Read delegate-id= /O=UiO/CN=XYZ delegate-attr= VOAdmin T1<currentTime<T2

Delegation Scenario with XACML Request subject-id=/O=Lund/CN=ABC resource-id=File1 action-id=Read group=ATLAS subject-id=/O=Lund/CN=ABC resource-id=File1 action-id=Read group=ATLAS delegate-id= /O=UiO/CN=XYZ Evaluate against Policy2 and get the right Adminstrative request; Then evaluate against Policy1, and get the final result delegate-attr=VOAdmin

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)

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.

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

Thanks!