BEA
WebLogic
Server
™
Programming WebLogic
Security
Restricted Rights Legend
This software and documentation is subject to and made available only pursuant to the terms of the BEA Systems License Agreement and may be used or copied only in accordance with the terms of that agreement. It is against the law to copy the software except as specifically allowed in the agreement. This document may not, in whole or in part, be copied photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form without prior consent, in writing, from BEA Systems, Inc.
Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the BEA Systems License Agreement and in subparagraph (c)(1) of the Commercial Computer Software-Restricted Rights Clause at FAR 52.227-19; subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013, subparagraph (d) of the Commercial Computer Software--Licensing clause at NASA FAR supplement 16-52.227-86; or their equivalent.
Information in this document is subject to change without notice and does not represent a commitment on the part of BEA Systems. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, BEA Systems DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE SOFTWARE OR WRITTEN MATERIAL IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE.
Trademarks or Service Marks
BEA, Jolt, Tuxedo, and WebLogic are registered trademarks of BEA Systems, Inc. BEA Builder, BEA Campaign Manager for WebLogic, BEA eLink, BEA Manager, BEA WebLogic Commerce Server, BEA WebLogic Enterprise, BEA WebLogic Enterprise Platform, BEA WebLogic Express, BEA WebLogic Integration, BEA WebLogic Personalization Server, BEA WebLogic Platform, BEA WebLogic Portal, BEA WebLogic Server, BEA WebLogic Workshop and How Business Becomes E-Business are trademarks of BEA Systems, Inc.
All other trademarks are the property of their respective companies. Programming WebLogic Security
Part Number Date Software Version
Contents
About This Document
Audience for this Guide... vii
e-docs Web Site... viii
How to Print the Document ... viii
Related Information... ix
Contact Us! ...x
Documentation Conventions ...x
1. Introduction
Audience for this Guide... 1-1 Application Developers... 1-2 Security Vendors Or Sophisticated Application Developers ... 1-3 Administrators ... 1-3 Why Implement Security?... 1-4 Security APIs... 1-5 Major Tasks Covered in this document... 1-10
2. Securing Web Applications (Thin Clients)
Authentication with Web Browsers... 2-1 Username and Password Authentication... 2-2 Digital Certificate Authentication ... 2-4 Developing Secure Web Applications... 2-6 Developing BASIC Authentication Web Applications... 2-6 Developing FORM Authentication Web Applications ... 2-11 Developing CLIENT-CERT Authentication Web Applications... 2-15
Programmatic Authentication ... 2-22
3. Writing Secure Java Clients (Fat Clients)
Introduction ... 3-1 Use of JSSE with WebLogic Server... 3-2 JAAS Authentication ... 3-3 Supported JAAS Classes ... 3-3 Overview of Specific JAAS Programming Steps... 3-4 Step 1: Authenticate the User... 3-4 Step 2: Retrieve Subject and Associate it with the Client Actions ... 3-4 Step 3: Implement the CallbackHandler Interface ... 3-4 Writing a Client Application Using JAAS Authentication ... 3-5 Sample LoginModule Implementation... 3-7 Sample Implementation of the CallbackHandler Interface ... 3-13 Sample LoginModule Configuration File ... 3-17 Sample LoginContext Implementation... 3-17 Sample Login Method Implementation... 3-18 Sample Implementation of the getSubject and runAS Methods ... 3-19 Sample PrivilegedAction Implementation ... 3-19 Sample Implementation of a Java Client That Uses JAAS ... 3-22 Using JNDI Authentication ... 3-25 Writing Applications that Use SSL ... 3-27 Communicating Securely with SSL-Enabled Web Browsers ... 3-28 Writing SSL Clients ... 3-29 SSL Client Sample ... 3-29 SSLSocketClient Sample ... 3-35 SSLClientServlet Sample... 3-39 Using Two-Way SSL Authentication... 3-40 Two-Way SSL Authentication with JNDI ... 3-41
Using Two-Way SSL Authentication Between WebLogic Server Instances... 3-43 Using Two-Way SSL Authentication with Servlets ... 3-45 Using a Custom Host Name Verifier... 3-46
Using an SSLServerSocketFactory ... 3-50 Using URLs to Make Outbound SSL Connections... 3-51
4. Securing EJB Applications
Adding Declarative Security to EJBs ... 4-1 Using the <global-role/> Tag With EJBs ... 4-3 Adding Programmatic Security to EJBs... 4-5
5. Protecting Application Server Resources
Using Network Connection Filters to Protect Application Server Resources... 5-1 Connection Filter Interfaces ... 5-2 ConnectionFilter interface... 5-2 ConnectionFilterRulesListener interface ... 5-2 Connection Filter Classes... 5-3 ConnectionFilterImpl Class ... 5-3 ConnectionEvent Class ... 5-3 Guidelines for Writing Connection Filter Rules ... 5-3 Connection Filter Rules Syntax ... 5-4 Types of Connection Filter Rules ... 5-5 How Connection Filter Rules are Evaluated... 5-5 Configuring the Default Connection Filter ... 5-6 Developing Custom Connection Filters ... 5-7 Connection Filter Examples ... 5-8 SimpleConnectionFilter Example ... 5-8 SimpleConnectionFilter2 Example ... 5-9 Example of the Accept Method Used in Filtering Network Connections
5-9
Using J2EE Sandbox Security to Protect Application Server Resources... 5-10
A. Deprecated Security APIs
Index
About This Document
This document is organized as follows:
! “Introduction”discusses the audiences of this document, the need for security, and the WebLogic Security application programming Interfaces (APIs).
! “Securing Web Applications (Thin Clients)”describes how to implement security in Web applications.
! “Writing Secure Java Clients (Fat Clients)”describes how to implement security in Java clients.
! “Securing EJB Applications”describes how to implement security in Enterprise JavaBeans.
! “Protecting Application Server Resources”discusses network connection filters and J2EE sandbox security.
! “Deprecated Security APIs”provides list ofweblogic.securitypackages in which APIs have been deprecated.
Audience for this Guide
This document is intended for programmers who want to incorporate security into their WebLogic Server applications. It provides an overview of the WebLogic security APIs and describes how to use them. The procedures and code examples provided in this document assume that you are using the WebLogic security providers that are included in the WebLogic Server distribution, not Custom security providers. The usage of the
different.
Note: This document does not provide comprehensive instructions on how to configure WebLogic Security providers and Custom security providers. For information on configuring WebLogic security providers and Custom security providers, see Managing WebLogic Security.
Note: This document is not intended for developers who want to write Custom security providers for use with WebLogic Server. It does not describe how to write Custom security providers. For information on developing Custom security providers, see Developing Security Providers for WebLogic Server.
e-docs Web Site
BEA product documentation is available on the BEA corporate Web site. From the BEA Home page, click on Product Documentation.
How to Print the Document
You can print a copy of this document from a Web browser, one main topic at a time, by using the File→Print option on your Web browser.
A PDF version of this document is available on the WebLogic Server documentation Home page on the e-docs Web site (and also on the documentation CD). You can open the PDF in Adobe Acrobat Reader and print the entire document (or a portion of it) in book format. To access the PDFs, open the WebLogic Server documentation Home page, click Download Documentation, and select the document you want to print. Adobe Acrobat Reader is available at no charge from the Adobe Web site at
In addition to this document, Programming WebLogic Security, the following documents provide user information on WebLogic Security: These documents are available on the Web atedocs.beasys.com.
! Introduction to WebLogic Security—This document summarizes the features of the WebLogic Security Service and presents an overview of the architecture and capabilities of the WebLogic Security Service. It is the starting point for understanding the WebLogic Security Service.
! Managing WebLogic Security—This document explain how to configure security for WebLogic Server and how to use compatibility security.
! Developing Security Providers for WebLogic Server—This document provides security vendors and application developers with the information needed to develop custom security providers that can be use with WebLogic Server.
! Securing a WebLogic Server Deployment—This document explains how to use the security features of WebLogic Server to protect a WebLogic Server
deployment.
! Upgrading Security in WebLogic Server Version 6.x to Version 8.1—This document provides procedures and other information you need to upgrade earlier versions of WebLogic Server to WebLogic Server 8.1. It also provides
information about moving applications from an earlier version of WebLogic Server to 8.1.
! Security FAQ—This document introduces WebLogic Server Frequently Asked Questions.
! Security Javadocs—This document provides reference documentation for the WebLogic security packages that are provided with and supported by this release of WebLogic Server.
Your feedback on BEA documentation is important to us. Send us e-mail at
docsupport@bea.comif you have questions or comments. Your comments will be reviewed directly by the BEA professionals who create and update the documentation. In your e-mail message, please indicate the software name and version you are using, as well as the title and document date of your documentation. If you have any questions about this version of BEA WebLogic Server, or if you have problems installing and running BEA WebLogic Server, contact BEA Customer Support through BEA WebSupport athttp://www.bea.com. You can also contact Customer Support by using the contact information provided on the Customer Support Card, which is included in the product package.
When contacting Customer Support, be prepared to provide the following information:
! Your name, e-mail address, phone number, and fax number
! Your company name and company address
! Your machine type and authorization codes
! The name and version of the product you are using
! A description of the problem and the content of pertinent error messages
Documentation Conventions
The following documentation conventions are used throughout this document.
Convention Usage
Ctrl+Tab Keys you press simultaneously.
text directories, and filenames and their extensions. Monospace text also indicates text that you enter from the keyboard.
Examples: import java.util.Enumeration; chmod u+w * config/examples/applications .java config.xml float monospace italic text Variables in code. Example: String CustomerName; UPPERCASE TEXT
Device names, environment variables, and logical operators.
Examples:
LPT1 BEA_HOME OR
{ } A set of choices in a syntax line.
[ ] Optional items in a syntax line. Example:
java utils.MulticastTest -n name -a address [-p portnumber] [-t timeout] [-s send]
| Separates mutually exclusive choices in a syntax line. Example:
java weblogic.deploy [list|deploy|undeploy|update] password {application} {source}
... Indicates one of the following in a command line:
! An argument can be repeated several times in the command line.
! The statement omits additional optional arguments.
. .
1
Introduction
The following topics are discussed in this section:
! Audience for this Guide ! Why Implement Security? ! Security APIs
! Major Tasks Covered in this document
Audience for this Guide
This document is intended for application developers who want to incorporate security into their WebLogic Server applications. It provides an overview of the WebLogic security APIs and describes how to use them.
Figure 1-1illustrates how different types of users would interact with the software architecture of the BEA WebLogic Server security service. The new security architecture has benefits for three categories of users: application developers, third-party security service vendors, and administrators.
Figure 1-1 How Different Users use WebLogic Server Security
Application Developers
Application developers use theWebLogic.Securityand Java 2 security application programming interfaces (APIs) to secure their applications. Therefore, this document provides instructions for using those APIs for securing Web applications, Java applications, and Enterprise JavaBeans (EJBs).
Security Vendors Or Sophisticated Application
Developers
Security vendors use the Security Service Provider Interfaces (SSPIs) to develop custom security providers for use with WebLogic Server. Sophisticated application developers may be tasked with performing this function as well, however, this document does not address this task. For information on how to use the SSPIs to develop custom security providers, seeDeveloping Security Providers for WebLogic Server.
Administrators
While administrators typically use the Administration Console to deploy, configure, and manage applications when they put the applications into production, application developers may also use the Administration Console to test their applications before they are put into production. At a minimum, testing requires that applications be deployed and configured. While this document does mention some aspects of administration as it relates to security, it referencesManaging WebLogic Security,
WebLogic Server Administration Guide, and other documents for descriptions of how to use the Administration Console to perform security tasks.
The procedures and code examples provided in this document assume that you are using the WebLogic security providers that are included in the WebLogic Server distribution, not custom security providers. The usage of the Weblogic security APIs does not change if you elect to use custom security providers, however, the
management procedures of the custom security providers may be different.
Note: This document does not provide comprehensive instructions on how to configure WebLogic Security providers or custom security providers. For information on configuring WebLogic Security providers and custom security providers, seeManaging WebLogic Security.
Why Implement Security?
Security refers to techniques for ensuring that data stored in a computer or passed between computers is not compromised. Most security measures involve proof material and data encryption. Proof material is typically a secret word or phrase that gives a user access to a particular application or system. Data encryption is the translation of data into a form that cannot be interpreted.
Distributed applications, such as those used for electronic commerce (e-commerce), offer many access points at which malicious people can intercept data, disrupt operations, or generate fraudulent input. As a business becomes more distributed the probability of security breaches increases. Accordingly, as a business distributes its applications, it becomes increasingly important for the distributed computing software upon which such applications are built to provide security.
An application server resides in the sensitive layer between end users and your valuable data and resources. WebLogic Server provides authentication, authorization, and encryption services with which you can guard your resources. These services cannot provide protection, however, from an intruder who gains access by discovering and exploiting a weakness in your deployment environment.
Therefore, whether you deploy WebLogic Server on the Internet or on an intranet, it is a good idea to hire an independent security expert to go over your security plan and procedures, audit your installed systems, and recommend improvements.
Another good strategy is to read as much as possible about security issues. For the latest information about securing Web servers, BEA recommends reading theSecurity Improvement Modules, Security Practices, and Technical Implementations
information available from the CERT™ Coordination Center operated by Carnegie Mellon University.
BEA suggests that you apply the remedies recommended in oursecurity advisories. In the event of a problem with a BEA product, BEA distributes an advisory and instructions with the appropriate course of action. If you are responsible for security related issues at your site, please register to receive future notifications. BEA has established an e-mail address (security-report@bea.com) to which you can send reports of any possible security issues in BEA products. In addition, you are advised to apply every Service Pack as they are released. Service Packs include a roll up of all bug fixes for each version of the product, as well as each of the previously released
Partner products that can also help you in your effort to secure the WebLogic Server production environment. For more information, see theBEA Partner’s Page.
Security APIs
This section lists the Security packages and classes that are implemented and supported by WebLogic Server. Application programmers use these packages to secure interactions between WebLogic Server and client applications, Enterprise JavaBeans (EJBs), and Web applications.Table 1-1lists the supported Sun Java security packages.Table 1-2lists the supported WebLogic security packages.
Note: Several of the WebLogic security packages, classes, and methods are being deprecated in this release of WebLogic Server. For more detailed information on deprecated packages and classes, see the particular package, class, or method inWebLogic javadoc.
Table 1-1 Supported Java Security Packages and Classes Package or Class Description
java.security.cert Provides classes and interfaces for parsing and managing certificates, certificate revocation lists (CRLs), and certification paths. It contains support for X.509 v3 certificates and X.509 v2 CRLs.
java.security.KeyStore This class represents an in-memory collection of keys and certificates. It is used to manage two types of keystore entries: Key and Trusted Certificate.
java.security.PrivateKey A private key. Private keys are used by entities for self-authentication.
java.security.Provider This class represents a "Cryptographic Service Provider" for the Java Security API, where a provider implements some or all parts of Java Security. To supply implementations of cryptographic services, a team of developers writes the implementation code and creates a subclass of the Provider class.
javax.crypto Provides the classes and interfaces for cryptographic operations. The cryptographic operations defined in this package include encryption, key generation and key agreement, and Message Authentication Code (MAC) generation.
Support for encryption includes symmetric, asymmetric, block, and stream ciphers. This package also supports secure streams and sealed objects.
Many classes provided in this package are provider-based (see the
java.security.Providerclass). The class itself defines a programming interface to which applications may write. The implementations themselves may then be written by independent third-party vendors and plugged in seamlessly as needed. Therefore, application developers may take advantage of any number of provider-based implementations without having to add or rewrite code.
javax.naming Provides the classes and interfaces for accessing naming services.
javax.net Provides classes for networking applications. These classes include factories for creating sockets. Using socket factories you can encapsulate socket creation and configuration behavior.
Table 1-1 Supported Java Security Packages and Classes (Continued) Package or Class Description
javax.net.SSL The classes and interfaces in this package are supported by WebLogic Server, but BEA recommends that you use the
weblogic.security.SSLpackage when you use SSL with WebLogic Server.
javax.security.cert Provides classes for public key certificates.
javax.servlet Contains classes and interfaces that describe and define the contracts between a servlet class and the runtime environment provided for an instance of such a class by a conforming servlet container.
javax.servlet.http Contains classes and interfaces that describe and define the contracts between a servlet class running under the HTTP protocol and the runtime environment provided for an instance of such a class by a conforming servlet container.
javax.security.auth Provides classes for performing JAAS-style LoginContext and Subject based authentication. This package provides a framework for authentication. The framework allows authentication to be performed in pluggable fashion. Different authentication modules can be plugged in for use with an application without requiring modifications to the application itself.
Note: WebLogic Server provides full container support for JAAS authentication and supports full use of JAAS authentication and authorization in application code.
Table 1-1 Supported Java Security Packages and Classes (Continued) Package or Class Description
Table 1-2 Supported WebLogic Security Packages
Package Description
weblogic.security Several classes deprecated in this release of WebLogic Server.
Provides interfaces and classes for mapping digital certificates sent from Web browsers and Java clients to WebLogic Server. This class makes it unnecessary for a user with a valid digital certificate to enter a username and password when accessing resources in WebLogic Server.
Note: Several classes in this package are deprecated in this release of WebLogic Server; instead, the WebLogic security infrastructure and default WebLogic security providers are used to enforce security in WebLogic Server.
weblogic.security.acl Provides interfaces and classes for creating custom security realms to access WebLogic Server users, groups, or ACLs from an external store. In addition, this package is used to test custom ACLs in server-side programs.
Note: The use of ACLs is deprecated in this release of WebLogic Server; instead, security policies and a default WebLogic security Authorization provider are used to control access to server resources in WebLogic Server.
weblogic.security.audit Provides interfaces and classes for auditing security events. WebLogic Server calls the Audit class with information about authentication and authorization requests. The package can be used to filter the authorization and authentication requests and direct them to a log file or other administrative facility.
Note: This package is being deprecated in this release of WebLogic Server. It is replaced by the new security infrastructure which includes a WebLogic security Auditing provider.
weblogic.security.auth Provides an authorization programming interface.
Note: This package is being deprecated in this release of WebLogic Server. It is replaced by the new security infrastructure which includes a WebLogic security Authorization provider.
weblogic.security.net Provides interfaces and classes that are used to examine connections to WebLogic Server and allow or deny the connections based on attributes such as the IP address, domain, or protocol of the initiator of the network connection.
weblogic.net.http. HTTPsURLConnection
Provides a class to represent an HTTPS connection to a remote object. This class is used to make an outbound SSL connection from a WebLogic Server acting as a client to another WebLogic Server.
Table 1-2 Supported WebLogic Security Packages (Continued)
Major Tasks Covered in this document
This document covers the following tasks:
! Developing secure Web application clients. This section includes instructions for using WebLogic security to secure the different types of Web application clients as defined by the J2EE specification, specifically Web browsers that use BASIC and FORM authentication. Instructions for the following tasks are provided:
" Developing Secure Web Applications
" Using the <global-role/> Tag With Web Applications " Adding Declarative Security to Web Applications
weblogic.security.SSL Provides classes for the secure socket package. Using these classes, you can communicate using SSL to reliably detect any errors introduced into the network byte stream and to optionally encrypt the data and/or authenticate the communicating peers.
Note: Some interfaces and classes in this package are deprecated in this release of WebLogic Server; instead the WebLogic security
infrastructure and the
Administration Console are used to configure SSL in WebLogic Sever.
weblogic.security.service Provides the ContextHandler and
ContextElement classes for developing custom security providers.
weblogic.security.services Provides server-side authentication class.
Table 1-2 Supported WebLogic Security Packages (Continued)
" Adding Programmatic Security to Web Applications
! Developing secure Java clients. This section includes instructions for using WebLogic security to secure the different types of Java application clients as defined by the J2EE specification, specifically:
" Writing a Client Application Using JAAS Authentication " Writing Applications that Use SSL
! Developing secure EJBs. This section includes instructions for using WebLogic security to secure EJBs. Instructions for the following tasks are provided:
" Adding Declarative Security to EJBs " Using the <global-role/> Tag With EJBs " Adding Programmatic Security to EJBs
! Protecting Application Server Resources. This section includes instructions for protecting resources at the server level. Instructions for the following tasks are provided:
" Using Network Connection Filters to Protect Application Server Resources " Using J2EE Sandbox Security to Protect Application Server Resources
2
Securing Web
Applications (Thin
Clients)
The following topics are discussed in this section:
! Authentication with Web Browsers ! Developing Secure Web Applications
! Using the <global-role/> Tag With Web Applications ! Adding Declarative Security to Web Applications ! Adding Programmatic Security to Web Applications ! Programmatic Authentication
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:! All communication on the network between the Web browser and the server is encrypted. None of the communication including the username and password flows in clear text.
! As a minimum authentication requirement, the server is required to present a digital certificate to the Web browser client to establish its trusted identity. 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 (seeFigure 2-1): 1. A user invokes a resource in WebLogic Server by entering the URL for that
resource in a Web browser. The URL contains the HTTP listen port and the HTTP schema, for example, http://myserver:7001.
2. The Web server in WebLogic Server receives the request. WebLogic Server provides its own Web server but also supports the use of Apache Server, Microsoft Internet Information Server, and Netscape Enterprise Server as Web servers.
3. The Web server checks whether the WebLogic Server resource is protected by an security policy. If the WebLogic Server resource is protected, the Web server uses the established HTTP connection to request a username and password from the user.
4. When the user’s Web browser receives the request from WebLogic Server, it prompts the user for a username and password.
5. The Web browser sends the request to the server again, along with the username and password.
6. The Web server forwards the request to the Web server plug-in. WebLogic Server provides the following plug-ins for Web servers:
" Netscape Server Application Programming Interface (NSAPI)
" Internet Information Server Application Programming Interface (ISAPI) The Web server plug-in performs authentication by sending the request, via the HTTP protocol, to the resource in WebLogic Server, along with the
authentication data (username and password) received from the user.
7. Upon successful authentication, WebLogic Server determines whether the user has the permissions necessary to access the resource.
8. Before invoking a method on the server resource, the server performs an security authorization check. During this check, the server extracts the user’s credentials from the security context, determines the user’s role, compares the user’s role to the security policy for the requested resource and verifies that the user is authorized to invoke the method on the resource.
9. If authorization succeeds, the server fulfills the request.
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):
1. A user invokes a resource in WebLogic Server by entering the URL for that resource in a Web browser. The URL contains the SSL listen port and the HTTPS schema, for example, https://myserver:7002.
2. The Web server in WebLogic Server receives the request. WebLogic Server provides its own Web server but also supports the use of Apache Server, Microsoft Internet Information Server, and Netscape Enterprise Server as Web servers.
3. The Web server checks whether the WebLogic Server resource is protected by an security policy. If the WebLogic Server resource is protected, the Web server uses the established HTTPs connection to request a username and password from the user.
4. When the user’s Web browser receives the request from WebLogic Server, it prompts the user for a username and password. (This step is optional when using two-way authentication.)
5. The Web browser sends the request again, along with the username and password. (Only supplied if requested by the server.)
6. WebLogic Server presents its digital certificate to the Web browser.
7. The Web browser checks that the server’s name matches the name in the digital certificate and that the digital certificate was issued by a trusted third party, that is, a trusted CA
8. If two-way authentication is in force on the server, the server requests a digital certificate from the client.
9. WebLogic Server checks that the client’s name matches the name in the digital certificate and that the digital certificate was issued by a trusted third party, that is, a trusted CA.
10. The Web server forwards the request to the Web server plug-in. The Web server plug-in performs authentication by sending the request, via the HTTPS protocol, to the resource in WebLogic Server, along with the authentication data (username and password) received from the user.
11. Upon successful authentication, WebLogic Server determines whether the user has the permissions necessary to access the resource.
12. Before invoking a method on the server resource, the server performs an security authorization check. During this check, the server extracts the user’s credentials from the security context, determines the user’s role, compares the user’s role to the security policy for the requested resource and verifies that the user is authorized to invoke the method on the resource.
13. If authorization succeeds, the server fulfills the request. For more information, see the following sections:
! Configuring the Apache Server Plug-In ! Configuring the Microsoft-IIS Plug-In ! Configuring the Netscape Plug-In
Developing Secure Web Applications
WebLogic Server supports three types of authentication for Web browsers:
! BASIC
! FORM
! CLIENT-CERT
The following sections cover these topics:
! Developing BASIC Authentication Web Applications ! Developing FORM Authentication Web Applications
! Developing CLIENT-CERT Authentication Web Applications ! Deploying Web Applications
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 Basic Authentication Login Screen
To develop a Web application that provides basic authentication, perform these steps: 1. Create theweb.xmldeployment descriptor. In this file you include the following
security information (seeListing 2-1):
a. Define the welcome file. The welcome file name is Welcome.jsp.
b. Define a security constraint for each set of Web application resources that you plan to protect. Each set of resources share a common URL. Resources such as HTML pages, JSPs, and servlets are the most commonly protected, but other types of resources are supported. InListing 2-1, the URL pattern points to the
Welcome.jspfile located in the Web application’s top-level directory, the HTTP methods that are allowed to access the resource, POST and GET, and the role name, webuser.
Note: Do not use hyphens in role names. Role names with hyphens cannot be modified in the Administration Console.
c. Define the type of authentication you want to use and the security realm to which the security constraints will be applied. In this case, the BASIC type is specified and the realm is the default realm, which means that the security constraints will apply to the active security realm when the WebLogic Server boots.
d. Define one or more security roles and map them to your security constraints. In our sample, only one role is defined, webuser, is defined in the security constraint so only one role name is defined here. However, any number of roles can be defined.
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>
2. Create theweblogic.xmldeployment descriptor. In this file you map security role names to users and groups.Listing 2-2shows a sampleweblogic.xmlfile that maps the webuser security role defined in the<security-role>tag in the
web.xmlfile to myGroup. With this configuration, WebLogic Server will only allow users in myGroup to access the protected resource—Welcome.jsp. However, you can use the Administration Console to modify the Web application’s security role so that other groups can be allowed to access the protected resource.
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>
3. Create a file that produces the Welcome screen that displays when the user enters a username and password and is granted access.Listing 2-3shows a sample
welcome.jspfile.Figure 2-3shows the Welcome screen.
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>
Figure 2-3 Welcome screen
4. Start WebLogic Server and define the users and Groups that will have access to the Web application resource. In the weblogic.xml file (seeListing 2-2), the
<principal-name> tag definesmyGroupas the group that has access to the Welcome.jsp. Therefore, use the Administration Console to define the myGroup group, define a user, and add that user to the myGroup group. For information on adding users and groups, seeConfiguring WebLogic Security.
5. Deploy the Web application and use the user defined in the previous step to access the protected resource.
a. For deployment instructions, see “Deploying Web Applications” on page 2-15. b. Open a Web browser and enter this URL:
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-2shows 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-4shows 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:
1. Create theweb.xmldeployment descriptor. In this file you include the following security information (seeListing 2-4):
a. Define the welcome file. The welcome file name is Welcome.jsp.
b. Define a security constraint for each set of Web application resources that you plan to protect. Each set of resources share a common URL. Resources such as HTML pages, JSPs, and servlets are the most commonly protected, but other types of resources are supported. InListing 2-4, the URL pattern pointsto /admin/edit.jspthus protecting the edit.jsp file located in the Web
Note: Do not use hyphens in role names. Role names with hyphens cannot be modified in the Administration Console.
c. Define the type of authentication you want to use and the security realm to which the security constraints will be applied. In this case, the FORM type is specified and no realm is specified so the realm is the default realm, which means that the security constraints will apply to the security realm that is activated when WebLogic Server boots.
d. Define one or more security roles and map them to your security constraints. In our sample, only one role is defined, admin, is defined in the security constraint so only one role name is defined here. However, any number of roles can be defined.
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>
</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>
2. Create theweblogic.xmldeployment descriptor. In this file you map security role names to users and groups.Listing 2-5shows a sampleweblogic.xmlfile that maps theadminsecurity role defined in the<security-role>tag in the
web.xmlfile to the groupsupportGroup. With this configuration, WebLogic Server will only allow users insupportgroup to access the protected resource. However, you can use the Administration Console to modify the Web
application’s security role so that other groups can be allowed to access the protected resource.
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">
<principal-name>supportGroup</principal-name> </security-role-assignment>
</weblogic-web-app>
3. Create a file that produces the Welcome screen when the user requests the protected resource by entering the URL.Listing 2-6shows a sample
welcome.jspfile.Figure 2-4shows the Welcome screen.
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>
4. Start WebLogic Server and define the users and Groups that will have access to the Web application resource. In the weblogic.xml file (seeListing 2-5), the
<role-name>tag definesadminas the group that has access to the edit.jsp file and defines the user joe as a member of that group. Therefore, use the
Administration Console to define theadmingroup, and define user joe and add joe to theadmingroup. You can also define other users add them to the group and they will also have access to the protected resource. For information on adding users and groups, seeConfiguring WebLogic Security.
5. Deploy the Web application and use the user(s) defined in the previous step to access the protected resource.
a. For deployment instructions, see “Deploying Web Applications” on page 2-15. b. Open a Web browser and enter this URL:
http://hostname:7001/security/welcome.jsp
c. Enter the username and password. The Welcome screen displays.
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.
Deploying Web Applications
To deploy a Web application on a server running in development mode, perform the following steps:
1. Set up a directory structure for the application’s files.Figure 2-5shows the directory structure for the Web application named basicauth. The top-level directory must be assigned the name of the Web application and the sub-directory must be namedWeb-inf.
Figure 2-5 Basicauth Application Directory Structure
2. To deploy the application in exploded directory format, simply move your directory to the applications directory on your server. For example, you would deploy thebasicauthapplication in the following location:
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
3. If you have not yet done so already, use the Administration Console to configure the users and groups that will have access to the application. To determine the users and groups that are allowed access to the protected resource, examine the
weblogic.xmlfile. For example, theweblogic.xmlfile for the basicauth sample (seeListing 2-2) definesmyGroupas the only group to have access to the
welcome.jspfile.
For more information on deploying Web applications, seeDeployment Tools and Procedures. basicauth Web-inf welcome.jsp web.xml weblogic.xml Dir Sub_Dir
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:
! Approach #1: Always use the deployment descriptors in the web.xml and weblogic.xml files. In this case, you simply elect to never use the
Administration Console to configure security and, instead, use the deployment descriptor files. The security configuration settings are read from the deployment descriptor files every time the Web application is deployed or redeployed. To use this approach, the Administration Console’s Ignore Security Data in Deployment Descriptors attribute on the General tab of a security realm must be left in its default state—unchecked.
! Approach #2: Always use the Administration Console. In this case, before
you deploy the application for the first time, you must check the Administration Console’s Ignore Security Data in Deployment Descriptors attribute so that the deployment descriptors are ignored on initial deployment and subsequent redeployments. Then you use the Administration Console to configure Global Roles after the application is deployed.
! Approach #3: Use the deployment descriptor files to configure security at initial application deployment and then use the Administration Console to configure security from that point forward. In this case, the security
configuration settings are read from the deployment descriptors upon initial deployment. Then you check the Ignore Security Data in Deployment
Descriptors attribute so that deployment descriptors are ignored on subsequent redeployments and you use the Administration Console to make all subsequent changes to the application’s security configuration.
! Approach #4: Use the deployment descriptors to configure policies and use the Administration Console to configure roles. In WebLogic Server 7.0 SP1
and later, support was added for the<global-role/>tag for use in the
weblogic.xmlandweblogic-ejb-jar.xmldeployment descriptors. You can use this tag, instead of the<principal-name>tag, to explicitly indicate that
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-7andListing 2-8show 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, SeeManaging WebLogic Security.
Adding Declarative Security to Web
Applications
To implement declarative security in Web application you use deployment descriptors (web.xmlandweblogic.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, SeeManaging 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-9shows the elements that are used with the<servlet>element to define the user role in the
web.xmlfile.
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 stringroleis mapped to the name supplied in the<role-name>element which is nested inside the<security-role-ref>element of a<servlet>declaration in theweb.xmldeployment 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 theweblogic.xmldeployment 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-assignment> <role-name>mgr</role-name> <principal-name>bostonManagers</principal-name> <principal-name>Bill</principal-name> <principal-name>Ralph</principal-name> </security-role-ref>
Programmatic Authentication
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-11shows 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);
3
Writing Secure Java
Clients (Fat Clients)
The following topics are discussed in this section:
! Introduction
! Use of JSSE with WebLogic Server ! JAAS Authentication
! Writing a Client Application Using JAAS Authentication ! Using JNDI Authentication
! Writing Applications that Use SSL
Introduction
Whether the client is an application, applet, Enterprise JavaBean (EJB), or servlet that requires authentication, WebLogic Server uses the Java Authentication and
Authorization Service (JAAS) classes to reliably and securely authenticate to the client. JAAS implements a Java version of the Pluggable Authentication Module (PAM) framework, which permits applications to remain independent from underlying authentication technologies. Therefore, the PAM framework allows the use of new or updated authentication technologies without requiring modifications to your
WebLogic Server uses JAAS for remote fat-client authentication, and internally for authentication. Therefore, only developers of custom Authentication providers and developers of remote fat client applications need to be involved with JAAS directly. Users of thin clients or developers of within-container fat client applications (for example, those calling an Enterprise JavaBean (EJB) from a servlet) do not require the direct use or knowledge of JAAS.
By default, WebLogic Server to uses SSL on the HTTPS port. The SSL protocol encrypts the data transmitted between the client and WebLogic Server so that the username and password do not flow in clear text.
Note: In order to implement security in a WebLogic client you must install the WebLogic Server software distribution kit on the Java client.
Use of JSSE with WebLogic Server
JSSE is a set of packages that support and implement the SSL and TLS v1, making those capabilities programmatically available. BEA WebLogic Server provides Secure Sockets Layer (SSL) support for encrypting data transmitted between WebLogic Server clients and servers, Java clients, Web browsers, and other servers.
WebLogic’s Java Secure Socket Extension (JSSE) implementation can be used by WebLogic clients, but is not required. Other JSSE implementations can be used for their client-side code outside the server as well.
The SSL implementation that WebLogic Server uses is static to the server configuration and is not replaceable by customer applications.
The WebLogic packages that implement JSSE are as follows:
! weblogic.security.SSL
JAAS Authentication
JAAS is a standard extension to the security in the Java Software Development Kit version 1.3. JAAS provides the ability to enforce access controls based on user identity. JAAS is provided in WebLogic Server as an alternative to the JNDI authentication mechanism.
WebLogic Server uses the authentication portion of the standard JAAS. The JAAS LoginContext provides support for the ordered execution of all configured
authentication provider LoginModule instances and is responsible for the management of the completion status of each configured provider.
Note: JAAS is the preferred method of authentication, however, the
WebLogic-supplied LoginModule only supports username and password authentication. Thus, for client certificate authentication (also referred to as two-way SSL authentication), you should use JNDI. To use JAAS for client authentication, you must write a custom LoginModule that does certificate authentication.
Note: Before compiling your JAAS applications on WebLogic Server, add the following paths to your system’sCLASSPATH to obtain required JAR files:
! %WL_HOME%\server\lib\mbeantypes\wlManagement.jar
! %WL_HOME%\server\lib\mbeantypes\wlSecurityProviders.jar
Note: WebLogic Server provides full container support for JAAS authentication and supports full use of JAAS authentication and authorization in application code.
Supported JAAS Classes
WebLogic Server supports the full JAAS 1.0 Reference Implementation with respect to authentication and authorization. While WebLogic Server does not protect any resources using JAAS authorization (it uses WebLogic security), you can use JAAS authorization in application code to protect the application’s resources.
Overview of Specific JAAS Programming Steps
The major steps for writing a secure application client using JAAS are as follows.
Step 1: Authenticate the User
The steps to authenticate the user are as follows: 1. Instantiate a LoginContext
2. Invoke the login by calling the LoginContext's login method.
These steps are executed using the JAAS classes and are described in Sun’s JAAS
Authentication Tutorial available at
http://java.sun.com/j2se/1.4/docs/guide/security/jaas/tutorials/G eneralAcnOnly.html.
Step 2: Retrieve Subject and Associate it with the Client Actions
If authentication is successful, the LoginModule populates the Subject with a Principal representing the user. The Principal the LoginModule places in the Subject is an instance of Principal, which is a class implementing thejava.security.Principal
interface. The calling application can subsequently retrieve the authenticated Subject by calling the LoginContext'sgetSubjectmethod. The
weblogic.security.SecurityclassrunAs()method is then used to associate the Subject identity with thePrivilegedActionorPrivilegedExceptionActionto be executed on behalf of the user identity.
Note: Use of the JAASjavax.security.auth.Subject.doAsmethods in WebLogic Server applications do not associate the Subject with the client actions. You may use thedoAsmethods to implement J2SE security in WebLogic Server applications, but such usage is independent of the need to use theSecurity.runAs()method.
Step 3: Implement the CallbackHandler Interface
The LoginModule uses the CallbackHandler to communicate with the user and obtain the requested information, such as the username and password.
This step is executed using the JAAS CallbackHandler interface and is described in Sun’s JAAS Authentication Tutorial available at
http://java.sun.com/j2se/1.4/docs/guide/security/jaas/tutorials/G eneralAcnOnly.html.
Writing a Client Application Using JAAS
Authentication
To use JAAS in a Java client to authenticate a Subject, perform the following procedure:
1. Implement a LoginModule class for the authentication mechanism you want to use with WebLogic Server (seeListing 3-1). You need a LoginModule class for each type of authentication mechanism. You can have multiple LoginModule classes for a single WebLogic Server deployment.
Theweblogic.security.auth.Authenticateclass uses aJNDI Environment objectfor initial context as described inTable 3-1. 2. Implement the CallbackHandler class that the LoginModule will use to
communicate with the user and obtain the requested information, such as the username and password. SeeListing 3-2for the sample CallbackHandler used in the JAAS client sample provided in the WebLogic Server distribution.
3. Implement a configuration file that specifies which LoginModule classes should be used for your WebLogic Server and in which order the LoginModule classes should be invoked. SeeListing 3-3for the sample configuration file used in the JAAS client sample provided in the WebLogic Server distribution.
4. In the Java client, instantiate aLoginContext. TheLoginContextconsults the configuration file,sample_jaas.config, to load the default LoginModule configured for WebLogic Server. SeeListing 3-4for an exampleLoginContext
instantiation.
5. Invoke thelogin()method ofLoginContext. Thelogin()method invokes all the loaded LoginModules. Each LoginModule attempts to authenticate the Subject. TheLoginContextthrows aLoginExceptionif the configured login conditions are not met. SeeListing 3-5for an example of thelogin()method. 6. Retrieve the authenticated Subject from the LoginContext and call the action as
the Subject. Upon successful authentication of a Subject, access controls can be placed upon that Subject by invoking therunAs()method of the
weblogic.security.Securityclass. TherunAs()method associates the specified Subject with the current thread’s access permissions and then executes the action. SeeListing 3-6for an example implementation of thegetSubject()
andrunAs()methods.
7. Write code to execute an action if the Subject has the required privileges. See
Listing 3-7for a sample implementation of the
javax.security.PrivilegedActionclass that executes an EJB to trade stocks.
8. Logout the user. The LoginModule logs out the user. SeeListing 3-1for a sample LoginModule.
Note: Before compiling your JAAS applications on WebLogic Server, add the following paths to your system’sCLASSPATH to obtain required JAR files:
! %WL_HOME%\server\lib\mbeantypes\wlManagement.jar
! %WL_HOME%\server\lib\mbeantypes\wlSecurityProviders.jar
Theexamples.security.jaasexample in the
SAMPLES_HOME\server\src\examples\security\jaas directory provided with WebLogic Server shows how to implement JAAS authentication in a Java client. The following sections show how each of these steps is implemented in the JAAS sample.
! Sample LoginModule Implementation
! Sample Implementation of the CallbackHandler Interface ! Sample LoginModule Configuration File
! Sample LoginContext Implementation ! Sample Login Method Implementation
! Sample Implementation of the getSubject and runAS Methods ! Sample PrivilegedAction Implementation
Sample LoginModule Implementation
Listing 3-1shows theUsernamePasswordLoginModulethat performs password authentication in theexamples.security.jaasexample. This login module class is provided in the WebLogic Server distribution in theweblogic.jarfile located in the
WL_HOME\server\libdirectory.
Listing 3-1 Example of LoginModule for Password Authentication
package weblogic.security.auth.login; import java.util.Map; import java.util.Hashtable; import java.io.IOException; import java.net.MalformedURLException; import java.rmi.RemoteException; import java.security.AccessController; import java.security.Principal; import java.security.PrivilegedAction; import javax.security.auth.Subject; import javax.security.auth.callback.Callback; import javax.security.auth.callback.CallbackHandler; import javax.security.auth.callback.NameCallback; import javax.security.auth.callback.PasswordCallback; import javax.security.auth.callback.UnsupportedCallbackException; import javax.security.auth.login.LoginException; import javax.security.auth.login.FailedLoginException; import javax.security.auth.spi.LoginModule; import weblogic.security.auth.Authenticate; import weblogic.security.auth.callback.URLCallback; import weblogic.jndi.Environment; /**
* <code>UsernamePasswordLoginModule</code> is used in a WLS client * to authenticate to the WLS server. This LoginModule
* username, password, and optional URL for the WLS server. Caller * must implement a NameCallback for the username, a
* PasswordCallback for the username, and a URLCallback for
* the URL. If no URL is available, then the callback handler should * return null for the URLCallback.
*
* @author Copyright (c) 2002 by BEA. All Rights Reserved. */
public class UsernamePasswordLoginModule implements LoginModule {
private Subject subject = null;
private CallbackHandler callbackHandler = null; private Map sharedState = null;
private Map options = null; private boolean debug = true; private String url = null;
// Authentication status
private boolean succeeded = false; private boolean commitSucceeded = false;
// Username and password
private String username = null; private String password = null;
/**
* Initialize the login module. *
* @param subject Subject to contain principals returned from * WLS server.
* @param callbackHandler CallbackHandler containing Name, * Password, and URL callbacks.
* @param sharedState Map used to share state among different * login modules.
* This is not used by this login module.
* @param options Map used to specify options to this login module. * Supported options
* debug and URL. The debug option can be used to display * additional debugging information. The URL option can be used * instead of the URL callback.
*/
public void initialize(Subject subject,
CallbackHandler callbackHandler, Map sharedState, Map options) { this.subject = subject; this.callbackHandler = callbackHandler;
this.sharedState = sharedState; this.options = options;
// Check options for login module debug enabled if(options != null)
{
Object val = options.get("debug");
if((val != null) && ((String) val).equalsIgnoreCase("true")) { debug = true; System.out.println("UsernamePasswordLoginModule.initialize(), debug enabled"); } val = options.get("URL"); if(val != null) {
url = (String) val; if(debug) System.out.println("UsernamePasswordLoginModule.initialize(), URL " + url); } } } /**
* Authenticate the user by username and password passed in *
* @return true in all cases *
* @exception FailedLoginException if the authentication fails. *
* @exception LoginException if this LoginModule is unable to * perform the authentication.
*/
public boolean login() throws LoginException {
// Verify that the client supplied a callback handler if(callbackHandler == null)
{
if(debug)
System.out.println("UsernamePasswordLoginModule.login(), no callback handler specified");
throw new LoginException("No CallbackHandler Specified"); }
// Populate callback list
Callback[] callbacks = new Callback[3];
