Introduction to Programing WebLogic Security

The following topics are covered in this section:

 

Audience for This Guide

This document is intended for the following audiences:

  • Application Developers

    Developers who are Java programmers that focus on developing client applications, adding security to Web applications and Enterprise JavaBeans . They work with other engineering, Quality Assurance (QA), and database teams to implement security features. Application Developers have in-depth/working knowledge of Java (including J2EE components such as servlets/JSPs and JSEE) and Java security.

    Application developers use the WebLogic security and 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 .

  • Security Developers

    Developers who focus on defining the system architecture and infrastructure for security products that integrate into WebLogic Server and on developing custom security providers for use with WebLogic Server. They work with Application Architects to ensure that the security architecture is implemented according to design and that no security holes are introduced. They also work with Server Administrators to ensure that security is properly configured. Security Developers have a solid understanding of security concepts, including authentication, authorization, auditing (AAA), in-depth knowledge of Java (including Java Management eXtensions (JMX), and working knowledge of WebLogic Server and security provider functionality.

    Security developers use the Security Service Provider Interfaces (SSPIs) to develop custom security providers for use with WebLogic Server, however, this document does not address this task. For information on how to use the SSPIs to develop custom security providers, see Developing Security Providers for WebLogic Server.

  • Server Administrators

    Administrators who work closely with Application Architects to design a security scheme for the server and the applications running on the server, to identify potential security risks, and to propose configurations that prevent security problems. Related responsibilities may include maintaining critical production systems, configuring and managing security realms, implementing authentication and authorization schemes for server and application resources, upgrading security features, and maintaining security provider databases. Server Administrators have in-depth knowledge of the Java security architecture, including Web application and EJB security, Public Key security, and SSL.

  • Application Administrators

    Administrators who work with Server Administrators to implement and maintain security configurations and authentication and authorization schemes, and to set up and maintain access to deployed application resources in defined security realms. Application Administrators have general knowledge of security concepts and the Java Security architecture. They understand Java, XML, deployment descriptors, and can identify security events in server and audit logs.

    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. This document does not cover some aspects of administration as it relates to security, rather, it references Managing WebLogic Security, Securing WebLogic Resources, and Administration Console Online Help for descriptions of how to use the Administration Console to perform security tasks.

    This document does not provide 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.

 

What Is 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 without holding or supplying the same secret.

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 these 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 and appropriate security measures. The document Securing a Production Environment highlights essential security measures for you to consider before you deploy WebLogic Server into a production environment. The document Securing WebLogic Resources introduces the various types of WebLogic resources, and provides information that allows you to secure these resources using WebLogic Server. For the latest information about securing Web servers, BEA also recommends reading the Security 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 our security 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 Service Packs.

Product provided by BEA partners can also help you in your effort to secure the WebLogic Server production environment. For more information, see the BEA Partner's Page.

 

Types of Security Supported by WebLogic Server

WebLogic Server supports the following security mechanisms:

 

Authentication

Authentication is the mechanism by which callers and service providers prove that they are acting on behalf of specific users or systems. Authentication answers the question, "Who are you?" using credentials. When the proof is bidirectional, it is referred to as mutual authentication.

WebLogic Server supports username and password authentication and certificate authentication. For certificate authentication, WebLogic Server supports both one-way and two-way SSL authentication. Two-way SSL authentication is a form of mutual authentication.

In WebLogic Server, Authentication providers are used to prove the identity of users or system processes. Authentication providers also remember, transport, and make identity information available to various components of a system (via subjects) when needed. You can configure the Authentication providers using the Web application and EJB deployment descriptor files, or the Administration Console, or a combination of both.

 

Authorization

Authorization is the process whereby the interactions between users and WebLogic resources are controlled, based on user identity or other information. In other words, authorization answers the question, "What can you access?"

In WebLogic Server, a WebLogic Authorization provider is used to limit the interactions between users and WebLogic resources to ensure integrity, confidentiality, and availability. You can configure the Authorization provider using the Web application and EJB deployment descriptor files, or the Administration Console, or a combination of both.

WebLogic Server also supports the use of programmatic authorization (also referred to in this document as programmatic security) to limit the interactions between users and WebLogic resources.

 

J2EE Security

For implementation and use of user authentication and authorization, BEA WebLogic Server utilizes the security services of the SDK version 1.4.1 for the Java 2 Platform, Enterprise Edition (J2EE). Like the other J2EE components, the security services are based on standardized, modular components. BEA WebLogic Server implements these Java security service methods according to the standard, and adds extensions that handle many details of application behavior automatically, without requiring additional programming.

 

Security APIs

This section lists the Security packages and classes that are implemented and supported by WebLogic Server. Use these packages to secure interactions between WebLogic Server and client applications, Enterprise JavaBeans , and Web applications.

Note: Several of the WebLogic security packages, classes, and methods are deprecated in this release of WebLogic Server. For more detailed information on deprecated packages and classes, see Deprecated Security APIs.

The following topics are covered in this section:

 

JAAS Client Application APIs

Use Java APIs and WebLogic APIs to write client applications that use JAAS authentication.

The following topics are covered in this section:

 

Java JAAS Client Application APIs

Use the following Java APIs to write JAAS client applications.

For information on how to use these APIs, see JAAS Authentication APIs.

 

WebLogic JAAS Client Application APIs

Use the following WebLogic APIs to write JAAS client applications.

For information on how to use these APIs, see JAAS Authentication APIs.

 

SSL Client Application APIs

Use Java and WebLogic APIs to write client applications that use SSL authentication.

The following topics are covered in this section:

 

Java SSL Client Application APIs

Use the following Java APIs to write SSL client applications.

WebLogic Server also supports the javax.net.SSL API, but BEA recommends that you use the weblogic.security.SSL package when you use SSL with WebLogic Server.

For information on how to use these APIs, see SSL Authentication APIs.

 

WebLogic SSL Client Application APIs

Use the following WebLogic APIs to write SSL client applications.

For information on how to use these APIs, see SSL Authentication APIs.

 

Other APIs

Additionally, you use the following APIs to develop WebLogic Server applications:

  • weblogic.security.net

    This API provides interfaces and classes that are used to implement network connection filters. Network connection filters allow or deny connections to WebLogic Server based on attributes such as the IP address, domain, or protocol of the initiator of the network connection. For more information about how to use this API, see Using Network Connection Filters.

  • weblogic.security.service

    This API includes interfaces, classes, and exceptions that support security providers. The WebLogic Security Framework consists of interfaces, classes, and exceptions provided by this API. The interfaces, classes, and exceptions in this API should be used in conjunction with those in the weblogic.security.spi package. For more information about how to use this API, see Developing Security Providers for WebLogic Server.

  • weblogic.security.services

    This API provides the server-side authentication class. This class is used to perform a local login to the server. It provides login methods that are used with CallbackHandlers to authenticate the user and return credentials using the default security realm.

  • weblogic.security.spi

    This package provides the Security Service Provider Interfaces (SSPIs). It provides interfaces, classes, and exceptions that are used for developing custom security providers. In many cases, these interfaces, classes, and exceptions should be used in conjunction with those in the weblogic.security.service API. You implement interfaces, classes, and exceptions from this package to create runtime classes for security providers. For more information about how to use the SSPIs, see Developing Security Providers for WebLogic Server.

  • weblogic.servlet.security

    This API provides a server-side API that supports programmatic authentication from within a servlet application. For more about how to use this API, see, Using the Programmatic Authentication API.

 

Administration Console and Security

With regard to security, you can use the Administration Console to define and edit deployment descriptors for Web Applications, EJBs, J2EE Connectors, and Enterprise Applications. This document, Programming WebLogic Security, does not describe how to use the Administration Console to configure security. For information on how to use the Administration Console to define and edit deployment descriptors, see Securing WebLogic Resources and Managing WebLogic Security.

 

Security Tasks and Code Examples

The security tasks 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 your 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, see Managing WebLogic Security.

Skip navigation bar  Back to Top Previous Next