Protecting Passwords with SSL

<< Authentication Example | Mapping Application Roles >>

Protecting Passwords with SSL

</security-role>

</web-app>

More description of the elements that declare security in a deployment descriptor can be found
in

"Specifying Security Constraints" on page 854

Protecting Passwords with SSL

Passwords are not protected for confidentiality with HTTP basic or form-based authentication,
meaning that passwords sent between a client and a server on an unprotected session can be
viewed and intercepted by third parties. To overcome this limitation, you can run these
authentication protocols over an SSL-protected session and ensure that all message content is
protected for confidentiality.

A <transport-guarantee> element indicates whether or not the protected resources should
travel over protected transport. For simplicity, this example does not require protected
transport, but in a real world application, you would want to set this value to CONFIDENTIAL to
ensure that the user name and password are not observed during transmission. When running
on protected transport, you can run the application over the secure SSL protocol, https, and
specify the secure port where your SSL connector is created (the default for the Application
Server is 8181). If you do not specify the HTTPS protocol, the server will automatically redirect
the application to the secure port.

Adding Authorized Roles and Users

To authenticate a user and allow that user access to protected resources on the Application
Server, you must link the roles defined in the application to the users defined for the Application
Server.

An application may define security roles, which are a logical grouping of users, classified by
common traits such as customer profile or job title.

The Application Server has multiple realms, each of which generally includes a database of
authorized users, their passwords, and one or more logical groups to which the each user
belongs.

When an application is deployed, the application-specific security roles are mapped to security
identities in the runtime environment, such as principals (identities assigned to users as a result
of authentication) or groups. Based on this mapping, a user who has been assigned a certain
security role has associated access rights to a web application deployed onto a server.

As shown in the deployment descriptor for this example application, the security constraint
specifies that users assigned to the role of loginUser are authorized to access any of the files in
the hello1_formauth application. In this example, when a resource that is constrained by this
same security constraint is accessed, for example, hello1_formauth/web/index.jsp, the
Application Server sends the login form, receives the login information, and checks to see if the
user is in a group that has been mapped to the role of loginUser. If the user name and password
are those of an authorized user, access to the resource is granted to the requester.

Examples: Securing Web Applications

The Java EE 5 Tutorial · September 2007

872