Java and Web Services Security in Action

Java and Web Services Security in Action

Marc Chanliau & Vikas Jain

Oracle

04/09/08 | Session Code: SOA-201

Agenda

The need for security in SOA environments“Define Once, Enforce Anywhere”

Paradigmatic Use CasesSOA EnvironmentsWeb Applications

Key industry standardsRequirementsDigital Security 101Transport-Level SecurityApplication-Level Security

Standard Security ImplementationsJava FrameworksMicrosoft WSE

Implementation choices

2

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)

3

Agenda






4

Use Case #1: SOA Application

5

ESB

BPEL Process

Receive Order

Get Customer Info

Verify Credit

Fulfill Order

Notify Customer

Web Client

Customer service

Credit Service

Notification Service

ESBDelivery Service

Use Case #1: Security Vulnerabilities

6

ESB Receive Order

Get Customer Info

Verify Credit

Notify Customer

Fulfill Order

Web Client

Customer service

Credit Service

Notification Service

ESBDelivery Service

: Security vulnerabilities

BPEL Process

Use Case #2: Web App. Invokes Web Service

7

Web Browser

ProcurementApplication

Corporate PortalPurchasing

Service

ShippingService

SSOToken

SAMLToken

KerberosToken

Identity PropagationEnd-to-End Security

SecurityToken

Service

Agenda






8

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

9

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)10

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. 11

Key Standard Security Frameworks

12

Transmission Control Protocol and Internet Protocol (TCP/IP)

Transport-Level Security: Secure Socket Layer (SSL)

Message Structure

Trust Management, Federation

Confidentiality, Integrity, Authenticity

XMLFrameworks

Non-XMLFrameworks

Transport Layer (HTTP, FTP, JMS, etc.)

Met

adat

a

Transport-Level Security and Digital Tokens

• Secure Socket Layer (SSL)• Digital Certificates• Kerberos

13

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

14

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.

15

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

16

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.

17

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

18

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

signed19

Message Structure, Message Security

20

• 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

SOAP Envelope Body

WS-Security Header

SecurityToken

Business Payload

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

21

SAML Architecture

22

AssertionsHow you define authentication & authorization information

ProtocolsHow you ask (Request) and get (Response) the assertions you need

BindingsHow SAML Protocols ride on industry-standard transport and messaging frameworks

ProfilesHow SAML Protocols and Bindings combine to support specific use cases

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>

23

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

24

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)

25

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)

26

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

27

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

28

Client Web Service (Endpoint)

Gateway

STS

WS-Trust Request

WS-Trust Response

Firewall

Web service request (SOAP/WS-Security/X.509) Web service request

(SOAP/WS-Security/SAML)

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

29

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

30

Metadata: WS-PolicyAttachment

• WS-PolicyAttachment defines how (WS-Policy) policies are attached to web services– Policies can be bound to WSDL or UDDI

31

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

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

32

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

33

Agenda






34

Java Technology Frameworks

• Java Platform, Enterprise Edition (Java EE platform) 5

• Apache / WSO2• Vendor specific (Oracle, IBM, BEA, etc.)

35

Java EE Platform 5

36

JCE/JCA

JSR 105 (RI) Apache XML-Security

XWS-Security

EncryptionSignature

WSIT

SAAJ

WS-Security and tokens

Key store, crypto operations

WS-SecurityPolicy, WS-Trust, WS-I-BSP

JAX-RPC, JAX-WS

Application (Web Service)

JAAS Authentication

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

Apache / WSO2

37

JCE/JCA

Apache XML-Security

Apache WSS4J

Signature (JSR 105), Encryption

Apache Rampart

MTOM / XOP

WS-Security and tokens


WS-SecurityPolicy, WS-Trust, etc.

Axis 2


JAAS Authentication

Axis 1.x

Attachments

Vendor Specific (e.g., Oracle 11g)

38

JCE/JCA

Oracle Security Developer Tools (OSDT)

Oracle Web Services Manager (OWSM)WS-Security and tokens, WS-I-BSP



OPS4J Authentication

JAX-RPC, JAX-WS, Axis 1.x, Axis 2

JAAS

XML Signature & Encryption

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

39

Agenda






40

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

41

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

42

Java and Web Services Security in Action

Documents

Transcript of Java and Web Services Security in Action