Java and Web Services Security in Action

1. Java and Web Services Security in Action Marc Chanliau & Vikas Jain Oracle 04/09/08 | Session Code: SOA-201

2. Agenda The need for security in SOA environments “Define Once, Enforce Anywhere” Paradigmatic Use Cases SOA Environments Web Applications Key industry standards Requirements Digital Security 101 Transport-Level Security Application-Level Security Standard Security Implementations Java Frameworks Microsoft WSE Implementation choices

3. The Need for Security in SOA Environments • Access to resources and services over HTTP (mainly) • Insecure port 80 • Readable messages (XML) - Message-level security required • Declarative security • No hard-coded security • Define security centrally • Policies are in a single point of control and administration • Enforce security locally • Policy enforcement points are distributed across the environment • Heterogeneous environments • Industry standards for integration and interoperability • Flexible deployment (multiple-platform support)

4. Agenda The need for security in SOA environments “Define Once, Enforce Anywhere” Paradigmatic Use Cases SOA Environments Web Applications Key industry standards Requirements Digital Security 101 Transport-Level Security Application-Level Security Standard Security Implementations Java Frameworks Microsoft WSE Implementation choices

5. Use Case #1: SOA Application BPEL Process Web Client ESB Receive Order Customer service Get Customer Info Credit Service Verify Credit Delivery Service ESB Fulfill Order Notification Service Notify Customer

6. Use Case #1: Security Vulnerabilities BPEL Process Web Client ESB Receive Order Customer service Get Customer Info Credit Service Verify Credit Delivery Service ESB Fulfill Order Notification Service Notify Customer : Security vulnerabilities

7. Use Case #2: Web App. Invokes Web Service SSO Token SAML Token Corporate Portal Purchasing Service Web Browser Procurement Application Security Token Service Kerberos Token Identity Propagation End-to-End Security Shipping Service

8. Agenda The need for security in SOA environments “Define Once, Enforce Anywhere” Paradigmatic Use Cases SOA Environments Web Applications Key industry standards Requirements Digital Security 101 Transport-Level Security Application-Level Security Standard Security Implementations Java Frameworks Microsoft WSE Implementation choices

9. Requirements • Authentication • Verify that the user is who she claims to be • Authorization - Access Control • Verify that the authenticated user has access rights to the service or resources invoked • Confidentiality • Hide whole or part of a document using encryption • Integrity, non repudiation • Have an authority digitally sign a document • Credential mediation • Exchange security tokens in a trusted environment • Service capabilities and constraints • Define what a service can do, under what circumstances

10. Digital Security 101 • Cryptography • From plaintext to ciphertext (encryption) and back (decryption) • Two parts: Algorithm, e.g., ADD, and Key, e.g., 3 • Secret-key cryptography • Uses identical (or symmetric) keys for encryption and decryption (e.g., Data Encryption Standard (DES), Triple DES, Advanced Encryption Standard (AES), Blowfish) • A message authentication code (MAC) can be added to a ciphertext to ensure that an encrypted message was not changed between sending and receiving (a MAC function computes a MAC from a message and a shared secret key) • Public-key cryptography • Uses different (or asymmetric) keys for encryption and decryption. Typically, the sender encrypts the message with the recipient's public key and the recipient decrypts the message with his private key (e.g., Rivest Shamir Adleman (RSA), Digital Signature Algorithm (DSA), Elliptic Curve Cryptography (ECC)) • Message Digest (or Hash) • Message “fingerprint” (i.e., a compressed representation of a message), faster to encrypt / sign (e.g., SHA-1, MD5)

11. PKCS • Public Key Cryptographic Standards (PKCS) specifications are submitted by RSA to various standards bodies and often become included in official standards (e.g., S/MIME, PKIX, SSL) • There are currently 12 PKCS specifications. The most common are: • PKCS#1 (RSA Cryptography Standard) provides a method for encrypting data using RSA public-key cryptography, defining RSA key generation, public-key syntax (used in certificates), private-key syntax (used in PKCS#8), encryption, decryption, and signature. • PKCS#5 (Password-Based Cryptography Standard) describes how to use a password and a random number to generate symmetric keys. • PKCS#7 (Cryptographic Message Syntax Standard) describes a general syntax (e.g., Certificate, CertificateRevocationList, etc.) for data that may have cryptography applied to it, such as digital signatures and digital envelopes. • PKCS#8 (Private-Key Information Syntax Standard) defines how to encode and decode private keys. • PKCS#10 (Certification Request Syntax Standard) defines the format of a certificate request to be sent to a CA (the CA uses PKCS#7 to return the certificate to the requester). • PKCS#11 (Cryptographic Token Interface Standard) defines the Cryptoki (cryptographic token interface) API to devices holding cryptographic information and performing cryptographic functions (in this context, a cryptographic token refers to a logical device). • PKCS#12 (Personal Information Exchange Syntax Standard) specifies a portable format for storing or transporting a user's private keys, certificates, and other cryptographic information.

12. Key Standard Security Frameworks Trust Management, Federation XML Frameworks Message Structure Metadata Confidentiality, Integrity, Authenticity Transport Layer (HTTP, FTP, JMS, etc.) Non-XML Frameworks Transport-Level Security: Secure Socket Layer (SSL) Transmission Control Protocol and Internet Protocol (TCP/IP)

13. Transport-Level Security and Digital Tokens • Secure Socket Layer (SSL) • Digital Certificates • Kerberos

14. Transport-Level Security: SSL • SSL is the most widely used transport-level data-communication protocol providing • Authentication (the communication is established between two trusted parties) • Confidentiality (the data exchanged is encrypted) • Message integrity (the data is checked for possible corruption) • Secure key exchange between client and server • SSL can be used in three modes: • No authentication: Neither the client nor the server authenticates itself to the other. No certificates are sent or exchanged. In this case, only confidentiality (encryption / decryption) is used. • One-way authentication (or server authentication): Only the server authenticates itself to the client. The server sends the client a certificate verifying that the server is authentic. • Two-way authentication (or bilateral authentication): Both client and server authenticate themselves to each other by sending certificates to each other. • SSL uses a combination of secret-key and public-key cryptography to secure communications • SSL traffic uses secret keys for encryption and decryption • The exchange of public keys is used for mutual authentication of the parties involved in the communication

15. X.509 Certificate • An X.509 digital certificate is a signed data structure designed to send a public key to a receiving party • A certificate includes standard fields such as certificate ID, issuer's DN, validity period, owner's DN, owner's public key, etc. • Certificates are issued by certificate authorities (CA) • A CA verifies an entity's identity and grants a certificate, signing it with the CA's private key. • The CA publishes its own certificate which includes its public key. • Each network entity has a list of the certificates of the CAs it trusts. Before communicating with another entity, a given entity uses this list to verify that the signature on the other entity's certificate is from a trusted CA.

16. Kerberos • Cross-platform authentication and single sign-on system • The Kerberos protocol provides mutual authentication between two entities relying on a shared secret (symmetric keys) • Terminology • Principal: an identity for a user (i.e., a user is assigned a principal), or an identity for an application offering Kerberos services • Realm: a Kerberos server environment; a Kerberos realm can be a domain name such as EXAMPLE.COM (by convention expressed in uppercase) • Components • Kerberos involves a client, a server, and a trusted party to mediate between them called the Key Distribution Center (KDC) • Each Kerberos realm has at least one KDC • KDCs come in different packages based on the operating platform used (for example, on Windows, the KDC is a domain service) • A Kerberos Token profile of WS-Security allows business partners to use Kerberos tokens in service-oriented architectures

17. Kerberos Process • A client (a user or an application server) that wants to use Kerberos authentication needs a Kerberos client package. When "kerberized" clients log in to their workstation, they can get a service ticket that they can reuse with other Kerberos resources without having to repeatedly log-in (single sign-on) • Typically, when a client wants to communicate with a server, the client sends a request to the KDC, and the KDC generates a session key allowing the client and the server to authenticate each other • The (kerberized) client logs on to a Kerberos realm using a password. • The password is hashed by the Kerberos server to produce the user's encryption key, which is compared by the KDC to the user's key stored in the Kerberos database. • If the comparison is successful, the Authentication Service of the KDC issues a ticket-granting ticket (TGT). • When the client needs to contact a server, it sends the TGT to the KDC. • The Ticket Granting Service of the KDC returns a session ticket to the client. • The client can now use the session ticket to access the server.

18. Application-Level Security (XML Frameworks) • Complements transport-level security (SSL) • Based on XML frameworks • Confidentiality, Integrity, Authenticity • XML Encryption, XML Signature • Message Structure, Message Security • SOAP, WS-Security / SAML • Message Delivery • WS-Addressing, WS-ReliableMessaging • Trust Management • WS-Trust • WS-SecureConversation • Metadata • WS-Policy, WS-SecurityPolicy, WS-PolicyAttachment • WS-MetadataExchange

19. Confidentiality, Integrity, Authenticity • XML Encryption (Data Confidentiality) • How digital content is encrypted and decrypted • How the encryption key information is passed to a recipient • How encrypted data is identified to facilitate decryption • XML Signature (Data Integrity, Authenticity) • Bind the sender’s identity (or “signing entity”) to an XML document • The document is signed using the sender’s private key • The signature is verified using the sender’s public key • Note: Signing / signature verification can be done using asymmetric or symmetric keys • Ensure non-repudiation of the signing entity • Proves that messages have not been altered since they were signed

20. Message Structure, Message Security • SOAP defines a protocol for exchanging XML messages between distributed peer processes • WS-Security defines how to attach XML Signature and XML Encryption headers to SOAP messages • WS-Security provides 6 profiles • Username (w/ opt. pwd digest) • X.509 cert • Kerberos ticket • SAML assertion • REL (Rights markup) document • SOAP with Attachments (SwA) SOAP Envelope SOAP Envelope Header WS-Security Header Security Token SOAP Envelope Body Business Payload

21. SAML • The Security Assertion Markup Language (SAML) is an open framework for sharing security information on the Internet through XML documents • SAML was designed to address the following: • Limitations of web browser cookies to a single domain: SAML provides a standard way to transfer cookies across multiple Internet domains • Proprietary web single sign-on (SSO): SAML provides a standard way to implement SSO within a single domain or across multiple domains • Federation: SAML facilitates identity management (e.g., account linking when a single user is known to multiple web sites under different identities) • Web Services Security: SAML provides a standard security token (a SAML assertion) that can be used with standard web services security frameworks (e.g., WS-Security, WS-Federation) • Identity propagation: SAML provides a standard way to represent a security token that can be passed across the multiple steps of a business process or transaction

22. SAML Architecture Assertions How you define authentication & authorization information Protocols How you ask (Request) and get (Response) the assertions you need Bindings How SAML Protocols ride on industry-standard transport and messaging frameworks Profiles How SAML Protocols and Bindings combine to support specific use cases

23. WS-Security With SAML Security Token • SAML assertions and references to assertion identifiers are contained in the <wsse:Security> element, which in turn is included in the <SOAP-ENV:Header> element (described in the WS-Security SAML Token Profile) <SOAP-ENV:Envelope> <SOAP-ENV:Header> <wsse:Security> <saml:Assertion> - - - </saml:Assertion> </wsse:Security> </SOAP-ENV:Header> <SOAP-ENV:Body> - - - </SOAP-ENV:Body> </SOAP-ENV:Envelope>

24. Message Delivery: WS-Addressing • SOAP does not provide a standard way to specify where a message is going or how responses or faults are returned • WS-Addressing provides an XML framework for identifying web services endpoints and for securing end-to-end endpoint identification in messages • A web service endpoint is a resource (such as an application or a processor) to which web services messages are sent • Example (wsa is the namespace for WS-Addressing) <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <S:Header> <wsa:MessageID> http://example.com/xyz-abcd-123 </wsa:MessageID> <wsa:ReplyTo> <wsa:Address>http://example.myClient1</wsa:Address> </wsa:ReplyTo> etc. • WS-Addressing is transport-independent, i.e., the request may be over JMS and the response over HTTP

25. Message Delivery: WS-ReliableMessaging • WS-ReliableMessaging (WS-RM), aka WS-ReliableExchange (its new OASIS moniker) defines a framework for identifying and managing the reliable delivery of messages between web services endpoints • WS-RM is predicated on the SOAP messaging structure (SOAP binding) and relies on WS-Security, WS-Policy, and WS-Addressing to provide reliable messaging • WS-RM provides the protocol that defines the steps (or "sequence") for reliable delivery of the message • WS-RM defines a reliable messaging (RM) source (the party that sends the message) and an RM destination (the party that receives the message)

26. Trust Management: WS-Trust • WS-Trust is an XML framework designed to enable applications to construct trusted SOAP message exchanges • Concepts • Trust • The characteristic that one entity is willing to rely on another entity to execute a set of actions and/or to make set of claims about a set of subjects • Claim • A statement made about a client or a service (e.g., name, identity, key, group, privilege, capability, etc.) • Security Token • A set of claims that can be signed (e.g., X.509 cert, Kerberos ticket, SAML assertion)

27. WS-Trust Focus • WS-Trust addresses situations where trust must be brokered between parties that don't use the same security tokens • A Security Token Service (STS) enables security token exchange, token issuance, and token validation • WS-Trust defines a request / response protocol • A client sends a RequestSecurityToken (RST) to the STS • The STS replies with a RequestSecurityTokenResponse (RSTR) • STS defines its security policies using WS-Policy/WS-SecurityPolicy • Policies are accessed using WS-MetadataExchange

28. WS-Trust Use Case • Premise: • No trust is established between the client and the service • The client only understands X.509 certs • The service only understands SAML Web Service (Endpoint) Client Gateway WS-Trust Response WS-Trust Request Web service request (SOAP/WS-Security/X.509) Web service request (SOAP/WS-Security/SAML) STS Firewall

29. Trust Management: WS-SecureConversation • WS-SecureConversation plays the same role in message-level security that SSL plays at the transport level • WS-SecureConversation defines the creation and sharing of security contexts between communicating parties • The <SecurityContextToken> (SCT) element supports the requirements of security contexts • An SCT involves a shared secret used to sign and/or encrypt messages • Derived keys are used for signing and encrypting messages associated with the security context • WS-SecureConversation defines how derived keys are computed and passed

30. Metadata: WS-Policy • WS-Policy enables one to specify policy information that can be used to access web services applications • A policy is expressed as one or more policy assertions • A policy assertion represents a capability or a requirement • For example, a policy assertion may stipulate that a request to a web service be encrypted, or a policy assertion can define the maximum message size that a web service can accept • The meaning of each assertion is specific to a particular domain, for example, security, reliability, or privacy

31. Metadata: WS-PolicyAttachment • WS-PolicyAttachment defines how (WS-Policy) policies are attached to web services • Policies can be bound to WSDL or UDDI <definitions> ... <binding name="StockQuoteWebServiceSoapBinding" ...> <wsp:PolicyReference xmlns:… URI="#SecureMessagePolicy"/> </binding> <wsp:Policy wsu:Id="SecureMessagePolicy"... > <sp:SignedParts> <sp:Body/> </sp:SignedParts> <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts> </wsp:Policy> ... </definitions>

32. Metadata: WS-SecurityPolicy • WS-SecurityPolicy defines a set of security policy assertions used in the context of the WS-Policy framework • WS-SecurityPolicy assertions describe how messages are secured on a communication path • WS-SecurityPolicy includes four categories of assertions • Policy assertion: an individual requirement, capability, other property, or a behavior (as defined in WS-Policy) • Security binding assertion: a policy assertion that identifies the type of security binding used to secure an exchange of messages (security binding is a set of properties that together provide enough information to secure a given message exchange) • Security binding property assertion: a policy assertion that specifies a particular value for a particular aspect of securing a message exchange • Token assertion: describes a token requirement (for example, a token can be a SAML assertion); token assertions defined within a security binding are used to satisfy protection requirements • WS-SecurityPolicy assertions are designed to represent the security characteristics defined in the WS-Security, WS-Trust, and WS-SecureConversation specifications

33. Metadata: WS-MetadataExchange • WS-MetadataExchange defines how a client can request the metadata it needs to access and communicate with a web service endpoint • Metadata can be WSDL, WS-Policy, schema • WS-MetadaExchange uses WS-Addressing to identify endpoints • WS-MetadaExchange works as follows: • A requester sends a GetMetadata request message to an endpoint • The endpoint replies with a GetMetadata response message including a reference to the metadata section requested • Note: Some vendors privilege WS-MetadaExchange over UDDI

34. Agenda The need for security in SOA environments “Define Once, Enforce Anywhere” Paradigmatic Use Cases SOA Environments Web Applications Key industry standards Requirements Digital Security 101 Transport-Level Security Application-Level Security Standard Security Implementations Java Frameworks Microsoft WSE Implementation choices

35. Java Technology Frameworks • Java Platform, Enterprise Edition (Java EE platform) 5 • Apache / WSO2 • Vendor specific (Oracle, IBM, BEA, etc.)

36. Java EE Platform 5 Application (Web Service) JAX-RPC, JAX-WS Authentication SAAJ JAAS WS-SecurityPolicy, WS-Trust, WS-I-BSP WSIT XWS-Security WS-Security and tokens JSR 105 (RI) Apache XML-Security Signature Encryption Key store, crypto operations JCE/JCA JAX-RPC = Java API for XML-based RPC | JAX-WS = Java APIs for XML Web ServicesJSR = Java Specification Request | SAAJ = The SOAP with Attachments API for Java JCE = Java Cryptography Extension | JCA = Java Cryptography Architecture

37. Apache / WSO2 Application (Web Service) Axis 1.x Axis 2 Authentication JAAS MTOM / XOP Attachments WS-SecurityPolicy, WS-Trust, etc. Apache Rampart Apache WSS4J WS-Security and tokens Signature (JSR 105), Encryption Apache XML-Security JCE/JCA Key store, crypto operations

38. Vendor Specific (e.g., Oracle 11g) Application (Web Service) JAX-RPC, JAX-WS, Axis 1.x, Axis 2 Authentication OPS4J JAAS Oracle Web Services Manager (OWSM) WS-Security and tokens, WS-I-BSP XML Signature & Encryption Oracle Security Developer Tools (OSDT) JCE/JCA Key store, crypto operations

39. Microsoft WSE • Web Services Enhancement (WSE 3.0) is a .NET framework security add-on to Visual Studio • WSE is a development tool that provides message-level security to SOA applications • WSE essentially implements security-centric WS-* specifications, such as WS-Security, WS-ReliableMessaging, WS-Addressing, WS-Policy, WS-Trust, WS-SecureConversation

40. Agenda The need for security in SOA environments “Define Once, Enforce Anywhere” Paradigmatic Use Cases SOA Environments Web Applications Key industry standards Requirements Digital Security 101 Transport-Level Security Application-Level Security Standard Security Implementations Java Frameworks Microsoft WSE Implementation choices

41. Application Server vs. External • Security can be implemented in the application server or external to the application server • Application Server security • Focused on a specific platform (Oracle, BEA, IBM, etc.) • External security (Oracle WSM, XML Appliances, etc.) • Defined in a single policy manager • Enforced across heterogeneous platforms • Deployment flexibility • Monitoring capabilities

42. Summary • SOA security is based on XML frameworks, Java technology standards, and Microsoft WSE in the .NET world only • Security includes authentication, access control, integrity, confidentiality, trust management • SOA security should be externalized for flexible deployment and easier administration