Securing a Web Service

Size: px

Start display at page:

Download "Securing a Web Service"

Earl Hoover
10 years ago
Views:

1 1 Securing a Web Service HTTP Basic Authentication and HTTPS/SSL Authentication and Encryption - Read Chaper 32 of the J2EE Tutorial -

2 protected session, described later in this chapter, which ensur content is encrypted. 2 HTTP Basic Authentication web server authenticates a client FIGURE A-1 HTTP Basic Authentication Login Page username and password To implement HTTP basic authentication, you carry out these! 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! Map users or groups to the roles in the application server o The procedures for carrying out these tasks are described in Authentication on page 194. This security mechanism applies to the entire web service and password may be intercepted while traveling over the network Secure Socet Layer (SSL) encryption 190 Building Web Services June 2003 may be used to overcome this limitation Note The IDE uses a variation of HTTP basic authentication generated client creates the login screen, and the user passwo client proxy, which in turn passes it to the web service s appli

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!

3 Implemeting HTTP 3 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 a login screen is presented to the client

server property) define roles like admin and user define users and user

4 4 HTTPS/SSL Authentication and Encryption SSL (secure socket layer) provides: data encryption server authentication message integrity two fundamental problems of security for networked applications can be solved by SSL: - passwords can be intercepted - identity of a sender or recipient can be faked and optional client authentication

security for networked applications can be solved by SSL: - passwords can be

5 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

following properties: a message encrypted with the public key can be decrypted by the private key a message encrypted by

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

knows, that only I can have encrypted it by decrypting it with my public key it must be made shure, that the public key

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

belongs to that owner includes an expiration date, name of CA, and

8 Public Key 8 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: Digital Signatures:

the X.509 Public Key Infrastructure (PKI) commercial or private CAs, e.g.

9 SSL Handshaking 9 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 certificate s digital signature and for safe transmission of the generated session key to the server.

The validation process uses the client s trust store. See Public Key Certificates. 4.

10 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 see Tomcat documentation for details

11 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> specifies how the user is prompted to log in

12 <?xml version="1.0"encoding="iso "?> <web-app xmlns=" xmlns:xsi=" xsi:schemalocation=" 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-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> use SSL Example web.xml  <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> 12 request username and password  <login-config> <auth-method>basic</auth-method> </login-config>  <security-role> <role-name>manager</role-name> </security-role> </web-app>

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

13 Basic Authetication 13 with JAX-RPC web client must send username and password steps: add security elements to web.xml define users and their security roles in the tomcat installation modify client code to set security properties - see chapter 32 of the J2EE tutorial -

xml define users and their security roles in the tomcat

Application Security

2009 Marty Hall Declarative Web Application Security Originals of Slides and Source Code for Examples: http://courses.coreservlets.com/course-materials/msajsp.html Customized Java EE Training: http://courses.coreservlets.com/