| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > Developing Security Providers for WebLogic Server > Authorization Providers |
|
Developing Security Providers for WebLogic Server
|
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, an Authorization provider is used to limit the interactions between users and WebLogic resources to ensure integrity, confidentiality, and availability.
The following sections describe Authorization provider concepts and functionality, and provide step-by-step instructions for developing a custom Authorization provider:
Before you develop an Authorization provider, you need to understand the following concepts:
A WebLogic resource is a structured object used to represent an underlying WebLogic Server entity that can be protected from unauthorized access. The level of granularity for WebLogic resources is up to you. For example, you can consider an entire Web application, a particular Enterprise JavaBean (EJB) within that Web application, or a single method within that EJB to be a WebLogic resource.
Note: WebLogic resources replace WebLogic Server 6.x access control lists (ACLs).
The Architecture of WebLogic Resources
The Resource interface, located in the weblogic.security.spi package, provides the definition for an object that represents a WebLogic resource, which can be protected from unauthorized access. The ResourceBase class, located in the weblogic.security.service package, is an abstract base class for more specific WebLogic resource types, and facilitates the model for extending resources. (See Figure 6-1 and Types of WebLogic Resources for more information.)
Figure 6-1 Architecture of WebLogic Resources
The ResourceBase class includes the BEA-provided implementations of the getID, getKeys, getValues, and toString methods. For more information, see the WebLogic Server 7.0 API Reference Javadoc for the ResourceBase class.
This architecture allows you to develop security providers without requiring that they be aware of any WebLogic resources. Therefore, when new resource types are added, you should not need to modify the security providers.
As shown in Figure 6-1, certain classes in the weblogic.security.service package extend the ResourceBase class, and therefore provide you with implementations for specific types of WebLogic resources. WebLogic resource implementations are available for:
Note: Each of these WebLogic resource implementations are explained in detail in the WebLogic Server 7.0 API Reference Javadoc.
Each WebLogic resource (described in Types of WebLogic Resources) can identified in two ways: by its toString() representation or by an associated resource ID (that is, using the getID method).
If you use the toString method of any WebLogic resource implementation, a description of the WebLogic resource will be returned in the form of a String. First, the type of the WebLogic resource is printed in pointy-brackets. Then, each key is printed, in order, along with its value. The keys are comma-separated. Values that are lists are comma-separated and delineated by open and close curly braces. Each value is printed as is, except that commas (,), open braces ({), close braces (}), and back slashes (\) are each escaped with a back slash. For example, the EJB resource:
EJBResource ("myApp",
"MyJarFile",
"myEJB",
"myMethod",
"Home",
new String[ ] {"argumentType1", "argumentType2"}
);
will produce the following toString output:
type=<ejb>, app=myApp, module="MyJarFile", ejb=myEJB, method="myMethod", methodInterface="Home", methodParams={argumentType1, argumentType2}
The format of the WebLogic resource description provided by the toString method is public (that is, you can construct one without using a Resource object) and is reversible (meaning that you can convert the String form back to the original WebLogic resource).
Note: Listing 6-1 illustrates how to use the toString method to identify a WebLogic resource.
Resource IDs and the getID Method
The getID method on each of the defined WebLogic resource types returns a 64-bit hashcode that can be used to uniquely identify the WebLogic resource in a security provider. The resource ID can be effectively used for fast runtime caching, using the following algorithm:
Note: Listing 6-2 illustrates how to use the getID method to identify a WebLogic resource in Authorization provider, and provides a sample implementation of this algorithm.
Because it is not guaranteed stable across multiple runs, you should not use the resource ID to store information about the WebLogic resource in a security provider database. Instead, best practice dictates that the security provider database contains the Resource.toString-to-security policy mapping, while the runtime cache contains the Resource.getID-to-security policy mapping.
How Security Providers Use WebLogic Resources
WebLogic resources are used in calls to Authorization and Role Mapping providers' runtime classes (specifically, in the AccessDecision and RoleMapper SSPI implementations). BEA recommends that these types of security providers store any resource-to-security policy and resource-to-role mappings in their corresponding security provider database using the WebLogic resource's toString method.
Notes: For more information about security provider databases, see Initializing the Security Provider Database. For more information about the toString method, see The toString() Method. For more information about Role Mapping providers, see Role Mapping Providers.
Listing 6-1 illustrates how to look up a WebLogic resource in the runtime class of an Authorization provider. This algorithm assumes that the security provider database for the Authorization provider contains a mapping of WebLogic resources to security policies. It is not required that you use the algorithm shown in Listing 6-1, or that you utitilize the call to the getParentResource method. (For more information about the getParentResource method, see Single-Parent Resource Hierarchies.)
Listing 6-1 How to Look Up a WebLogic Resource in an Authorization Provider: Using the toString Method
Policy findPolicy(Resource resource) {
Resource myResource = resource;
while (myResource != null) {
String resourceText = myResource.toString();
Policy policy = lookupInDB(resourceText);
if (policy != null) return policy;
myResource = myResource.getParentResource();
}
return null;
}You can optimize the algorithm for looking up a WebLogic resource by using the getID method for the resource. (Use of the toString method alone, as shown in Listing 6-1, may impact performance due to the frequency of string concatenations.) The getID method may be quicker and more efficient because it is a hash operation that is calculated and cached within the WebLogic resource itself. Therefore, when the getID method is used, the toString value only needs to be calculated once per resource (as shown in Listing 6-2).
Listing 6-2 How to Look Up a WebLogic Resource in an Authorization Provider: Using the getID Method
Policy findPolicy(Resource resource) {
Resource myResource = resource;
while (myResource != null) {
long id = myResource.getID();
Policy policy = lookupInCache(id);
if (policy != null) return policy;
String resourceText = myResource.toString();
Policy policy = lookupInDB(resourceText);
if (policy != null) {
addToCache(id, policy);
return policy;
}
myResource = myResource.getParentResource();
}
return null;
}Note: The getID method is not guaranteed between service packs or future WebLogic Server releases. Therefore, you should not store getID values in your security provider database.
Single-Parent Resource Hierarchies
WebLogic resources are arranged in a hierarchical structure ranging from most specific to least specific. You can use the getParentResource method for each of the WebLogic resource types if you like, but it is not required.
The WebLogic security providers use the single-parent resource hierarchy as follows: If a WebLogic security provider attempts to access a specific WebLogic resource and that resource cannot be located, the WebLogic security provider will call the getParentResource method of that resource. The parent of the current WebLogic resource is returned, and allows the WebLogic security provider to move up the resource hierarchy to protect the next (less-specific) resource. For example, if a caller attempts to access the following URL resource:
type=<url>, application=myApp, contextPath="/mywebapp", uri=foo/bar/my.jsp
and that exact URL resource cannot be located, the WebLogic security provider will progressively attempt to locate and protect the following resources (in order):
type=<url>, application=myApp, contextPath="/mywebapp", uri=/foo/bar/*
type=<url>, application=myApp, contextPath="/mywebapp", uri=/foo/*
type=<url>, application=myApp, contextPath="/mywebapp", uri=*.jsp
type=<url>, application=myApp, contextPath="/mywebapp", uri=/*
type=<url>, application=myApp, contextPath="/mywebapp"
type=<url>, application=myApp
type=<app>, application=myApp
type=<url>
Note: For more information about the getParentResource method, see the WebLogic Server 7.0 API Reference Javadoc for any of the predefined WebLogic resource types or the Resource interface.
WebLogic Resources, Roles, and Security Policies
Roles are abstract, logical collections of users similar to a group. Once you create a role, you define an association between that role and a WebLogic resource. This association (called a security policy) specifies who has what access to the WebLogic resource. Security policies (as well as roles) are instantiated for each level of the WebLogic resource hierarchy.
Notes: For more information about WebLogic resource hierarchies, see Single-Parent Resource Hierarchies. For information about roles and security policies for use with WebLogic resources, see "Understanding Roles" and "Understanding WebLogic Security Policies" in Managing WebLogic Security.
Like LoginModules for Authentication providers, an Access Decision is the component of an Authorization provider that actually answers the "is access allowed?" question. Specifically, an Access Decision is asked whether a subject has permission to perform a given operation on a WebLogic resource, with specific parameters in an application. Given this information, the Access Decision responds with a result of PERMIT, DENY, or ABSTAIN.
Note: For more information about Access Decisions, see Implement the AccessDecision SSPI.
Figure 6-2 illustrates how Authorization providers (and the associated Adjudication and Role Mapping providers) interact with the WebLogic Security Framework during the authorization process, and an explanation follows.
Figure 6-2 Authorization Providers and the Authorization Process
Generally, authorization is performed in the following manner:
Note: A ContextHandler is a high-performing WebLogic class that allows a variable number of arguments to be passed as strings to a method. For more information about ContextHandlers, see the WebLogic Server 7.0 API Reference Javadoc for the ContextHandler interface. For more information about Access Decisions, see Access Decisions. For more information about Role Mapping providers, see Role Mapping Providers.
The resource container calls the WebLogic Security Framework, passing in the subject, the WebLogic resource, and optionally, the ContextHandler object (to provide additional input for the decision).
The Role Mapping providers use the values contained in the Callback objects, the subject, and the resource to compute a list of roles to which the subject making the request is entitled, and pass the list of applicable roles back to the WebLogic Security Framework.
The Authorization providers' Access Decisions also use the ContextHandler to request various pieces of information about the request. They too construct a set of Callback objects that represent the type of information being requested. This set of Callback objects is then passed as an array to the ContextHandler using the handle method. (The process is the same as described for Role Mapping providers in Step 5.)
Note: For more information about the Adjudication provider, see Adjudication Providers.
Do You Need to Develop a Custom Authorization Provider?
The default (that is, active) security realm for WebLogic Server includes a WebLogic Authorization provider. The WebLogic Authorization provider supplies the default enforcement of authorization for this version of WebLogic Server. The WebLogic Authorization provider returns an access decision using a policy-based authorization engine to determine if a particular user is allowed access to a protected WebLogic resource. The WebLogic Authorization provider also supports the deployment and undeployment of security policies within the system. If you want to use an authorization mechanism that already exists within your organization, you could create a custom Authorization provider to tie into that system.
How to Develop a Custom Authorization Provider
If the WebLogic Authorization provider does not meet your needs, you can develop a custom Authorization provider by following these steps:
Create Runtime Classes Using the Appropriate SSPIs
Before you start creating runtime classes, you should first:
When you understand this information and have made your design decisions, create the runtime classes for your custom Authorization provider by following these steps:
Note: At least one Authorization provider in a security realm must implement the DeployableAuthorizationProvider SSPI, or else it will be impossible to deploy Web applications and EJBs.
For an example of how to create a runtime class for a custom Authorization provider, see Example: Creating the Runtime Class for the Sample Authorization Provider.
Implement the AuthorizationProvider SSPI
To implement the AuthorizationProvider SSPI, provide implementations for the methods described in Understand the Purpose of the "Provider" SSPIs and the following method:
For more information about the AuthorizationProvider SSPI and the getAccessDecision method, see the WebLogic Server 7.0 API Reference Javadoc.
Implement the DeployableAuthorizationProvider SSPI
To implement the DeployableAuthorizationProvider SSPI, provide implementations for the methods described in Understand the Purpose of the "Provider" SSPIs, Implement the AuthorizationProvider SSPI, and the following methods:
For more information about the DeployableAuthorizationProvider SSPI and the deployPolicy and undeployPolicy methods, see the WebLogic Server 7.0 API Reference Javadoc.
Implement the AccessDecision SSPI
When you implement the AccessDecision SSPI, you must provide implementations for the following methods:
For more information about the AccessDecision SSPI and the isAccessAllowed and isProtectedResource methods, see the WebLogic Server 7.0 API Reference Javadoc.
Example: Creating the Runtime Class for the Sample Authorization Provider
Listing 6-3 shows the SampleAuthorizationProviderImpl.java class, which is the runtime class for the sample Authorization provider. This runtime class includes implementations for:
Note: The bold face code in Listing 6-3 highlights the class declaration and the method signatures.
Listing 6-3 SampleAuthorizationProviderImpl.java
package examples.security.providers.authorization;
import java.security.Principal;
import java.util.Enumeration;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import javax.security.auth.Subject;
import weblogic.management.security.ProviderMBean;
import weblogic.security.WLSPrincipals;
import weblogic.security.service.ContextHandler;
import weblogic.security.spi.AccessDecision;
import weblogic.security.spi.DeployableAuthorizationProvider;
import weblogic.security.spi.Direction;
import weblogic.security.spi.InvalidPrincipalException;
import weblogic.security.spi.Resource;
import weblogic.security.spi.ResourceCreationException;
import weblogic.security.spi.ResourceRemovalException;
import weblogic.security.spi.Result;
import weblogic.security.spi.SecurityServices;
public final class SampleAuthorizationProviderImpl implements DeployableAuthorizationProvider, AccessDecision
{
private String description;
private SampleAuthorizerDatabase database;
public void initialize(ProviderMBean mbean, SecurityServices services)
{
System.out.println("SampleAuthorizationProviderImpl.initialize");
SampleAuthorizerMBean myMBean = (SampleAuthorizerMBean)mbean;
description = myMBean.getDescription() + "\n" + myMBean.getVersion();
database = new SampleAuthorizerDatabase(myMBean);
}
public String getDescription()
{
return description;
}
public void shutdown()
{
System.out.println("SampleAuthorizationProviderImpl.shutdown");
}
public AccessDecision getAccessDecision()
{
return this;
}
public Result isAccessAllowed(Subject subject, Map roles, Resource resource,
ContextHandler handler, Direction direction) throws InvalidPrincipalException
{
System.out.println("SampleAuthorizationProviderImpl.isAccessAllowed");
System.out.println("\tsubject\t= " + subject);
System.out.println("\troles\t= " + roles);
System.out.println("\tresource\t= " + resource);
System.out.println("\tdirection\t= " + direction);
Set principals = subject.getPrincipals();
for (Resource res = resource; res != null; res = res.getParentResource()) {
if (database.policyExists(res)) {
return isAccessAllowed(res, principals, roles);
}
}
return Result.ABSTAIN;
}public boolean isProtectedResource(Subject subject, Resource resource) throws
InvalidPrincipalException
{
System.out.println("SampleAuthorizationProviderImpl.
isProtectedResource");
System.out.println("\tsubject\t= " + subject);
System.out.println("\tresource\t= " + resource);
for (Resource res = resource; res != null; res = res.getParentResource()) {
if (database.policyExists(res)) {
return true;
}
}
return false;
}public void deployPolicy(Resource resource, String[] roleNamesAllowed)
throws ResourceCreationException
{
System.out.println("SampleAuthorizationProviderImpl.deployPolicy");
System.out.println("\tresource\t= " + resource);
for (int i = 0; roleNamesAllowed != null && i < roleNamesAllowed.length;
i++) {
System.out.println("\troleNamesAllowed[" + i + "]\t= " +
roleNamesAllowed[i]);
}
database.setPolicy(resource, roleNamesAllowed);
}
public void undeployPolicy(Resource resource) throws ResourceRemovalException
{
System.out.println("SampleAuthorizationProviderImpl.undeployPolicy");
System.out.println("\tresource\t= " + resource);
database.removePolicy(resource);
}
private boolean principalsOrRolesContain(Set principals, Map roles, String
principalOrRoleNameWant)
{
if (roles.containsKey(principalOrRoleNameWant)) {
return true;
}
{
for (Iterator i = principals.iterator(); i.hasNext();) {
Principal principal = (Principal)i.next();
String principalNameHave = principal.getName();
if (principalOrRoleNameWant.equals(principalNameHave)) {
return true;
}
}
}
return false;
}
private Result isAccessAllowed(Resource resource, Set principals, Map roles)
{
for (Enumeration e = database.getPolicy(resource); e.hasMoreElements();)
{
String principalOrRoleNameAllowed = (String)e.nextElement();
if (WLSPrincipals.getEveryoneGroupname().
equals(principalOrRoleNameAllowed) ||
(WLSPrincipals.getUsersGroupname().equals(principalOrRoleNameAllowed)
&& !principals.isEmpty()) || principalsOrRolesContain(principals,
roles, principalOrRoleNameAllowed))
{
return Result.PERMIT;
}
}
return Result.DENY;
}
}
Generate an MBean Type Using the WebLogic MBeanMaker
Before you start generating an MBean type for your custom security provider, you should first:
When you understand this information and have made your design decisions, create the MBean type for your custom Authorization provider by following these steps:
Notes: Several sample security providers (available under "Code Direct" on the dev2dev Web site) illustrate how to perform these steps.
All instructions provided in this section assume that you are working in a Windows environment.
Create an MBean Definition File (MDF)
To create an MBean Definition File (MDF), follow these steps:
Note: A complete reference of MDF element syntax is available in MBean Definition File (MDF) Element Syntax.
Use the WebLogic MBeanMaker to Generate the MBean Type
Once you create your MDF, you are ready to run it through the WebLogic MBeanMaker. The WebLogic MBeanMaker is currently a command-line utility that takes as its input an MDF, and outputs some intermediate Java files, including an MBean interface, an MBean implementation, and an associated MBean information file. Together, these intermediate files form the MBean type for your custom security provider.
The instructions for generating an MBean type differ based on the design of your custom Authorization provider. Follow the instructions that are appropriate to your situation:
No Optional SSPI MBeans and No Custom Operations
If the MDF for your custom Authorization provider does not implement any optional SSPI MBeans and does not include any custom operations, follow these steps:
java -DMDF=xmlfile -DFiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
where xmlFile is the MDF (the XML MBean Description File) and filesdir is the location where the WebLogic MBeanMaker will place the intermediate files for the MBean type.
Whenever xmlfile is provided, a new set of output files is generated. If files already exist in the location specified by filesdir, you are informed that the existing files will be overwritten and are asked to confirm.
Each time you use the -DcreateStubs=true flag, it overwrites any existing MBean implementation file.
Optional SSPI MBeans or Custom Operations
If the MDF for your custom Authorization provider does implement some optional SSPI MBeans or does include custom operations, consider the following:
java -DMDF=xmlfile -DFiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
where xmlFile is the MDF (the XML MBean Description File) and filesdir is the location where the WebLogic MBeanMaker will place the intermediate files for the MBean type.
Whenever xmlfile is provided, a new set of output files is generated. If files already exist in the location specified by filesdir, you are informed that the existing files will be overwritten and are asked to confirm.
Each time you use the -DcreateStubs=true flag, it overwrites any existing MBean implementation file.
The MBean implementation file generated by the WebLogic MBeanMaker is named MBeanNameImpl.java. For example, for the MDF named SampleAuthorizer, the MBean implementation file to be edited is named SampleAuthorizerImpl.java.
java -DMDF=xmlfile -DFiles=filesdir -DcreateStubs=true weblogic.management.commo.WebLogicMBeanMaker
where xmlFile is the MDF (the XML MBean Description File) and filesdir is the location where the WebLogic MBeanMaker will place the intermediate files for the MBean type.
Whenever xmlfile is provided, a new set of output files is generated. If files already exist in the location specified by filesdir, you are informed that the existing files will be overwritten and are asked to confirm.
Each time you use the -DcreateStubs=true flag, it overwrites any existing MBean implementation file.
The MBean implementation file generated by the WebLogic MBeanMaker is named MBeanNameImpl.java. For example, for the MDF named SampleAuthorizer, the MBean implementation file to be edited is named SampleAuthorizerImpl.java.
Accomplishing this task may include, but is not limited to: copying the method implementations from your existing MBean implementation file into the newly-generated MBean implementation file (or, alternatively, adding the new methods from the newly-generated MBean implementation file to your existing MBean implementation file), and verifying that any changes to method signatures are reflected in the version of the MBean implementation file that you are going to use (for methods that exist in both MBean implementation files).
About the Generated MBean Interface File
The MBean interface file is the client-side API to the MBean that your runtime class or your MBean implementation will use to obtain configuration data. It is typically used in the initialize method as described in Understand the Purpose of the "Provider" SSPIs.
Because the WebLogic MBeanMaker generates MBean types from the MDF you created, the generated MBean interface file will have the name of the MDF, plus the text "MBean" appended to it. For example, the result of running the SampleAuthorizer MDF through the WebLogic MBeanMaker will yield an MBean interface file called SampleAuthorizerMBean.java.
Use the WebLogic MBeanMaker to Create the MBean JAR File (MJF)
Once your have run your MDF through the WebLogic MBeanMaker to generate your intermediate files, and you have edited the MBean implementation file to supply implementations for the appropriate methods within it, you need to package the MBean files and the runtime classes for the custom Authorization provider into an MBean JAR File (MJF). The WebLogic MBeanMaker also automates this process.
To create an MJF for your custom Authorization provider, follow these steps:
java -DMJF=jarfile -DFiles=filesdir weblogic.management.commo.WebLogicMBeanMaker
where jarfile is the name for the MJF and filesdir is the location where the WebLogic MBeanMaker looks for the files to JAR into the MJF.
Compilation occurs at this point, so errors are possible. If jarfile is provided, and no errors occur, an MJF is created with the specified name.
Notes: If you want to update an existing MJF, simply delete the MJF and regenerate it. The WebLogic MBeanMaker also has a -DIncludeSource option, which controls whether source files are included into the resulting MJF. Source files include both the generated source and the MDF itself. The default is false. This option is ignored when -DMJF is not used.
The resulting MJF can be installed into your WebLogic Server environment, or distributed to your customers for installation into their WebLogic Server environments.
Install the MBean Type Into the WebLogic Server Environment
To install an MBean type into the WebLogic Server environment, copy the MJF into the WL_HOME\server\lib\mbeantypes directory, where WL_HOME is the top-level installation directory for WebLogic Server. This "deploys" your custom Authorization provider—that is, it makes the custom Authorization provider manageable from the WebLogic Server Administration Console.
You can create instances of the MBean type by configuring your custom Authorization provider (see Configure the Custom Authorization Provider Using the Administration Console), and then use those MBean instances from a GUI, from other Java code, or from APIs. For example, you can use the WebLogic Server Administration Console to get and set attributes and invoke operations, or you can develop other Java objects that instantiate MBeans and automatically respond to information that the MBeans supply. We recommend that you back up these MBean instances. For more information, see "Backing Up Security Configuration Data" under "Recovering Failed Servers" in Creating and Configuring WebLogic Server Domains.
Configure the Custom Authorization Provider Using the Administration Console
Configuring a custom Authorization provider means that you are adding the custom Authorization provider to your security realm, where it can be accessed by applications requiring authorization services.
Configuring custom security providers is an administrative task, but it is a task that may also be performed by developers of custom security providers. This section contains information that is important for the person configuring your custom Authorization providers:
Note: The steps for configuring a custom Authorization provider using the WebLogic Server Administration Console are described under "Configuring a Custom Security Provider" in Managing WebLogic Security.
Managing Authorization Providers and Deployment Descriptors
Some application components, such as Enterprise JavaBeans (EJBs) and Web applications, store relevant deployment information in Java 2 Enterprise Edition (J2EE) and WebLogic Server deployment descriptors. For Web applications, the deployment descriptor files (called web.xml and weblogic.xml) contain information for implementing the J2EE security model, including declarations of security policies. Typically, you will want to include this information when first configuring your Authorization providers in the WebLogic Server Administration Console.
The Administration Console provides an Ignore Security Data in Deployment Descriptors flag for this purpose, which you or an administrator should deselect the first time a custom Authorization provider is configured. (To locate this flag, click Security
Listing 6-4 Sample web.xml File
<?xml version="1.0" ?>
<!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>
...
<context-param>
<param-name>HTTPS_PORT</param-name>
<param-value>7502</param-value>
</context-param>
...
<servlet>
<servlet-name>Security</servlet-name>
<servlet-class>com.beasys.commerce.ebusiness.security.
EncryptionServlet</servlet-class>
</servlet>
...
<servlet-mapping>
<servlet-name>Security</servlet-name>
<url-pattern>/security</url-pattern>
</servlet-mapping>
...
<session-config>
<session-timeout>15</session-timeout>
</session-config>
...
<security-constraint>
<web-resource-collection>
<web-resource-name>Administration Tool Pages</web-resource-name>
<description>The Administration Tool Pages</description>
<url-pattern>/tools/catalog/*</url-pattern>
<url-pattern>/tools/content/*</url-pattern>
<url-pattern>/tools/order/*</url-pattern>
<url-pattern>/tools/property/*</url-pattern>
<url-pattern>/tools/usermgmt/*</url-pattern>
<url-pattern>/tools/util/*</url-pattern>
<url-pattern>/tools/webflow/*</url-pattern>
<url-pattern>/tools/*info.jsp</url-pattern>
<url-pattern>/repository/*</url-pattern>
<url-pattern>/security/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>Administrators</description>
<role-name>SystemAdminRole</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<security-constraint>
<web-resource-collection>
<web-resource-name>Portal Administration Tool Pages
</web-resource-name>
<description>The Portal Administration Tool Pages</description>
<url-pattern>/tools/portal/*</url-pattern>
<url-pattern>/tools/wlps_home.jsp</url-pattern>
<url-pattern>/repository/*</url-pattern>
<url-pattern>/security/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>Administrators</description>
<role-name>DelegatedAdminRole</role-name>
<role-name>SystemAdminRole</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
...
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
<security-role>
<description>System Administrators</description>
<role-name>SystemAdminRole</role-name>
</security-role>
...
</web-app>
While you can set additional security policies in the web.xml/weblogic.xml deployment descriptors and in the Administration Console, BEA recommends that you copy the security policies defined in the Web application or EJB deployment descriptors once, then use the Administration Console to define subsequent security policies. This is because any changes made to the security policies through the Administration Console during configuration of an Authorization provider will not be persisted to the web.xml and weblogic.xml files. Before you deploy the application again (which will happen if you redeploy it through the Administration Console, modify it on disk, or restart WebLogic Server), you should select the Ignore Security Data in Deployment Descriptors flag. If you do not, the security policies defined using the Administration Console will be overwritten by those defined in the deployment descriptors.
Note: The Ignore Security Data in Deployment Descriptors flag also affects Role Mapping providers and Credential Mapping providers. For more information, see Managing Role Mapping Providers and Deployment Descriptors and Managing Credential Mapping Providers, Resource Adapters, and Deployment Descriptors, respectively.
Enabling Security Policy Deployment
If you implemented the DeployableAuthorizationProvider SSPI and want to support deployable security policies with your custom Authorization provider, the person configuring the custom Authorization provider (that is, you or an administrator) must be sure that the Policy Deployment Enabled flag in the WebLogic Server Administration Console is checked. Otherwise, deployment for the Authorization provider is considered "turned off." Therefore, if multiple Authorization providers are configured, the Policy Deployment Enabled flag can be used to control which Authorization provider is used for security policy deployment.
The Policy Deployment Enabled flag performs the same function as the Ignore Security Data in Deployment Descriptors flag (described in Managing Authorization Providers and Deployment Descriptors), but is specific to Authorization providers.
Note: If both the Policy Deployment Enabled flag and the Ignore Security Data in Deployment Descriptors flag are checked, the Ignore Security Data in Deployment Descriptors flag takes precedence. In other words, if the Ignore Security Data in Deployment Descriptors flag is checked, the Authorization provider will not do deployment even if its Policy Deployment Enabled flag is checked.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||