1 / 25

OGSA Security Profile 2.0 (a.k.a. “Express Authentication Profile)

OGSA Security Profile 2.0 (a.k.a. “Express Authentication Profile). DUANE MERRILL October 18, 2007. Presentation Overview. Goals & non-goals of the OGSA-SP 2.0 Motivation Secure Addressing Secure Transport Secure SOAP Questions. OGSA Security Profile 2.0.

alyssa
Download Presentation

OGSA Security Profile 2.0 (a.k.a. “Express Authentication Profile)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OGSA Security Profile 2.0(a.k.a. “Express Authentication Profile) DUANE MERRILL October 18, 2007

  2. Presentation Overview • Goals & non-goals of the OGSA-SP 2.0 • Motivation • Secure Addressing • Secure Transport • Secure SOAP • Questions

  3. OGSA Security Profile 2.0 (A.K.A “Express Authentication Profile”) GOALS • Profile how to convey secure-communication requirements within EPRs • Define well-known, composable security policies for common security mechanisms • Provide minor mechanism clarifications and refinements as security mechanisms are adapted to Grid • Establish trustworthiness of EPRs (e.g., tamper-resistance via digital signature)

  4. Intent IS TO: • Enable discovery of common security mechanisms • Or cleanly identify when interoperability is not possible • Easily be extended to accommodate new mechanisms, credentials, etc. IS NOT TO: • Impose common security mechanisms • Invent new security mechanisms • Invent new languages for describing security mechanisms

  5. Motivation SECURITY: • A system’s ability to protect its assets • Disclosure or theft of resources • Modification (including destruction) of resources • Resource service interruption • Crucial for OGSA/Grid adoption • Participants require protection from undue risk • Participants must meet legal requirements

  6. First Steps: Protocol Interoperability • SOA Philosophy • Presume nothing regarding service implementation • Message format and endpoints are public knowledge • Security mechanisms affect message format • “What do I have to do to my messages to communicate?” • Message payloads defined by well-known, static service interfaces • Diverse (and possibly dynamic) security action requirements for messages

  7. Diverse Security Requirements • Credential requirements • Users & resources tied to existing credential infrastructures • (e.g., Kerberos, X.509 PKI, SAML, etc.) • No “lowest common denominator” • OGSA security model tasked with integration of these trust and security domains • Security action requirements • Grid applications created via service composition • Application-specific security requirements imposed on component services • E.g., ByteIO resources may have confidentiality requirements in some cases, not others

  8. Why another mechanism for security requirement discovery? • Attachment of WS-SecurityPolicy requirements to WSDL and UDDI • WS-I Conformance Claim Attachment Mechanism to WSDL • "http://ogf.org/profiles/hpc-basic/1.0/username-token" • Issues: • WSDL not always fine-grained enough • WSDL not always published • Non-standardized conventions for locating WSDL • Scope limited to interface/application

  9. Why another mechanism for security requirement discovery? (Continued) • CaGrid exposes requirements through reflective service operations • getSecurityMetadata() • Chicken-before-egg problem • Extra communication required • Liberty exposes requirements within EPRs • “urn:liberty:security:2006-08:ClientTLS:SAMLV2” • Not as expressive as WS-SecurityPolicy • No means to communicate individual integrity/confidentiality requirements

  10. Why EPRs? • Grid utility is derived from the composition (often dynamic) of services • EPRs extensively incorporated into core service interfaces, e.g.: • Notification (WS-Eventing) • Execution management (BES activity creation) • Directory services (RNS) • EPRs are how services refer and address each other • EPRs serve as invocation contexts: “Everything one needs to know to for communication”

  11. OGSA SP 2.0 Document Architecture • Multiple documents composed in a hierarchical, extensible fashion.  • OGSA-BSP Secure Addressing • Defines the general WS-SecurityPolicy attachment mechanism to EPRs • Profile EPR digital signature • OGSA-SP Secure Transport • Defines well-known policies for de-facto transport-level secure communication configurations. • OGSA-SP Secure SOAP Messaging • Defines analogous policies for de-facto message-level security mechanisms

  12. Secure Addressing Idea: • Apply WS-SecurityPolicy to the extensible <wsa:Metadata> portion of the EPR WS-SecurityPolicy: • Extension to WS-Policy framework • New OASIS standard • Grammar for asserting token types, cryptographic algorithms and mechanisms, including using transport level security

  13. <wsa:Metadata> … <!-- This policy attachment applies to all actions on this endpoint --> <wsp:PolicyAttachment> <wsp:AppliesTo> <wsp:URI>urn:soapaction:*</wsp:URI> </wsp:AppliesTo> <!-- Collection of policy alternatives --> <wsp:Policy> <wsp:ExactlyOne> <!-- Alternative 1: Server-auth TLS + Username-token --> <wsp:All> <wsp:PolicyReference>http://…#CertifiedServerTLS</wsp:PolicyReference> <wsp:PolicyReference>http://...#UsernameToken</wsp:PolicyReference> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> </wsp:PolicyAttachment> … <wsa:Metadata>

  14. Secure Addressing Con’t (Optional) Digital signing of EPRs: • Extend WS-Addressing to profile a <ds:Signature> element as a child of the <wsa:EndpointReference> document • Such a signature MUST cover the following elements: • <wsa:Address> • <wsa:ReferenceParameters> • <wsa:Metadata>

  15. Secure Transport • Defines secure transport bindings to be referenced by name: • Server-authenticated TLS w/ Server Certificate • Server-authenticated TLS w/o Server Certificate • Mutually-authenticated TLS w/ Sever Certificate • Mutually-authenticated TLS w/o Sever Certificate • If the Server Certificate is present, the Profile mandates hostname verification as per RFC 2818 – HTTP over TLS • TLS/SSL algorithm suites are restricted to those listed in WS-SecurityPolicy

  16. <wsp:Policy wsu:Id=”ServerTLS”> <sp:TransportBinding> <wsp:Policy> <sp:TransportToken> <wsp:Policy> <sp:HttpsToken /> </wsp:Policy> </sp:TransportToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256 /> </wsp:Policy> </sp:AlgorithmSuite> </wsp:Policy> </sp:TransportBinding> </wsp:Policy> TLS_RSA_WITH_AES_256_CBC_SHA SSL_RSA_WITH_AES_256_CBC_SHA <wsp:Policy wsu:Id=”MutualTLS”> <sp:TransportBinding> <wsp:Policy> <sp:TransportToken> <wsp:Policy> <sp:HttpsToken> <wsp:Policy> <sp:RequireClientCertificate /> </wsp:Policy> </sp:HttpsToken> </wsp:Policy> </sp:TransportToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256 /> </wsp:Policy> </sp:AlgorithmSuite> </wsp:Policy> </sp:TransportBinding> </wsp:Policy> Server-authenticated TLS w/o Server Cert Policy Mutually-authenticated TLS w/o Server Cert Policy

  17. Back to Secure Addressing • EPRs may also need to perform key distribution: • Extra hostname-verification at the transport-level • Message-level encryption • Want to embed tokens directly into the EPR, yet WS-SecurityPolicy does not provide for this • Token assertions may contain a <wsp:issuer> element to indicate the EPR of a location from which to obtain a token • Solution: extend WS-SecPol’s token assertions to optionally contain an alternative <wsse:SecurityTokenReference> • We can put embedded tokens in <wsse:SecurityTokenReference> tags within the <wsa:Metadata> document

  18. <wsp:Policy wsu:Id=”ServerTLS”> <sp:TransportBinding> <wsp:Policy> <sp:TransportToken> <wsp:Policy> <sp:HttpsToken> <wsse:SecurityTokenReference> <wsse:Reference URI='#RecipientTransportIdentity' ValueType="http://docs.oasis-open.org/...#X509v3" /> </wsse:SecurityTokenReference> </sp:HttpsToken> </wsp:Policy> </sp:TransportToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256 /> </wsp:Policy> </sp:AlgorithmSuite> </wsp:Policy> </sp:TransportBinding> </wsp:Policy> Server-authenticated TLS w/ Server Cert Policy

  19. Secure SOAP • Defines common secure message-level bindings to be referenced by name: • Username-token (simple) • Password-digest username-token (digest of password, timestamp, and nonce) • X.509 Mutual authentication

  20. <wsp:Policy wsu:Id=”PasswordDigest” <sp:SupportingTokens> <wsp:Policy> <sp:UsernameToken> <wsp:Policy> <sp:HashPassword/> </wsp:Policy> </sp:UsernameToken> </wsp:Policy> </sp:SupportingTokens> </wsp:Policy> <wsp:Policy wsu:Id=”UsernameToken” <sp:SupportingTokens> <wsp:Policy> <sp:UsernameToken/> </wsp:Policy> </sp:SupportingTokens> </wsp:Policy> Username-Token Policy Password-Digest Policy

  21. (01) <wsp:Policy wsu:Id=”MutualX509”> (02) <sp:AsymmetricBinding> (03) <wsp:Policy> (04) <sp:InitiatorToken> (05) <wsp:Policy> (06) <sp:X509Token sp:IncludeToken="http://.../AlwaysToRecipient"> (07) <wsp:Policy> (08) <wsp:ExactlyOne> (09) <wsp:All> (10) <sp:WssX509V3Token11/> (11) </wsp:All> (12) <wsp:All> (13) <sp:WssX509PkiPathV1Token11/> (14) </wsp:All> (15) <wsp:All> (16) <sp:WssX509Pkcs7Token11/> (17) </wsp:All> (18) </wsp:ExactlyOne> (19) </wsp:Policy> (20) </sp:X509Token> (21) </wsp:Policy> (22) </sp:InitiatorToken> … Mutually-Authenticated X.509 Policy

  22. … (23) <sp:RecipientToken> (24) <wsp:Policy> (25) <wsp:ExactlyOne> (26) <wsp:All> (27) <sp:X509Token sp:IncludeToken="http://.../IncludeToken/Never> (28) <wsse:SecurityTokenReference> (29) <wsse:Reference URI='#RecipientMessageIdentity‘ ValueType="http://...wss-x509-token-profile-1.0#X509v3"/> (30) </wsse:SecurityTokenReference> (31) <wsp:Policy> (32) <sp:WssX509V3Token11/> (33) </wsp:Policy> (34) </sp:X509Token> (35) </wsp:All> … Mutually-Authenticated X.509 Policy

  23. … (74) <wsp:Policy wsu:Id=”RequestPolicy”> (75) <sp:SignedParts> (76) <sp:Body/> (77) <Header namespace="http://www.w3.org/2005/08/addressing"/> (78) </sp:SignedParts> (79) <sp:SignedElements> (80) <sp:XPath/> (81) /Envelope/Header/*[@isReferenceParameter="true"]' (82) </sp:XPath> (83) </sp:SignedElements> (84) </wsp:Policy> (85) (86) <wsp:Policy wsu:Id=”ResponsePolicy”> (87) <sp:SignedParts> (88) <sp:Body/> (89) </sp:SignedParts> (90) </wsp:Policy> (91) (92) </wsp:Policy> Mutually-Authenticated X.509 Policy

  24. Specifying Additional Protection Policy ... <wsp:Policy> <wsp:All> <wsp:PolicyReference> http://www.ggf.org/ogsa/2007/05/sp-secure-soap#MutualX509 </wsp:PolicyReference> <wsp:Policy wsu:Id=”SupplementalInputPolicy”> <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts> </wsp:Policy> <wsp:Policy wsu:Id=”SupplementalOutputPolicy”> <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts> </wsp:Policy> </wsp:All> </wsp:Policy> • ...

  25. Questions

More Related