Overview of Security Management

The following sections provide an overview of the security system for WebLogic Server, including the differences between the 6.x release of WebLogic Server and this release of WebLogic Server.

Note: Throughout this document, the term 6.x refers to WebLogic Server 6.0 and 6.1 and their associated Service Packs.

 

Audience

Managing WebLogic Security is intended for Server Administrators and Application Administrators.

  • Server Administrators 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 security configurations that prevent security problems. Related responsibilities may include maintaining critical production systems, setting up and configuring 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 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.

Server and Application Administrators should read Securing WebLogic Resources as well as this document.

 

How Security Changed in WebLogic Server

The security service in WebLogic Server simplifies the configuration and management of security while offering robust capabilities for securing your WebLogic Server deployment. This section describes how the security service changed from previous releases of WebLogic Server.

 

Change in Scope of Security Realms

In WebLogic Server 6.x, security realms provided authentication and authorization services. You chose from the File realm or a set of alternative security realms including the Lightweight Data Access Protocol (LDAP), Windows NT, Unix, or RDBMS realms. If you wanted to customize authentication, you could write you own security realm and integrate it into the WebLogic Server environment. A security realm applied to a domain and you could not have multiple security realms in a domain.

In this release of WebLogic Server, security realms act as a scoping mechanism. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies. You can configure multiple security realms in a domain; however, only one can be the default (active) security realm. WebLogic Server provides two default security realms:

  • myrealm - Has the WebLogic Adjudication, Authentication, Identity Assertion, Authorization, Role Mapping, and Credential Mapping providers configured by default.

  • CompatibilityRealm - Provides backward compatibility for 6.x security configurations. You can access an existing 6.x security configuration through the CompatibilityRealm.

Custom security realms written using the security application programming interfaces (APIs) are only supported in Compatibilty security. In this release of WebLogic Server, you customize authentication and authorization functions by configuring a new security realm to provide the security services you want and then set the new security realm as the default security realm.

 

Security Providers

Security providers are modular components that handle specific aspects of security, such as authentication and authorization. Although applications can leverage the services offered via the default WebLogic security providers, the WebLogic Security Service's flexible infrastructure also allows security vendors to write their own custom security providers for use with WebLogic Server. WebLogic security providers and custom security providers can be mixed and matched to create unique security solutions, allowing organizations to take advantage of new technology advances in some areas while retaining proven methods in others. The WebLogic Server Administration Console allows you to administer and manage all your security providers through one unified management interface.

The WebLogic Security Service supports the following types of security providers:

  • Authentication - Authentication is the process whereby the identity of users or system processes are proved or verified. Authentication also involves remembering, transporting, and making identity information available to various components of a system when that information is needed. The WebLogic Security Service supports the following types of authentication:

    • Username and password authentication

    • Certificate-based authentication directly with WebLogic Server

    • HTTP certificate-based authentication proxied through an external Web server

    The WebLogic Authentication provider supplies these services.

  • Authorization - Authorization is the process whereby the interactions between users and WebLogic resources are limited to ensure integrity, confidentiality, and availability. In other words, authorization is responsible for controlling access to WebLogic resources based on user identity or other information. The WebLogic Authorization provider supplies these services.

  • Role Mapping - Obtains a computed set of roles granted to a requestor for a given resource. Role Mapping providers supply Authorization providers with this information so that the Authorization provider can answer the "is access allowed?" question for WebLogic resources that use role-based security (for example, Web applications and Enterprise JavaBeans .

  • Identity Assertion - An Authentication provider that performs perimeter authentication - a special type of authentication using tokens - is called an Identity Assertion provider. Identity assertion involves establishing a client's identity through the use of client-supplied tokens that may exist outside of the request. Thus, the function of an Identity Assertion provider is to validate and map a token to a username. Once this mapping is complete, an Authentication provider's LoginModule can be used to convert the username to principals. The WebLogic Identity Assertion provider supplies these services.

  • Auditing - Auditing is the process whereby information about security requests and the outcome of those security requests are collected, stored, and distributed for the purpose of non-repudiation. In other words, auditing provides an electronic trail of computer activity. The WebLogic Auditing provider supplies these services.

  • Adjudication - When multiple Authorization providers are configured in a security realm, each may return a different answer to the "is access allowed" question for a given resource. Determining what to do if multiple Authorization providers do not agree is the primary function of an Adjudication provider. Adjudication providers resolve authorization conflicts by weighing each Authorization provider's answer and returning a final decision.

  • Credential Mapping - A credential map is a mapping of credentials used by WebLogic Server to credentials used in a legacy or remote system, which tell WebLogic Server how to connect to a given resource in that system. In other words, credential maps allow WebLogic Server to log into a remote system on behalf of a subject that has already been authenticated. Credential Mapping providers map credentials in this way. The WebLogic Credential Mapping provider supplies this service.

  • Keystore - A keystore is a mechanism for creating and managing password-protected stores of private keys and certificates for trusted certificate authorities. The keystore is available to applications that may need it for authentication or signing purposes. In the WebLogic Server security architecture, the WebLogic Keystore provider is used to access keystores. Note that the WebLogic Server Keystore provider is deprecated in this release of WebLogic Server and is only supported for backward compatibility. Use keystores instead.

 

Security Policies Instead of ACLs

In WebLogic Server 6.x, access control lists (ACLs) and permissions were used to protect WebLogic resources. In this release of WebLogic Server, security policies replace ACLs and permissions. Security policies answer the question "who has access" to a WebLogic resource. A security policy is created when you define an association between a WebLogic resource and a user, group, or security role. You can also optionally associate a time constraint with a security policy. A WebLogic resource has no protection until you assign it a security policy.

Creating security policies is a multi-step process with many options. To fully understand this process, read Securing WebLogic Resources. This document should be used in conjunction with Managing WebLogic Security to ensure security is completely configured for a WebLogic Server deployment.

 

WebLogic Resources

A WebLogic resource is a structured object used to represent an underlying WebLogic Server entity, which can be protected from unauthorized access. WebLogic Server defines the following resources:

  • Administrative resources such as the WebLogic Server Administration Console and the weblogic.Admin tool.

  • Application resources that represent Enterprise applications. This type of resource includes individual EAR (Enterprise Application aRchive) files and individual components, such as EJB JAR files contained within the EAR.

  • Component Object Model (COM) resources that are designed as program component objects according to Microsoft's framework. This type of resource includes COM components accessed through BEA's bi-directional COM-Java (jCOM) bridging tool.

  • Enterprise Information System (EIS) resources that are designed as connectors, which allow the integration of Java applications with existing enterprise information systems. These connectors are also known as resource adapters.

  • Enterprise JavaBean (EJB) resources including EJB JAR files, individual EJBs within an EJB JAR, and individual methods on an EJB.

  • Java DataBase Connectivity resources including groups of connection pools, individual connection pools, and multipools.

  • Java Naming and Directory Interface (JNDI) resources.

  • Java Messaging Service resources.

  • Server resources related to WebLogic Server instances, or servers. This type of resource includes operations that start, shut down, lock, or unlock servers.

  • URL resources related to Web applications. This type of resource can be a Web Application aRchive (WAR) file or individual components of a Web application (such as servlets and JSPs).

    Note: Web resources are deprecated in this release of WebLogic Server. Use the URL resource instead.

  • Web Services resources related to services that can be shared by and used as components of distributed, Web-based applications. This type of resource can be an entire Web service or individual components of a Web service (such as a stateless session EJB, particular methods in that EJB, the Web application that contains the web-services.xml file, and so on).

 

Deployment Descriptors and the WebLogic Server Administration Console

The WebLogic Security Service can use information defined in deployment descriptors to grant security roles and define security policies for Web applications and EJBs. When WebLogic Server is booted for the first time, security role and security policy information stored in weblogic.xml and weblogic-ejb-jar.xml files is loaded into the Authorization and Role Mapping providers configured in the default security realm. Changes to the information can then be made through the WebLogic Server Administration Console.

To use information in deployment descriptors, at least one Authorization and Role Mapping provider in the security realm must implement the DeployableAuthorizationProvider, and DeployableRoleProvider Security Service Provider Interface (SSPI). This SSPI allows the providers to store (rather than retrieve) information from deployment descriptors. By default, the WebLogic Authorization and Role Mapping providers implement this SSPI.

If you change security role and security policy in deployment descriptors through the WebLogic Server Administration Console and want to continue to modify this information through the WebLogic Server Administration Console, you can set attributes on the security realm to ensure changes made through the WebLogic Server Administration Console are not overwritten by old information in the deployment descriptors when WebLogic Server is rebooted.

 

The Default Security Configuration in WebLogic Server

To simplify the configuration and management of security in WebLogic Server, a default security configuration is provided. In the default security configuration, myrealm is set as the default security realm and the WebLogic Adjudication, Authentication, Identity Assertion, Authorization, Credential Mapping, and Role Mapping providers are defined as the security providers. To use the default security configuration, you need to define users, groups, and security roles for the security realm, and create security policies to protect the WebLogic resources in the domain.

If the default security configuration does not meet your requirements, you can create a new security realm with any combination of WebLogic and custom security providers and then set the new security realm as the default security realm.

 

Configuration Steps for Security

Because the security features are closely related, it is difficult to determine where to start when configuring security. In fact, configuring security for your WebLogic Server deployment may be an iterative process. Although more than one sequence of steps may work, BEA Systems recommends the following procedure:

  1. Determine whether or not to use the default security configuration by reading Customizing the Default Security Configuration.

    • If you are using the default security configuration, begin at step 3.

    • If you are not using the default security configuration, begin at step 2.

  2. Change the configuration of the security providers (for example, configure an LDAP Authentication provider instead of using the WebLogic Authentication provider) or configure custom security providers in the default security realm. This step is optional. By default, WebLogic Server configures the WebLogic security providers in the default security realm (myrealm).

    Note: You can also create a new security realm, configure security providers (either WebLogic or custom) in the security realm and set the new security realm as the default security realm.

  3. Optionally, configure embedded LDAP server. By default, attributes for the embedded LDAP server are configured. However, you may want to change those attributes to optimize the use of the embedded LDAP server in your environment.

  4. Ensure user accounts are properly secured. WebLogic Server provides a set of attributes for protecting user accounts. By default, they are set for maximum security. However, during the deployment of WebLogic Server you may need to lessen the restrictions on user accounts. Before moving to production, check that the attributes on user accounts are set for maximum protection. If you are creating a new security realm, you need to set the user lockout attributes.

  5. Protect WebLogic resources with security policies. Creating security policies is a multi-step process with many options. To fully understand this process, read Securing WebLogic Resources. This document should be used in conjunction with Managing WebLogic Security to ensure security is completely configured for a WebLogic Server deployment.

  6. Configure identity and trust and enable SSL for WebLogic Server. (This step is optional but encouraged.)

In addition, you can:

  • Map WebLogic Server credentials to credentials for an EIS (for example, the username and password for an Oracle database).

  • Configure a connection filter.

  • Enable interoperability between WebLogic domains.

 

What Is Compatibility Security?

Compatibility security refers to the capability to run security configurations from WebLogic Server 6.x in this release of WebLogic Server. In Compatibility security, you manage 6.x security realms, users, groups, and ACLs, protect user accounts, and configure the Realm Adapter Auditing provider and optionally the Identity Assertion provider in the Realm Adapter Authentication provider.

The only security realm available in Compatibility security is the CompatibilityRealm. The Realm Adapter providers (Auditing, Adjudication, Authorization, and Authentication) in the Compatibility realm allow backward compatibility to the authentication, authorization, and auditing services in 6.x security realms.

 

Management Tasks Available in Compatibility Security

Because Compatibility security only allows you to access authentication, authorization, and custom auditing implementations supported in WebLogic Server 6.x, not all 6.x security tasks are allowed in Compatibility security. Use Compatibility security to:

  1. Configure the Realm Adapter Auditing provider.

  2. Configure the Identity Assertion provider in the Realm Adapter Authentication provider so that implementations of the weblogic.security.acl.CertAuthenticator class can be used. Note that the Realm Adapter Adjudication and Authorization providers are configured by default in the CompatibilityRealm using information in an 6.x existing config.xml file. These providers can only be used in the CompatibilityRealm. The Realm Adapter Authentication provider is also automatically configured in the CompatibilityRealm. However, this provider can also be configured in other realms to provide access to users and groups stored in 6.x security realms.

  3. Change the password of the system user to protect your WebLogic Server deployment.

  4. Manage the security realm in the CompatibilityRealm.

  5. Define additional users for the security realm in the CompatibilityRealm. Organize users further by implementing groups in the security realm.

  6. Manage ACLs and permissions for the resources in your WebLogic Server deployment.

  7. Create security roles and security policies for WebLogic resources you add to the CompatibilityRealm.

You can still use SSL, configure connection filters, and enable interoperability between domains; however, you use the security features available in this release of WebLogic Server to perform these tasks.