security design and solution in arc1 weizhong qiang university of oslo april 9, 2008
TRANSCRIPT
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!