Java and web services security in action
This presentation is the property of its rightful owner.
Sponsored Links
1 / 42

Java and Web Services Security in Action PowerPoint PPT Presentation


  • 74 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Java and Web Services Security in Action

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

Oracle

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


Agenda

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


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)


Agenda1

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


Use case 1 soa application

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


Use case 1 security vulnerabilities

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


Use case 2 web app invokes web service

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


Agenda2

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


Requirements

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


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)


Java and web services security in action

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.


Key standard security frameworks

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)


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.


Kerberos

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


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

Security

Token

SOAP Envelope Body

Business Payload


Java and web services security in action

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


Saml architecture

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


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)

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


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


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)

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


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

<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

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


Agenda3

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


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)

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


Apache wso2

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


Vendor specific e g oracle 11g

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


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


Agenda4

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


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


Summary

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


  • Login