Java and web services security in action
1 / 42

Java and Web Services Security in Action - PowerPoint PPT Presentation

  • Uploaded on

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 Cases SOA Environments Web Applications Key industry standards Requirements

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Java and Web Services Security in Action' - maude

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Java and web services security in action

Java and Web Services Security in Action

Marc Chanliau & Vikas Jain


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


The need for security in SOA environments

“Define Once, Enforce Anywhere”

Paradigmatic Use Cases

SOA Environments

Web Applications

Key industry standards


Digital Security 101

Transport-Level Security

Application-Level Security

Standard Security Implementations

Java Frameworks

Microsoft WSE

Implementation choices

The need for security in soa environments
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)


The need for security in SOA environments

“Define Once, Enforce Anywhere”

Paradigmatic Use Cases

SOA Environments

Web Applications

Key industry standards


Digital Security 101

Transport-Level Security

Application-Level Security

Standard Security Implementations

Java Frameworks

Microsoft WSE

Implementation choices

Use case 1 soa application
Use Case #1: SOA Application

BPEL Process

Web Client


Receive Order

Customer service

Get Customer Info

Credit Service

Verify Credit

Delivery Service


Fulfill Order

Notification Service

Notify Customer

Use case 1 security vulnerabilities
Use Case #1: Security Vulnerabilities

BPEL Process

Web Client


Receive Order

Customer service

Get Customer Info

Credit Service

Verify Credit

Delivery Service


Fulfill Order

Notification Service

Notify Customer

: Security vulnerabilities

Use case 2 web app invokes web service
Use Case #2: Web App. Invokes Web Service





Corporate Portal



Web Browser








Identity Propagation

End-to-End Security




The need for security in SOA environments

“Define Once, Enforce Anywhere”

Paradigmatic Use Cases

SOA Environments

Web Applications

Key industry standards


Digital Security 101

Transport-Level Security

Application-Level Security

Standard Security Implementations

Java Frameworks

Microsoft WSE

Implementation choices


  • 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

Digital security 101
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)


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

Key standard security frameworks
Key Standard Security Frameworks

Trust Management, Federation



Message Structure


Confidentiality, Integrity, Authenticity

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



Transport-Level Security: Secure Socket Layer (SSL)

Transmission Control Protocol and Internet Protocol (TCP/IP)

Transport level security and digital tokens
Transport-Level Security and Digital Tokens

  • Secure Socket Layer (SSL)

  • Digital Certificates

  • Kerberos

Transport level security ssl
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

X 509 certificate
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.


  • 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

Kerberos process
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.

Application level security xml frameworks
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

Confidentiality integrity authenticity
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

Message structure message security
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



SOAP Envelope Body

Business Payload


  • 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

Saml architecture
SAML Architecture


How you define authentication & authorization information


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


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


How SAML Protocols and Bindings combine to support specific use cases

Ws security with saml security token
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)




    <saml:Assertion> - - - </saml:Assertion>



    <SOAP-ENV:Body> - - - </SOAP-ENV:Body>


Message delivery ws addressing
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=""









  • WS-Addressing is transport-independent, i.e., the request may be over JMS and the response over HTTP

Message delivery ws reliablemessaging
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)

Trust management ws trust
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)

Ws trust focus
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

Ws trust use case
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)



WS-Trust Response

WS-Trust Request

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

Web service request (SOAP/WS-Security/SAML)



Trust management ws secureconversation
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

Metadata ws policy
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

Metadata ws policyattachment
Metadata: WS-PolicyAttachment

  • WS-PolicyAttachment defines how (WS-Policy) policies are attached to web services

    • Policies can be bound to WSDL or UDDI



<binding name="StockQuoteWebServiceSoapBinding" ...>

<wsp:PolicyReference xmlns:… URI="#SecureMessagePolicy"/>


<wsp:Policy wsu:Id="SecureMessagePolicy"... >










Metadata ws securitypolicy
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

Metadata ws metadataexchange
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


The need for security in SOA environments

“Define Once, Enforce Anywhere”

Paradigmatic Use Cases

SOA Environments

Web Applications

Key industry standards


Digital Security 101

Transport-Level Security

Application-Level Security

Standard Security Implementations

Java Frameworks

Microsoft WSE

Implementation choices

Java technology frameworks
Java Technology Frameworks

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

  • Apache / WSO2

  • Vendor specific (Oracle, IBM, BEA, etc.)

Java ee platform 5
Java EE Platform 5

Application (Web Service)





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



WS-Security and tokens

JSR 105 (RI)

Apache XML-Security



Key store, crypto operations


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
Apache / WSO2

Application (Web Service)

Axis 1.x

Axis 2





WS-SecurityPolicy, WS-Trust, etc.

Apache Rampart

Apache WSS4J

WS-Security and tokens

Signature (JSR 105), Encryption

Apache XML-Security


Key store, crypto operations

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

Application (Web Service)

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




Oracle Web Services Manager (OWSM)

WS-Security and tokens, WS-I-BSP

XML Signature & Encryption

Oracle Security Developer Tools (OSDT)


Key store, crypto operations

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


The need for security in SOA environments

“Define Once, Enforce Anywhere”

Paradigmatic Use Cases

SOA Environments

Web Applications

Key industry standards


Digital Security 101

Transport-Level Security

Application-Level Security

Standard Security Implementations

Java Frameworks

Microsoft WSE

Implementation choices

Application server vs external
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


  • 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