1
Securing a Web
Service
HTTP Basic Authentication and HTTPS/SSL
Authentication and Encryption
-2
HTTP Basic
Authentication
web server authenticates a client
username and password
password may be intercepted while
traveling over the network
Secure Socet Layer (SSL) encryption
may be used to overcome this
limitation
190 Building Web Services • June 2003
network. To overcome this limitation, you can run basic authentication in an SSL-protected session, described later in this chapter, which ensures that all message content is encrypted.
FIGURE A-1 HTTP Basic Authentication Login Page
To implement HTTP basic authentication, you carry out these tasks:
! Set the web service’s Authentication property in the IDE ! Associate roles with the web service in the IDE
! Define users (principals) and user groups in the application server or web server ! Map users or groups to the roles in the application server or web server
The procedures for carrying out these tasks are described in “Using HTTP Basic Authentication” on page 194.
This security mechanism applies to the entire web service and all its methods.
Note – The IDE uses a variation of HTTP basic authentication in which the generated client creates the login screen, and the user password is passed to the client proxy, which in turn passes it to the web service’s application server.
3
Implemeting HTTP
Basic Authetication
set web service’s authentication property
whithin IDE (app. server property)
define roles like admin and user
define users and user groups
map the role names to users and groups
generate a client to access the secured
web service
4
HTTPS/SSL
Authentication
and Encryption
SSL (secure socket layer) provides:
data encryption
server authentication
message integrity
and optional client authentication
two fundamental problems
of security for networked
applications can be solved by SSL:
- passwords can be intercepted
- identity of a sender or
5
Public Key Encryption
client or server is in possession of a two-part key: a public key
and a private key
the private key must be kept secret
the public key is made known to all interesting parties
keys are related mathematically and have the following
properties:
a message encrypted with the public key can be decrypted
by the private key
a message encrypted by the private key can be decrypted
by the public key
it is computationally impractical to deduce the private key
from the public key
6
Features
if I encrypt with your public key, only you can decrypt it
message can not be read by others
if modified by others, message will be garbled
encrypting a message with my private key is like signing it
(digital signature):
everyone knows, that only I can have encrypted it by
decrypting it with my public key
it must be made shure, that the public key really belongs to
me
this is done by public key certificates issued by trusted
organizations, called certificate authorities (CA)
7
Public Key
Certificates
certificate specifies the name of the owner
and attests that the public key, included in
the certificate, belongs to that owner
includes an expiration date, name of CA,
and digital signature of CA
its public key must be known without
doubt - how?
8
Public Key
Certificates (2)
SSL enabled client or server has a database
called a trust store
contains trusted certificates
certificates conform to the X.509 Public Key
Infrastructure (PKI)
commercial or private CAs, e.g.:
Verisign: http://digitalid.verisign.com
9
SSL Handshaking
1. The client sends an initial packet to the server containing information such as encryption
algorithms that it can use.
2. The server sends a packet to the client containing information such as encryption algorithms
that it can use and a copy of its certificate.
3. The client validates the server certificate. The validation process uses the client’s trust store.
See “Public Key Certificates”.
4. The client generates a random session key and encrypts the session key with the server’s
public key, obtained from the server’s certificate. The session key is temporary for the duration of
the SSL connection. The session key is processed by traditional, two-way encryption-decryption
algorithms, and must be known to both parties in the exchange.
5. The client sends the encrypted session key to the server. Only the server can decrypt the
session key, using the server’s private key. Now the client and the server both have the session
key. They use this key to encrypt and decrypt data for the remainder of the session.
This technique solves two problems:
■ The client in this scenario does not own a certificate. Therefore public key encryption
by itself cannot be used by the two parties to send data in both directions. The session
key is also needed.
■ Public key encryption is computationally intensive. It is much more efficient for SSL to
apply public key encryption only during the initial handshaking, for verifying a
10
Securing a Web
Application
Every Web Service or - more general -
Web Application uses a standard
Deployment Descriptor
a file named
web.xml
describes elements and configuration
information of a web application
11
Security Elements
inside web.xml, the following elements define
security
<security-role>
as defined in Tomcat’s config. file
tomcat_users.xml; e.g. admin, manager
<security-constraint>
maps security roles to web resources using
URL mapping
<login-config>
12
Example
web.xml
<?xml version="1.0"encoding="ISO-8859-1"?> <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version=?2.4 ?><display-name>A Secure Application</display-name> <servlet> <servlet-name>catalog</servlet-name> <servlet-class>com.mycorp.CatalogServlet </servlet-class> <init-param> <param-name>catalog</param-name> <param-value>Spring</param-value> </init-param> <security-role-ref> <role-name>MGR</role-name>
<!--role name used in code --> <role-link>manager</role-link> </security-role-ref> </servlet> <security-role> <role-name>manager</role-name> </security-role> <servlet-mapping> <servlet-name>catalog</servlet-name> <url-pattern>/catalog/*</url-pattern> </servlet-mapping> <!-- SECURITY CONSTRAINT --> <security-constraint> <web-resource-collection> <web-resource-name>SalesInfo</web-resource-name> <url-pattern>/salesinfo/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>manager</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL </transport-guarantee> </user-data-constraint> </security-constraint> <!-- LOGIN AUTHENTICATION --> <login-config> <auth-method>BASIC</auth-method> </login-config> <!-- SECURITY ROLES --> <security-role> <role-name>manager</role-name> </security-role>
request username and password
use SSL
13
