WS-Security

Copyright 2010 Purple Desk All Rights Reserved. PurpleDesk.and its logo are Trademarks of Purple Desk.www.javafasttrack.com

WS-Security WS-Security is a family of specifications designed to augment wirelevel security by providing a unified, transport-neutral, end-to-end framework for higher levels of security such as authentication and authorization. WS-Policy This specification describes general security capabilities, constraints, and policies. For example, a WS-Policy assertion could stipulate that a message requires security tokens or that a particular encryption algorithm be used. WS-Trust This specification deals primarily with how security tokens are to be issued, renewed, and validated. In general, the specification covers broker trust relationships, which are illustrated later in a code example. WS-Privacy This specification explains how services can state and enforce privacy policies. The specification also covers how a service can determine whether a requester intends to follow such policies. WS-SecureConversation This specification covers, as the name indicates, secure web service conversations across different sites and, therefore, across different security contexts and trust domains. The specification focuses on how a security context is created and how security keys are derived and exchanged. WS-Federation This specification addresses the challenge of managing security identities across different platforms and organizations. At the heart of the challenge is how to maintain a single, authenticated identity (for example, Alices security identity) in a heterogeneous security environment. WS-Authorization This specification covers the management of authorization data such as security tokens and underlying policies for granting access to secured resources.
Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

Wire-level security
Security begins at the transport or wire level; that is, with basic protocols that govern communications between a web service, whether SOAP-based or RESTstyle, and its clients. Security at this level typically provides three services. First, the client and service need transport-level assurance that each is communicating with the other rather than with some impostor. Second, the data sent from one side to the other needs to be encrypted strongly enough so that an interceptor cannot decrypt the data and thus gain access to the secrets carried therein

Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

User authentication and authorization

Web services provide clients with access to resources. If a resource is secured, then a client needs the appropriate credentials to gain access. The credentials are presented and verified through a process that usually has two phases. In the first phase, a client (user) presents information such as a username together with a credential such as a password. If the credential is not accepted, access to the requested resource is denied. The first phase is known as user authentication. The second phase, which is optional, consists of fine-tuning the authenticated users access rights. For example, a stock-picking web service might provide all paying customers with a username and password, but the service might divide the customers into categories, for instance, regular and premier. Access to certain resources might be restricted to premier clients. The second phase is known as role authorization

Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

WS-Security
WS-Security, or WSS for short, is a collection of protocols that specify how different levels of security can be enforced on messaging in SOAP-based web services. For example, WSS specifies how digital signatures and encryption information can be inserted into SOAP headers. Recall that SOAP-based services are designed to be transport-neutral. Accordingly, WSS is meant to provide comprehensive endToend security regardless of the underlying transport.

Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

HTTPS Basics
HTTPS is easily the most popular among the secure versions of HTTP. HTTPS provides three critical security services over and above the transport services that HTTP provides. Following is a summary of the three, with Figure 5-2 as a reference. In the figure, Alice needs to send a secret message to Bob. Eve, however, may be eavesdropping. Eve may even try to dupe Alice and Bob into believing that they are communicating with one another when, in fact, each is communicating instead with Eve. This variation is known as the MITM (Man In The Middle) attack. For secure communications, Alice and Bob thus need these three services:

Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

Peer authentication Alice needs Bob to authenticate himself so that she is sure about who is on the receiving end before she sends the secret message. Bob, too, needs Alice to authenticate herself so that he knows that the secret message is from her rather than an impostor such as Eve. This step also is described as mutual authentication or mutual challenge. Confidentiality Once Alice and Bob have authenticated each other, Alice needs to encrypt the secret message in such a way that only Bob can decrypt it. Even if Eve intercepts the encrypted message, she should not be able to decrypt the message because doing so requires enormous computational power or incredibly good luck. Integrity The message that Alice sends should be identical to the one that Bob receives. If not, an error condition should be raised. The received message might differ from the sent one for various reasons; for instance, noise in the communications channel or deliberate tampering by Eve. Any difference between the sent and the received message should be detected.
Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

Symmetric and Asymmetric Encryption/Decryption Modern approaches to encryption follow two different approaches, symmetric and asymmetric. Under either approach, the bits to be encrypted (plain bits) are one input to an encryption engine and an encryption key is the other input. The encrypted bits are the cipher bits. If the input bits represent text, then they are the plaintext and the output bits are the ciphertext. The cipher bits are one input to the decryption engine, and a decryption key is the other input. The decryption produces the original plain bits. In the symmetric approach, the same keycalled the secret key or the single keyis used to encrypt and decrypt

Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

In the asymmetric approach, the starting point is a key pair, which consists of a private key and a public key. As the names suggest, the private key should not be distributed but safeguarded by whoever generated the key pair. The public key can be distributed freely and publicly. If message bits are encrypted with the public key, they can be decrypted only with the private key, and vice-versa.The asymmetric approach solves the key distribution problem, but asymmetric encryption and decryption are roughly a thousand times slower than their symmetric counterparts.

Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

RSA This is the public key cryptography algorithm, named after Rivest, Shamir, and Adleman, the former MIT professors who designed it. RSA is the most commonly used public key algorithm. It is used to encrypt the pre-master that is sent from the client to the server. RC4_128 The stream cipher algorithm, which is used to encrypt and decrypt the bit traffic between client and server, has a key length of 128 bits. The R is for Rivest in RSA, and the C is for cipher. (Sometimes RC is said to be shorthand for Rons Code, as Rivests first name is Ron.) RC4 is the most commonly used stream cipher. RC4_128 is used to encrypt the data traffic once the handshake is completed. MD5 The certificates 128-bit identifying hash, also called its fingerprint, is generated with the Message Digest algorithm 5. MD5 supplies what is officially known as the cryptographic hash function. Rivest designed MD5 as an improvement over MD4. Although MD5 is not fatally flawed, it is gradually losing ground to alternatives such as the Secure Hash Algorithm (SHA) family of hash algorithms
Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

10

<?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-secext-1.0.xsd" S:mustUnderstand="1"> <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1216851209528949783553"> <wsse:Username>fred</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-username-token-profile-1.0#PasswordText"> rockbed </wsse:Password> <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-soap-message-security-1.0#Base64Binary"> Vyg90XUn/rl2F4m6lSFIZCoU </wsse:Nonce> <wsu:Created>2008-07-23T22:13:33.001Z</wsu:Created> </wsse:UsernameToken> </wsse:Security> </S:Header> <S:Body> <ns2:echo xmlns:ns2="http://wss.jft/"> <arg0>Hello, world!</arg0> </ns2:echo> </S:Body> </S:Envelope>
Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

11

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header/> <S:Body> <ns2:echoResponse xmlns:ns2="http://wss/"> <return>Echoing: Hello, world!</return> </ns2:echoResponse> </S:Body> </S:Envelope>

Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

12

Tomcat (Enable https)

Password changeit D:\onesource\webservices\source>keytool -genkey -alias tomcat keyalg RSA Keylocation C:\Documents and Settings\Administrator https://localhost:8443/ https://localhost:8443/wss1/TempConvertImplPort?wsdl

Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

13

Server.xml <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="C:\Documents and Settings\Administrator\.keystore"/>

Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

14

 -Djavax.net.ssl.trustStore=C:\Documents and Settings\Administrator\.keystore \ -Djavax.net.ssl.trustStorePassword=changeit \ -Djavax.net.ssl.keyStore=C:\Documents and Settings\Administrator\.keystore \ -Djavax.net.ssl.keyStorePassword=changeit

Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

15

Container-Managed Authentication and Authorization

Tomcat provides container-managed authentication and authorization. The concept of a realm plays a central role in the Tomcat approach. A realm is a collection of resources, including web pages and web services, with a designated authentication and authorization facility.
JDBCRealm The authentication information is stored in a relational database accessible through a standard Java JDBC driver. DataSourceRealm The authentication information again is stored in a relational database and accessible through a Java JDBC DataSource, which in turn is available through a JNDI JNDIRealm The authentication information is stored in an LDAP-based (Lightweight Directory Access Protocol) directory service, which is available through a JNDI provider. MemoryRealm The authentication information is read into the container at startup from the file conf/tomcat-users.xml. This is the simplest choice and the default. JAASRealm The authentication information is available through a JAAS (Java Authentication and Authorization Service) provider, which in turn is available in a Java Application Server such as BEA WebLogic, GlassFish, JBoss, or WebSphere.

Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

16

Questions and Comments

Copyright 2010 Purple Desk All Rights Reserved. www.javafasttrack.com

17