| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > Programming WebLogic Security > Securing Web Applications (Thin Clients) |
|
Programming WebLogic Security
|
Securing Web Applications (Thin Clients)
The following topics are discussed in this section:
Authentication with Web Browsers
Web browsers can connect to WebLogic Server over either an HyperText Transfer Protocol (HTTP) port or an HTTP Secure (HTTPS) port. The benefits of using an HTTPS port versus an HTTP port is two-fold. With HTTPS connections:
If the server is configured for two-way SSL authentication, both the server and client are required to present a digital certificate to each other to establish their trusted identity.
Username and Password Authentication
WebLogic Server performs username and password authentication when users use a Web browser to connect to the server via the HTTP port. In this scenario, the browser and server interact in the following manner to authenticate a user (see Figure 2-1):
Figure 2-1 illustrates the secure login process for Web browsers.
Figure 2-1 Secure Login for Web Browsers
Digital Certificate Authentication
WebLogic Server uses encryption and digital certificate authentication when Web browser users connect to the server via the HTTPS port. In this scenario, the browser and server interact in the following manner to authenticate and authorize a user (see Figure 2-1):
For more information, see the following sections:
Developing Secure Web Applications
WebLogic Server supports three types of authentication for Web browsers:
The following sections cover these topics:
Developing BASIC Authentication Web Applications
With basic authentication, the Web browser pops up a login screen in response to a resource request. The login screen prompts the user for username and password. Figure 2-2 shows a typical login screen.
Figure 2-2 Basic Authentication Login Screen
To develop a Web application that provides basic authentication, perform these steps:
Note: Do not use hyphens in role names. Role names with hyphens cannot be modified in the Administration Console.
Listing 2-1 Basic Authentication web.xml File
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app>
<welcome-file-list>
<welcome-file>welcome.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/welcome.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>webuser</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>default</realm-name>
</login-config>
<security-role>
<role-name>webuser</role-name>
</security-role>
</web-app>
Listing 2-2 BASIC Authentication weblogic.xml File
<?xml version="1.0"?>
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 6.0//EN" "http://www.bea.com/servers/wls600/dtd/weblogic-web-jar.dtd">
<weblogic-web-app>
<security-role-assignment>
<role-name>webuser</role-name>
<principal-name>myGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>
Listing 2-3 BASIC Authentication welcome.jsp File
<html>
<head>
<title>Browser Based Authentication Example Welcome Page</title>
</head>
<h1> Browser Based Authentication Example Welcome Page </h1>
<p> Welcome <%= request.getRemoteUser() %>!
</blockquote>
</body>
</html>
http://localhost:7001/basicauth/welcome.jsp
Developing FORM Authentication Web Applications
With FORM authentication, you provide a custom login screen that the Web browser displays in response to a resource request and error screen that displays if the login fails. The login screen prompts the user for username and password. Figure 2-2 shows a typical login screen. The benefit is that you have complete control over these screens so that you can design them to meet the requirements of your application.
Figure 2-4 shows the login screen for the form-based authentication sample application.
Figure 2-4 Form Authentication Login Screen
To develop a Web application that provides FORM authentication, perform these steps:
Note: Do not use hyphens in role names. Role names with hyphens cannot be modified in the Administration Console.
Listing 2-4 FORM Authentication web.xml File
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<welcome-file-list>
<welcome-file>welcome.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>AdminPages</web-resource-name>
<description>
These pages are only accessible by authorized
administrators.
</description>
<url-pattern>/admin/edit.jsp</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<description>
These are the roles who have access.
</description>
<role-name>
admin
</role-name>
</auth-constraint>
<user-data-constraint>
<description>
This is how the user data must be transmitted.
</description>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/fail_login.html</form-error-page>
</form-login-config>
</login-config>
<security-role>
<description>
An administrator
</description>
<role-name>
admin
</role-name>
</security-role>
</web-app>
Listing 2-5 FORM Authentication weblogic.xml File
<?xml version="1.0"?>
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 6.0//EN" "http://www.bea.com/servers/wls600/dtd/weblogic-web-jar.dtd">
<weblogic-web-app>
<security-role-assignment>
<role-name>admin</role-name>
<principal-name>supportGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>
Listing 2-6 Form Authentication welcome.jsp File
<html>
<head>
<title>Security login example</title>
</head>
<%
String bgcolor;
if ((bgcolor=(String)application.getAttribute("Background")) ==
null)
{
bgcolor="#cccccc";
}
%>
<body bgcolor=<%="\""+bgcolor+"\""%>>
<blockquote>
<img src=BEA_Button_Final_web.gif align=right>
<h1> Security Login Example </h1>
<p> Welcome <%= request.getRemoteUser() %>!
<p> If you are an administrator, you can configure the background
color of the Web Application.
<br> <b><a href="admin/edit.jsp">Configure background</a></b>.
<% if (request.getRemoteUser() != null) { %>
<p> Click here to <a href="logout.jsp">logout</a>.
<% } %> </blockquote>
</body>
</html>
http://hostname:7001/security/welcome.jsp
Developing CLIENT-CERT Authentication Web Applications
Use client certificates involves using the SSL and digital certificates to secure your network traffic and verify that clients are who they claim to be. For information on using SSL and digital certificates, see "Writing SSL Clients" on page 3-29.
To deploy a Web application on a server running in development mode, perform the following steps:
Figure 2-5 Basicauth Application Directory Structure
WL_HOME\user_projects\mydomain\applications\basicauth
If the server is running, the application should auto-deploy. Use the Administration Console to verify that the application deployed.
If the server is not running, the application should auto-deploy when you start the server
For more information on deploying Web applications, see Deployment Tools and Procedures.
Using the <global-role/> Tag With Web Applications
With WebLogic Server versions 7.0 SP1 and later, there are four different options, or approaches, that you can use to configure security in Web applications:
Thus, the <global-role/> tag gives you the flexibility of not having to specify a specific role mapping for each role defined in the deployment descriptors for a particular Web application. Rather, you can use the Administration Console to specify and modify a specific role mapping for each defined role at anytime. Additionally, because you may elect to use this tag on some applications and not others, it is not necessary to check the Ignore Security Data In Deployment Descriptors attribute on the General tab of the security realm. Thus, within the same security realm, deployment descriptors can be used to specify and modify security for some applications while the Administration Console can be use to specify and modify security for others.
Listing 2-7 and Listing 2-8 show by comparison how to use the <global-role> tag.
Listing 2-7 Using the web.xml and weblogic.xml Files to Map Security Roles and Principals to a Security Realm
web.xml entries:
<web-app>
...
<security-role>
<role-name>webuser</role-name>
</security-role>
...
</web-app>
<weblogic.xml entries:
<weblogic-web-app>
<security-role-assignment>
<role-name>webuser</role-name>
<principal-name>myGroup</principal-name>
<principal-name>Bill</principal-name>
<principal-name>Mary</principal-name>
</security-role-assignment>
</weblogic-web-app>
Listing 2-8 Using the <global-role> tag in Web Application Deployment Descriptors
web.xml entries:
<web-app>
...
<security-role>
<role-name>webuser</role-name>
</security-role>
...
</web-app>
<weblogic.xml entries:
<weblogic-web-app>
<security-role-assignment>
<role-name>webuser</role-name>
<global-role/>
</security-role-assignment>
For information about how to use the Administration Console to configure security for EJBs, See Managing WebLogic Security.
Adding Declarative Security to Web Applications
To implement declarative security in Web application you use deployment descriptors (web.xml and weblogic.xml) to define security requirements. The deployment descriptors map the application's logical security requirements to its runtime definitions. And at runtime, the servlet container uses the security definitions to enforce the requirements. For a discussion of using deployment descriptors, see "Developing Secure Web Applications" on page 2-6.
For information about how to use deployment descriptors and the <global-role/> tag to configure security in Web applications declaratively, see "Using the <global-role/> Tag With Web Applications" on page 2-17.
For information about how to use the Administration Console to configure security in Web applications, See Managing WebLogic Security.
Adding Programmatic Security to Web Applications
You can write your servlets to access users and roles programmatically in your servlet code. To do this, use the following method in your servlet code: javax.servlet.http.HttpServletRequest.isUserInRole(String role). This method returns a boolean indicating whether the authenticated user is included in the specified logical "role". If the user has not been authenticated, this method returns false.
This method maps roles to the group names in the security realm. Listing 2-9 shows the elements that are used with the <servlet> element to define the user role in the web.xml file.
Listing 2-9 IsUserInRole Web.xml and Weblogic.xml Elements
Begin web.xml entries:
...
<servlet>
<security-role-ref>
<role-name>user-rolename</role-name>
<role-link>rolename-link</role-link>
</security-role-ref>
</servlet>
<security-role>
<role-name>rolename-link</role-name>
</security-role>
...
Begin weblogic.xml entries:
...
<security-role-assignment>
<role-name>rolename-link</role-name>
<principal-name>groupname</principal>
<principal-name>username</principal>
</security-role-assignment>
...
The string role is mapped to the name supplied in the <role-name> element which is nested inside the <security-role-ref> element of a <servlet> declaration in the web.xml deployment description. The <role-name> element defines the name of the security role or principal that is used in the servlet code. The <role-link> element maps to a <role-name> defined in the <security-role-assignment> element in the weblogic.xml deployment descriptor.
For example, if the client has successfully logged in as user Bill with the role of manager, the following method would return true:
request.isUserInRole("manager")The following listing provides an example.
Listing 2-10 Example of Security Role Mapping
Servlet code:
out.println("Is the user a Manager? " +
request.isUserInRole("manager"));
web.xml entries:
<servlet>
. . .
<role-name>manager</role-name>
<role-link>mgr</role-link>
. . .
</servlet>
<security-role>
<role-name>mgr</role-name>
</security-role>
weblogic.xml entries:
<security-role-assignment>
<role-name>mgr</role-name>
<principal-name>bostonManagers</principal-name>
<principal-name>Bill</principal-name>
<principal-name>Ralph</principal-name>
</security-role-ref>
There are some applications where programmatic authentication is appropriate. A typical example is an application that supports user self-registration, that is, an application that requires an automated means for users to register an authentication identity for themselves and then be given immediate access to the site's protected resources. Usually, to self register, users are required to provide their identity and a password to protect the account, and perhaps some personal information that only they would know, for example, their mother's maiden name.
WebLogic Server provides a server-side API that supports programmatic authentication from within a servlet application:
weblogic.servlet.security.ServletAuthentication
Using this API, you can write servlet code that authenticates the user, logs in the user, and associates the user with the current session so that the user is registered in the active WebLogic Server security realm. Once the login is completed, it appears as if the user logged in using the standard mechanism. Listing 2-11 shows an example of how to use this API.
Listing 2-11 Programmatic Authentication Code Fragment
CallbackHandler handler = new SimpleCallbackHandler(username,
password);
Subject mySubject =
weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject);
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||