Security Design and Solution in Security Design and Solution in ARC1ARC1

Weizhong Qiang

University of Oslo

April 9, 2008

OutlineOutline

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 ARC1 (next generation Advanced Resource Connector)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 sol

utions, through web service interface and grid gateways

Overview of internal structure of Overview of internal structure of ARC1ARC1

HED (Host Environment HED (Host Environment Daemon)Daemon)

Web Service containerFunctionality: 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 securityHED architecture and security

Internal structure of HEDInternal structure of HED

FT

PM

CC

HED

Configuration fileConfiguration file <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>

TCPMCC

TLSMCC

HTTPMCC

SOAPMCC

AREX Service

Echo Service

Message flows and security plugins Message flows and security plugins inside one MCC or serviceinside one MCC or service

AuthenticationHandler

AuthorizationHandler

Decryption Handler

MCC (Message Chain Component)

EncryptionHandler

Main Process of MCC

Incoming Message (Request)

Outging Message (Request)

AuthenticationHandler

AuthorizationHandler

Decryption Handler

EncryptionHandler

Main Process of MCC

Incoming Message (Response)

Outgoing Message (Response)

Secure communicationSecure 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 OnAuthentication and Single Sign On

Bases on SSL/TLSFunctionality also in MCCTLSSupport proxy certificate, which means the Single sign on concept defined in Globus GSI can be supportedThe 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 profileProxy 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 SS

L session

AuthorizationAuthorization

PDP is available, which can parse a specific xml policy and request

PDP has been integrated into service

Policy schema, request schema

Authorization ArchitectureAuthorization 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 ArchitectureAuthorization 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 policyArc specific policy

Why do we propose a policy schema?Easy to manage; non-GUI is tolerantGeneral, expressive

The difference with XACMLSimilar but simplified schema:

• No <Apply> <Obligation> <AttributeDesignator > <AttributeSelector>

• Less complicated hierarchy

Arc specific policyArc 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>

Arc specific request expressionArc 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>

XACML and delegationXACML and delegation

XACML as a standard policy solution should be consideredXACML is more flexible for policy definitionXACML start to support delegation (XACML administrative and delegation profile, in draft XACML 3.0), which is one of the aims of ARC1Development is under process

Delegation ScenarioDelegation 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 p read/writ

e File1– ServiceA says p read/write File1 during [T1, T2] if p process VOAd

min

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

<Policy1>

Delegation ScenarioDelegation Scenario —with XACML Policy —with XACML Policy

<Target><Resource> resource-id=File1

<Action> action-id=Read/Write

<Delegate>

<Rule>

<Condition>

<Target> <Subject> delegate-attr=VOAdmin

<Resource> resource-id=File1

<Action> action-id=Read/Write

<Policy2>

<Target> <Subject> group=ATLAS

<Resource> resource-id=File1

<Action> action-id=Read

<PolicyIssuer> <Attribute>

<Rule> <Target>

<Condition>

delegate-id= /O=UiO/CN=XYZ

delegate-attr= VOAdmin

T1<currentTime<T2

Delegation ScenarioDelegation Scenario — with XACML Request — with XACML Request

<Request> <Subject> subject-id=/O=Lund/CN=ABC

<Resource> resource-id=File1

<Action> action-id=Read

group=ATLAS

<Request> <Subject> subject-id=/O=Lund/CN=ABC

<Resource> resource-id=File1

<Action> action-id=Read

group=ATLAS

<Delegate> 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 Issues about authorization delegation 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 “S

AML 2.0 profile of XACML v2.0”)

SAML (SAML (Security Assertion Markup Security Assertion Markup LanguageLanguage))

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 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!