weblogic the security role assignment references an invalid security role

No results were found for your search query.

To return expected results, you can:

• Reduce the number of search terms. Each term you use focuses the search further.
• Check your spelling. A single misspelled or incorrectly typed term can change your result.
• Try substituting synonyms for your original terms. For example, instead of searching for "java classes", try "java training"
• Did you search for an IBM acquired or sold product ? If so, follow the appropriate link below to find the content you need.

Search results are not available at this time. Please try again later or use one of the other support options on this page.

The security-role-assignment references an invalid security-role: maximouser

Troubleshooting.

When enabling application server security and deploying Maximo to a WebLogic environment, you may encounter the following error when attempting to initialize the application: BEA-149205>

There is likely a mismatch between the role name specified in your web xml file and the role name specified in your weblogic xml files.

Resolving The Problem

Check the following files and ensure that the role name you are using in your environment matches in all files. Note that the role name is typically specified in the singular rather than in plural. The default value is "maximouser". \maximo\applications\maximo\maximouiweb\webmodule\WEB-INF\weblogic.xml \maximo\applications\maximo\META-INF\weblogic-application.xml \maximo\applications\maximo\mboejb\ejbmodule\META-INF\weblogic-ejb-jar.xml \maximo\applications\maximo\maximouiweb\webmodule\WEB-INF\web.xml An example of the entry found in the weblogic* xml files, is as follows: <security-role-assignment> <role-name>maximouser</role-name> <principal-name>maximousers</principal-name> </security-role-assignment> An example of the entry found in the web.xml is as follows: <security-role> <description>MAXIMO Application Users</description> <role-name>maximouser</role-name> </security-role> Once each entry of the role name has been corrected in all files, rebuild and redeploy the maximo.ear.

Was this topic helpful?

Not useful Useful

Document Information

Modified date: 17 June 2018

swg22004484

Page Feedback

Share your feedback

Need support.

• Submit feedback to IBM Support

1-800-IBM-7378 ( USA )

• Directory of worldwide contacts

OBIEE Server Throws the Error - "[HTTP:101168]The security-role-assignment references an invalid security-role" (Doc ID 2305240.1)

Last updated on MAY 08, 2023

The error " [HTTP:101168]The security-role-assignment references an invalid security-role: allowedGroups  "occurs when attempting to start OBIEE weblogic server

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.

• X (Twitter)

IT-Security (Part 7): WebLogic Server, Roles, Role Mapping and Configuring a Role Mapping Provider

Key words: IT-Security, WebLogic Server, Authorization, authorization process, Role Mapping, Roles and  XACML Role Mapping Provider

L et“™s continue with Authorization topic. We discussed about the Authorization Process and its main components such as WebLogic Security Framework and Security Provider. Now, we look at Security Provider“™s subcomponents: Role Mapping and Security Policies.

The Role Mapping: Is access allowed?

Role Mapping providers help to clear, weather a user has the adequate role to access a resource? The Authorization provider can with this role information answer the „is access allowed?“ question for WebLogic resources. [1]

The Role Mapping Process

Role mapping is the process whereby principals are dynamically mapped to security roles at runtime. The WebLogic Security Framework sends Request Parameter to specific Role Mapping provider that is configured for a security realm as a part of an authorization decision. Figure 1 Role Mapping Process presents how the Role Mapping providers interact with the WebLogic Security Framework to create dynamic role associations. The result is a set of roles that apply to the principals stored in a subject at a given moment . [2]

Figure 1 Role Mapping Process

Let“™s review each part again [3] :

• The request parameters are including information such as the subject of the request and the WebLogic resource being requested.
• Role Mapping provider contains a list of the roles. For instance, if a security policy specifies that the requestor is permitted to a particular role, the role is added to the list of roles that are applicable to the subject.
• As response, get WebLogic Security Framework the list of roles.
• These roles can then be used to make authorization decisions for protected WebLogic resources, as well as for resource container and application code. I“™m going to discuss about that in part 9.

Configuring a Role Mapping Provider

The XACML Role Mapping provider and DefaultRoleMapper are included by WebLogic Server. In addition, you can use a custom Role Mapping provider in your security realm too. By default, most configuration options for the XACML Role Mapping provider are already defined. However, you can set Role Mapping Deployment Enabled, which specifies whether or not this Role Mapping provider imports information from deployment descriptors for Web applications and EJBs into the security realm. This setting is enabled by default. In order to support Role Mapping Deployment Enabled, a Role Mapping provider must implement the DeployableRoleProvider SSPI. Roles are stored by the XACML Role Mapping provider in the embedded LDAP server. [4] XACML Role Mapping provider is the standard Role Mapping provider for the WebLogic Security Framework. To configure a Role Mapping provider:

• In the Change Center of the Administration Console, click Lock & Edit

Figure 2 Change Center

• In the left pane, select Security Realms and click the name of the realm you are configuring.

Figure 3 Domain Structure: Click Security Realms

Figure 4 Summary of Security Realms

• Select Providers > Role Mapping. The Role Mapping Providers table lists the Role Mapping providers configured in this security realm

Figure 5 myrealm: Role Mapping

• Click New. The Create a New Role Mapping Provider page appears.

Figure 6 WebLogic Server default Role Mapping Provider: XACMLRoleMapper

• In the Name field, enter a name for the Role Mapping provider. From the Type drop-down list, select the type of the Role Mapping provider (e.g. DefaultRoleMapper or XACMLRoleMapper) and click OK.

Figure 7 a New Role Mapping Provider: Default_1

• Select Providers > Role Mapping and click the name of the new Role Mapping provider to complete its configuration.

Figure 8 Role Mapping Configuration

• Optionally, under Configuration > Provider Specific, set Role Deployment Enabled if you want to store security roles that are created when you deploy a Web application or an Enterprise JavaBean (EJB) (See Figure 8 Role Mapping Configuration).
• Click Save to save your changes.
• In the Change Center, click Activate Changes and then restart WebLogic Server.

XACML Role Mapping Provider

As we discussed above, a WebLogic security realm is configured by default with the XACML Role Mapping provider. It implements XACML 2.0, the standard access control policy markup language (the eXtensible Access Control Markup Language ). WebLogic XACML Role Mapping Provider is saved as a .dat file und available on e.g.: $Domain-Home/ XACMLRoleMapper.dat and has the following options (see Figure 8 Role Mapping Configuration):

• Name: The name of your WebLogic XACML Role Mapping Provider.
• Description: The description of your Weblogic XACML Role Mapping Provider.
• Version: The version of your Weblogic XACML Role Mapping Provider.
• Role Deployment Enabled: Returns whether this Role Mapping provider stores roles that are created while deploying a Web application or EJB.

You can see file structure on the following example: XACMLRoleMapper.dat has different User/Groups. For each User assigned particular Roles, Policies and associated resources. For example, you see description of Group and User „Administrators“ below:

Figure 9 XACMLRoleMapper.dat: description of Group and User „Administrators“

You see a policy contains Description, Target and Rule. Each element is associated to different attributes and with this form prepared one „authorization matrix“ that it helps to decide Application Server about a user or a group. Continued“¦

See too last parts of IT-Security and Oracle Fusion Middleware:

• https://thecattlecrew.net/2014/02/17/it-security-weblogic-server_1/
• https://thecattlecrew.net/2014/03/05/it-security-part-2-weblogic-server-and-oracle-platform-security-services-opss-2/
• https://thecattlecrew.net/2014/03/14/it-security-part-3-weblogic-server-and-java-security-features/
• https://thecattlecrew.net/2014/06/05/it-security-weblogic-server-and-authentication-part-4/
• https://thecattlecrew.net/2014/06/22/it-security-part-5-weblogic-server-perimeter-authentication-and-identity-assertion/
• https://thecattlecrew.net/2014/07/23/it-security-part-6-weblogic-server-and-authorization/

[1] Oracle® Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.6), E13707-06

[2] Oracle® Fusion Middleware Understanding Security for Oracle WebLogic Server 11g Release 1 (10.3.6), E13710-06

[3] Oracle® Fusion Middleware Understanding Security for Oracle WebLogic Server 11g Release 1 (10.3.6), E13710-06

[4] Oracle® Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.6), E13707-06

See: http://modj.org/home/ueber-uns.html

Ähnliche Posts

Wie Sie Context Mapping nicht machen sollten …

Erkennen, was wie voneinander abhängt

Die Teile dahin legen, wo sie passen könnten

2 kommentare.

Pingback: IT-Security (Part 7): WebLogic Server, Roles, Role Mapping and Configuring a Role Mapping Provider by Mohammad Esad-Djou | ora fusion community

Pingback: IT-Security (Part 7): WebLogic Server, Roles, Role Mapping and Configuring a Role Mapping Provider – Mohammad Esad-Djou

Schreibe einen Kommentar Antwort verwerfen

Speichern Sie meinen Namen, meine E-Mail-Adresse und meine Website in diesem Browser für den nächsten Kommentar.

Type above and press Enter to search. Press Esc to cancel.

Oracle Business Intelligence

• All Categories
• 12.7K Forums
• User Groups
• 1 Announcements
• Find Partners
• For Partners
• Hall of Fame: Spotlights
• Hall of Fame: Monthly Highlights
• Hall of Fame: Leaderboard

auth-constraint in WEB.xml and security-role-assignment in WEBLOGIC.xml

Dear GURUS,

I am trying to understand a few of the descriptors used for Security authentication using LDAP in web.xml and weblogic.xml:

<security-constraint>

       <auth-constraint>

       <role-name>webuser</role-name>

WEBLOGIC.xml:

<security-role-assignment>

  <role-name>webuser</role-name>

  <principal-name>myGroup</principal-name>

  </security-role-assignment>

  < externally-defined />

I need to understand how and where to define the roles and associated groups/users when using " externally-defined " descriptor.

Please note that I am trying to use groups defined in my LDAP, but am unable to use all the groups defined there.

OBIEE 12.2.1.4 and Server is Windows Server 2012 R2.

Any guidance or suggestions for this is highly appreciated.

Please direct me towards some documents with example if possible.

Editing security data

You can manage security data and supported security providers for your domain in the Security Data tree perspective.

You must be logged in as a user with the Admin role and have the WebLogic Remote Console extension installed to access this perspective. See Install the WebLogic Remote Console for instructions.

Any changes you make within the Security Data perspective are immediate - you don’t need to commit or restart the server to apply your changes.

Managing users and groups

You can easily manage the WebLogic Server users and groups that are configured as part of the default authentication provider (WebLogic Authentication Provider) within a security realm. Only the default authentication provider is supported. If you’re not using the default authentication provider, you’ll need to manage its users and groups through its own external tools.

Create a user

• In the Security Data Tree perspective, expand Realms.
• Select the Security Realm to which you want to add users.
• Expand the Authentication Provider node and then select the authentication provider to which you want to add users.
• Expand Users and click New .
• Enter a Name, Description and Password for this user. User names must be unique in the security realm and passwords must be eight characters or longer.
• Click Create .

Create groups

• Select the Security Realm to which you want to add groups.
• Expand the Authentication Provider node and then select the authentication provider to which you want to add groups.
• Expand Groups and click New .
• Enter a Name and Description for this group. Group names must be unique in the security realm.
• In the Security Data Tree perspective, go to Realms > realmName > Authentication Providers > providerName > Users.
• Click the user that you want to edit.
• Move through the various tabs to update the properties of the user. You cannot edit the name of a user - you must delete and create a new user.
• You can add users to groups. Under the Membership tab, select any Available group to which you want to add the user and move them over to Chosen.
• Click Save .

Edit groups

• In the Security Data Tree perspective, go to Realms > realmName > Authentication Providers > providerName > Groups.
• Click the group that you want to edit. You can modify the group description or, under the Membership tab, nest the current group under other groups. You cannot edit the name of a group - you must delete and create a new group.

Delete users

Delete groups

Deleting a group will not delete the users within that group.

Managing Security Policies and Roles

Use security policies to manage who can access a resource in a WebLogic Server domain.

A resource is an entity (such as a Web Service or a server instance) or an action (such as a method in a Web Service or the act of shutting down a server instance). For a list of resource types, see Resource Types You Can Secure with Policies .

A security policy specifies which users, groups, or roles can access the resource according to a set of conditions. Whenever possible, you should use security roles to determine access control. A security role, like a security group, grants an identity to a user. Unlike a group, however, membership in a role can be based on a set of conditions that are evaluated at runtime.

For most types of WebLogic resources, you can use the WebLogic Remote Console to define the security policies and roles that restrict access. However, for Web application and EJB resources, you can also use deployment descriptors.

The general process to secure a WebLogic resource is:

• Create users and groups
• Optional : Manage default security roles or create new ones. We recommend that you use roles to secure WebLogic resources (instead of users or groups) to increase efficiency for administrators who work with many users. You can use the default roles that WebLogic Server provides or create your own.
• Create and apply security policies.

For more information, see Securing Resources Using Roles and Policies for Oracle WebLogic Server .

Security roles

A security role is an identity granted to users or groups based on specific conditions. Multiple users or groups can be granted the same security role and a user or group can be in more than one security role. Security roles are used by policies to determine who can access a WebLogic resource.

WebLogic Server provides a default set of roles that you can use with any policy (global roles). You can create your own global roles or create roles that can be used by policies only for a specific resource (scoped roles). For example, you can place all of your system administrators in WebLogic Server’s Admin role. You can then create a scoped role for a specific EJB that contains highly sensitive business logic. When you create a policy for the EJB, you can specify that only the scoped role can access the EJB.

If two roles conflict, the role of a narrower scope overrides the role of the broader scope. For example, a scoped role for an EJB resource overrides a global role or a scoped role for the enterprise application that contains the EJB.

Security roles are created within a security realm, and the roles can be used only when the realm is active.

For more information, see Overview of Security Roles .

Create global roles

Before creating a new global security role, review the Global Security Roles in Securing Resources Using Roles and Policies for Oracle WebLogic Server to assess if an existing role is sufficient for your needs.

• Select the Security Realm where you want to add a global role.
• Expand Role Mappers > XACMLRoleMapper > Global > Roles.
• Click New .
• Enter a name for the new global role and click Create .

After the role is created, you can build a policy that uses conditions to determine which users or groups it encompasses. We recommend that whenever possible you use the Group condition which grants the security role to all members of the specified group. See Edit a policy for more details on how you can edit conditions.

For a description of conditions in the Predicate List, see Security Role Conditions

Create scoped roles

Scoped roles can only be used with policies that apply to specific resources.

• Select the Security Realm where you want to add a scoped role.
• Expand Role Mappers > XACMLRoleMapper > Resource > Roles.
• Enter a name for the new scoped role and click Create .

After the role is created, you can build a policy that uses conditions to determine which users or groups it encompasses. We recommend that whenever possible you use the Group condition which grants the security role to all members of a specified group. See Edit a policy for more details on how you can edit conditions.

Security policies

A security policy specifies the conditions that users, groups, or roles must meet to access a resource. Policies must have one or more conditions and you can combine conditions to create complex policies for more dynamic access control.

Root level policies apply to all instances of a specific resource type, for example, all JMS resources in your domain. All default security policies are root level policies.

You can also create policies that only apply to a specific resource instance. If the instance contains other resources, the policy will apply to the included resource as well. For example, you can create a policy for an entire JMS system resource, or for a particular queue or topic within that resource.

The policy of a narrower scope overrides policy of a broader scope. For example, if you create a security policy for a JMS system resource and a policy for a JMS queue within that system resource, the JMS queue will be protected by its own policy and will ignore the policy for the system resource.

For more information, see Security Policies in Securing Resources Using Roles and Policies for Oracle WebLogic Server .

It’s recommended that you use the Role condition where possible. Basing conditions on security roles lets you create one security policy that takes into account multiple users or groups, and is a more efficient method of management.

See Security Policy Conditions in Securing Resources Using Roles and Policies for Oracle WebLogic Server to learn more.

Create a policy for resource instances

You can create a security policy that only applies to a specific resource instance. If the instance contains other resources, the policy will apply to the included resources as well.

• Select the Security Realm that contains the resource instance where you want to add a policy.
• Expand Authorizers > XACMLAuthorizer > resourceInstance .
• Click Add Condition to open the Add New First Condition dialog box.
• Select a predicate from the Predicate List . Depending on the predicate you choose, you may need to configure arguments for the condition.

You can add more conditions to the policy to increase its complexity.

Edit a policy

You can edit a policy by modifying a condition’s arguments or by modifying the relationships between conditions in the policy.

• Go to the policy that you want to edit.
• Click on the condition you want to edit. You can only edit the arguments of the condition. If you want to use a different predicate for the condition, you must add a new condition.

Conditions have three different types of relationships: AND, OR, and Combination.

• AND: All of the conditions joined by an AND operator must be met.
• OR: At least one of the conditions joined by an OR operator must be met.
• Combination: Two or more conditions are combined and must be evaluated as a group. Conditions within a combination are themselves related to each other through AND or OR operators.

By default, a new condition is added as a simple condition at the top of the list of conditions. To insert a new condition elsewhere, select an existing condition and then click Add Condition. You’ll get a dropdown list with options to add the new condition either above or below the selected condition. The order of conditions is not meaningful to how the policy is interpreted.

A policy can contain multiple simple or compound conditions or a mix of simple and compound conditions. You can also nest compound conditions.

Why should you use compound conditions? Consider this scenario: a resource exists where you want Administrators to always have access, but Deployers to only have access between 9 am and 5 pm. The following policy would address both requirements.

Condition 1 (simple): Role: Admin

Condition 2 (compound): Role: Deployer AND access occurs between 09:00:00 and 17:00:00 GMT -7:00

Use the actions on the Policy page to edit a policy.

You can also edit a policy from its Advanced tab where the policy is expressed as string. Any changes made to a policy in the Advanced tab are reflected in the main Policy tab, and vice versa.

Delete a policy

Before you delete a policy, make sure that the default security policy for the resource instance will provide adequate access control.

• Go to the policy you want to delete.
• Delete all of the conditions in the policy.

Managing credential mappers

A Credential Mapping provider lets WebLogic Server map a WebLogic resource to a set of credentials in an external system so that the WebLogic resource can log into that external system on behalf of a subject that has already been authenticated. You can map multiple WebLogic resources (of the same type) to the same external system (and even to the same subject within that system).

You can manage the credential mappings for the default credential mapper provider (WebLogic Credential Mapping Provider) within a security realm. Only the default credential mapping provider is supported.

The general process for mapping credentials remains the same across WebLogic resources:

• Configure an applicable MBean in the Edit Tree perspective such as deploying an app or adding a data source.
• Commit your changes and restart the server if any of your changes are non-dynamic.
• In the Security Data Tree perspective, under Credential Mappers, find the corresponding node for the MBean. If necessary, define the properties of a WebLogic resource to identify it and form a connection between the MBean’s configuration data and its security data.
• Create mappings for the WebLogic resource.

You can create credential mappings for the following WebLogic resources:

• JDBC applications
• JDBC modules
• Resource adapters

Data Sources

Remote resources, app deployments: ejbs, identify an ejb component.

The first time you add a reference to an EJB component, you’ll also create a credential mapping for that EJB component.

• Select the Security Realm where you want to add a EJB component. Go to Credential Mappers > credentialMapperName > App Deployments > applicationName > EJBs.
• Fill in the fields as required.

A reference to the EJB component is added under the EJBs node. The name of the EJB component is generated by the properties of the application and those you set when adding the EJB component.

For information on how to manage the credential mappings, see Credential Mappings .

Remove a reference to an EJB Component

You cannot delete a reference to an EJB component with multiple credential mappings. To delete an EJB component reference, you must delete all of the credential mappings first - which will then delete the EJB component reference automatically - or delete all but one of the credential mappings and then follow these steps:

• In the Security Data Tree perspective, go to Credential Mappers > credentialMapperName > App Deployments > applicationName > EJBs.

App Deployments: JDBC Application

You can only add credential mappings for JDBC applications, not manage the JDBC applications themselves.

App Deployments: JDBC Modules

Identify a jdbc module.

The first time you add a reference to a JDBC module, you’ll also create a credential mapping for that JDBC module.

• Select the Security Realm where you want to add a JDBC module. Go to Credential Mappers > credentialMapperName > App Deployments > applicationName > JDBC Modules.

Remove a reference to a JDBC Module

You cannot delete a reference to a JDBC module with multiple credential mappings. To delete a JDBC module reference, you must delete all of the credential mappings first - which will then delete the JDBC module reference automatically - or delete all but one of the credential mappings and then follow these steps:

• In the Security Data Tree perspective, go to Credential Mappers > credentialMapperName > App Deployments > applicationName > JDBC Module.

App Deployments: Resource Adapters

Identify a resource adapter.

The first time you add a reference to a resource adapter, you’ll also create a credential mapping for that resource adapter.

• Select the Security Realm where you want to add a resource adapter. Go to Credential Mappers > credentialMapperName > App Deployments > applicationName > Resource Adapters.

A reference to a resource adapter is added under the Remote Adapters node. The name of the resource adapter is generated by combining its property values.

Remove a reference to Resource Adapter

You cannot delete a reference to a resource adapter with multiple credential mappings. To delete a resource adapter reference, you must delete all of the credential mappings first - which will then delete the resource adapter reference automatically - or delete all but one of the credential mappings and then follow these steps:

• In the Security Data Tree perspective, go to Credential Mappers > credentialMapperName > App Deployments > applicationName > Resource Adapter.

You can only add credential mappings for data sources, not manage the data sources themselves. You can manage data sources in the Edit tree perspective.

Identify a remote resource

The first time you add a reference to a remote resource, you’ll also create a credential mapping for that remote resource.

If you add a remote resource with the cross-domain protocol enabled, it will create a WebLogic Server user named cross-domain. Only the cross-domain user can be used to create credential mappings. While the WebLogic Remote Console will let you add other WebLogic Server users and credential mappings within the remote resource, the mappings will not work and will not provide access to the remote resource.

• Select the Security Realm where you want to add a credential mapping. Navigate down to Credential Mappers > credentialMapperName > Remote Resources.
• Fill in the fields as needed. Certain fields are disabled depending on whether you choose to use the cross-domain protocol.

A reference to a remote resource is added under the remote resources node. The name of the remote resource is generated by combining its property values.

Remove a reference to a remote resource

You cannot delete a reference to a remote resource with multiple credential mappings. To delete a remote resource reference, you must delete all of the credential mappings first - which will then delete the remote resource reference automatically - or delete all but one of the credential mappings and then follow these steps:

• In the Security Data Tree perspective, go to Realms > realmName > Credential Mappers > credentialMapperName > Remote Resources.

Credential mappings

Add a credential mapping.

You can add a new credential mapping to associate another WebLogic resource to a remote user.

The credential mappings and credentials for each WebLogic resource appear under the resource’s node.

• In the Security Data Tree perspective, go to Realms > realmName > Credential Mappers > credentialMapperName > wlResourceType > wlResourceName > Credential Mappings.
• Fill in the fields as needed. If you want to map to a remote user that is already referenced in the remote resource, disable the Create Credential toggle.

Remap a WebLogic resource

You can edit a credential mapping to associate a WebLogic user for a WebLogic resource to a different remote user. The WebLogic Remote Console must already be aware of the remote user before you can remap the WebLogic Server user. If you want to remap the WebLogic resource to a new remote user, you must first add it to the WebLogic Remote Console.

• Select the credential mapping you want to edit.
• In the Remote User field, replace the current remote user with the username of the remote user you want to remap the WebLogic resource to.
• Click Save.

Delete a credential mapping

When you delete a credential mapping, the remote user that the WebLogic resource was previously associated with is also deleted if it was the only credential mapping using that remote user.

Credentials

Add a credential.

After you have added the first set of credentials for a remote system to a WebLogic resource, you can add more users from that remote system.

• In the Security Data Tree perspective, go to Realms > realmName > Credential Mappers > credentialMapperName > wlResourceType > wlResourceName > Credentials
• Enter the username and password for the remote user.

You can now map a WebLogic user for the WebLogic resource to the new set of credentials.

Change a remote user password

If the password of the remote user changes, you’ll need to update it in the WebLogic Remote Console or the mapping will break and prevent the WebLogic resource from logging into the remote system.

• In the Security Data Tree perspective, go to Realms > realmName > Credential Mappers > credentialMapperName > wlResourceType > wlResourceName > Credentials.
• Select the remote user whose password you want to change.
• Change the password.

Remove a credential

Each WebLogic resource has its own set of credentials Removing a credential from the WebLogic Remote Console will not affect the user in the remote system.

You cannot delete a credential that currently has a WebLogic resource mapped to it.

• Select any relevant mappings and update the Remote User field to a new remote user.
• Under the same WebLogic resource, expand the Credentials node.

weblogic.xml Deployment Descriptor Elements

This following sections describe the deployment descriptor elements defined in the weblogic.xml file. The root element for weblogic.xml is <weblogic-web-app> . The following elements are defined within the <weblogic-web-app> element:

You can also access the Document Type Descriptor (DTD) for weblogic.xml at http://www.bea.com/servers/wls600/dtd/weblogic-web-jar.dtd .

description Element

The description element is a text description of the Web Application.

weblogic-version Element

The weblogic-version element indicates the version of WebLogic Server on which this Web Application is intended to be deployed. This element is informational only and is not used by WebLogic Server.

security-role-assignment Element

The security-role-assignment element declares a mapping between a security role and one or more principals in the realm, as shown in the following example.

<security-role-assignment>       <role-name> PayrollAdmin </role-name>       <principal-name> Tanya </principal-name>       <principal-name> Fred </principal-name>       <principal-name> system </principal-name> </security-role-assignment>

refer ence-descriptor Element

The reference-descriptor element maps the JNDI name of a server resource to a name used in the Web Application. The reference-description element contains two elements: The resource-description element maps a resource, for example, a DataSource, to its JNDI name. The ejb-reference element maps an EJB to its JNDI name.

resource-description Element

ejb-reference-description Element

session-descriptor Element

The session-descriptor element defines parameters for HTTP sessions, as shown in the following example:

<session-descriptor>   <session-param>      <param-name>        CookieDomain      </param-name>      <param-value>        myCookieDomain      </param-value>   </session-param> </session-descriptor>

Session Parameter Names and Values

jsp-descriptor Element

The jsp-descriptor element defines parameter names and values for servlet JSPs, as shown in the following example.

<jsp-descriptor>       <jsp-param>            <param-name>             FOO            </param-name>            <param-value>             BAR            </param-value>       </jsp-param> </ jsp-descriptor>

JSP Parameter Names and Values

• Install App

Java Development Tools

For appeals, questions and feedback about Oracle Forums, please email [email protected] . Please ask technical questions in the appropriate category. Thank you!

Error is: 'weblogic.management.DeploymentException:'

eDocs Home > BEA WebLogic Server 8.1 Documentation > Developing Web Applications for WebLogic Server > weblogic.xml Deployment Descriptor Elements

Developing Web Applications for WebLogic Server

weblogic.xml Deployment Descriptor Elements

The following sections describe the deployment descriptor elements that you define in the weblogic.xml file under the root element <weblogic-web-app> :

auth-filter

Charset-params, container-descriptor, context-root, description, jsp-descriptor, preprocessor, preprocessor-mapping.

• reference-descriptor

run-as-role-assignment

Security-permission, security-role-assignment, servlet-descriptor, session-descriptor, url-match-map, virtual-directory-mapping, weblogic-version, wl-dispatch-policy.

The DOCTYPE header for the weblogic.xml file is as follows:

<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">

You can also access the Document Type Descriptor (DTD) for weblogic.xml at http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd .

The description element is a text description of the Web application.

The weblogic-version element indicates the version of WebLogic Server on which this Web application is intended to be deployed. This element is informational only and is not used by WebLogic Server.

The security-role-assignment element declares a mapping between a security role and one or more principals in the realm, as shown in the following example.

<security-role-assignment>       <role-name> PayrollAdmin </role-name>       <principal-name> Tanya </principal-name>       <principal-name> Fred </principal-name>       <principal-name> system </principal-name> </security-role-assignment>

Note: If you do not define a security-role-assignment element and its subelements, the Web application container implicitly maps the role name as a principal name and logs a warning. The EJB container does not deploy the module if mappings are not defined.

Consider the following usage scenarios for the role name is "role_xyz"

• If you map"role_xyz to user "joe" in weblogic.xml, role_xyz becomes a local role.
• If you specify role_xyz as an externally defined role, it becomes global (it refers to the role defined at the realm level).
• If you do not define a security-role-assignment element, role_xyz becomes a local role, and the Web application container creates an implicit mapping to it and logs a warning.

The run-as-role-assignment element maps a run-as role name (a subelement of the servlet element) in web.xml to a valid user name in the system. The value can be overridden for a given servlet by the run-as-principal-name element in the servlet-descriptor. If the run-as-role-assignment is absent for a given role name, the Web application container chooses the first principal-name defined in the security-role-assignment.

refer ence-descriptor

The reference-descriptor element maps a name used in the Web application to the JNDI name of a server resource. The reference-description element contains two elements: The resource-description element maps a resource, for example, a DataSource, to its JNDI name. The ejb-reference element maps an EJB to its JNDI name.

resource-env-description

The resource-env-description element maps a resource-env-ref , declared in the ejb-jar.xml deployment descriptor, to the JNDI name of the server resource it represents.

resource-description

The resource-description element is used to map the JNDI name of a server resource to an EJB resource reference in WebLogic Server.

ejb-reference-description

The session-descriptor element contains the session-param element, which defines attributes for HTTP sessions, as shown in the following example:

<session-descriptor>   <session-param>      <param-name>        CookieDomain      </param-name>      <param-value>        myCookieDomain      </param-value>   </session-param> </session-descriptor>

session-param

The jsp-descriptor element defines attribute names and values for JSPs. You define the attributes as name/value pairs. The following example shows how to configure the compileCommand attribute. Enter all of the JSP configurations using the pattern demonstrated in this example:

<jsp-descriptor>       <jsp-param>            <param-name>             compileCommand            </param-name>            <param-value>             sj            </param-value>       </jsp-param> </ jsp-descriptor>

JSP Attribute Names and Values

The auth-filter element specifies an authentication filter HttpServlet class.

The <container-descriptor> element defines general attributes for Web applications.

check-auth-on-forward

Add the <check-auth-on-forward/> element when you want to require authentication of forwarded requests from a servlet or JSP. Omit the tag if you do not want to require re-authentication. For example:

<container-descriptor>     <check-auth-on-forward/> </container-descriptor>

Note that the default behavior has changed with the release of the Servlet 2.3 specification, which states that authentication is not required for forwarded requests.

redirect-with-absolute-url

The <redirect-with-absolute-url> element controls whether the javax.servlet.http.HttpServletResponse.SendRedirect() method redirects using a relative or absolute URL. Set this element to false if you are using a proxy HTTP server and do not want the URL converted to a non-relative link.

The default behavior is to convert the URL to a non-relative link.

user readable data used in a redirect.

index-directory-enabled

The <index-directory-enabled> element controls whether or not to automatically generate an HTML directory listing if no suitable index file is found.

The default value is false (does not generate a directory). Values are true or false .

index-directory-sort-by

The <index-directory-sort-by> element defines the order in which the directory listing generated by weblogic.servlet.FileServlet is sorted. Valid sort-by values are NAME, LAST_MODIFIED, and SIZE. The default sort-by value is NAME.

servlet-reload-check-secs

The <servlet-reload-check-secs> element defines whether a WebLogic Server will check to see if a servlet has been modified, and if it has been modified, reloads it. The -1 value tells the server never to check the servlets, 0 tells the server to always check the servlets, and the default is to check each 1 second.

A value specified in the console will always take precedence over a manually specified value.

single-threaded-servlet-pool-size

The <single-threaded-servlet-pool-size> element defines the size of the pool used for SingleThreadMode instance pools. The default value is 5.

session-monitoring-enabled

The <session-monitoring-enabled> element, if set to true, allows runtime MBeans to be created for sessions. When set to false, the default value, runtime MBeans are not created. A value specified in the console takes precedence over a value set manually.

save-sessions-enabled

The <save-sessions-enabled> element controls whether session data is cleaned up during redeploy or undeploy. It affects memory and replicated sessions. Setting the value to true means session data is saved. Setting to false means session data will be destroyed when the Web application is redeployed or undeployed. The default is false.

prefer-web-inf-classes

The <prefer-web-inf-classes> element, if set to true, will cause classes located in the WEB-INF directory of a Web application to be loaded in preference to classes loaded in the application or system classloader. The default value is false. A value specified in the console will take precedence over a value set manually.

default-mime-type

The <default-mime-type> element default value is null. This element allows the user to specify the default mime type for a content-type for which the extension is not mapped.

retain-original-url

Set the <retain-original-url> element to true to retain the HTTP in the original URL you are requesting prior to being forwarded to the authentication URL.

Once you login successfully using the authentication URL, you are then taken back to the exact URL that you had originally requested.

The <charset-params> element is used to define code set behavior for non-unicode operations. For example:

<charset-params>

<input-charset>

<resource-path>/*</resource-path>

<java-charset-name>UTF-8</java-charset-name>

</input-charset>

</charset-params>

input-charset

Use the <input-charset> element to define which character set is used to read GET and POST data. For example:

<input-charset>     <resource-path>/foo</resource-path>     <java-charset-name>SJIS</java-charset-name> </input-charset>

For more information, see Loading Servlets, Context Listeners, and Filters .

charset-mapping

Use the <charset-mapping> element to map an IANA character set name to a Java character set name. For example:

<charset-mapping>     <iana-charset-name>Shift-JIS</iana-charset-name>     <java-charset-name>SJIS</java-charset-name> </charset-mapping>

For more information, see Mapping IANA Character Sets to Java Character Sets .

Use the virtual-directory-mapping element to specify document roots other than the default document root of the Web application for certain kinds of requests, such as image requests. All images for a set of Web applications can be stored in a single location, and need not be copied to the document root of each Web application that uses them. For an incoming request, if a virtual directory has been specified servlet container will search for the requested resource first in the virtual directory and then in the Web application's original document root. This defines the precedence if the same document exists in both places.

<virtual-directory-mapping>

     <local-path>c:/usr/gifs</local-path>

     <url-pattern>/images/*</url-pattern>

     <url-pattern>*.jpg</url-pattern>

</virtual-directory-mapping>

     <local-path>c:/usr/common_jsps.jar</local-path>

     <url-pattern>*.jsp</url-pattern>

The WebLogic Server implementation of virtual directory mapping requires that you have a directory that matches the url-pattern of the mapping. The image example requires that you create a directory named images at c:/usr/gifs/images. This allows the servlet container to find images for multiple Web applications in the images directory.

Use this element to specify a class for URL pattern matching. The WebLogic Server default URL match mapping class is weblogic.servlet.utils.URLMatchMap, which is based on J2EE standards. Another implementation included in WebLogic Server is SimpleApacheURLMatchMap, which you can plug in using the url-match-map element.

Rule for SimpleApacheURLMatchMap:

If you map *.jws to JWSServlet then

http://foo.com/bar.jws/baz will be resolved to JWSServlet with pathInfo = baz.

Configure the URLMatchMap to be used in weblogic.xml as in the following example:

<url-match-map>

weblogic.servlet.utils.SimpleApacheURLMatchMap

</url-match-map>

The preprocessor element contains the declarative data of a preprocessor.

The following table describes the elements you can define within the preprocessor element.

The preprocessor-mapping element defines a mapping between a preprocessor and a URL pattern.

The following table describes the elements you can define within the preprocessor-mapping element.

The security-permission element specifies a single security permission based on the Security policy file syntax. Refer to the following URL for Sun's implementation of the security permission specification:

http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax

Disregard the optional codebase and signedBy clauses.

For example:

<security-permission-spec>

     grant { permission java.net.SocketPermission "*", "resolve" };

</security-permission-spec>

permission java.net.SocketPermission is the permission class name.

"*" represents the target name.

resolve indicates the action.

The context-root element defines the context root of this stand-alone Web application. If the Web application is part of an EAR, not stand-alone, specify the context root in the EAR's application.xml file. A context-root setting in application.xml takes precedence over context-root setting in weblogic.xml.

Note that this weblogic.xml element only acts on deployments using the two-phase deployment model. See Two-Phase Deployment in Deploying WebLogic Server Applications .

The order of precedence for context root determination for a Web application is as follows:

• Check application.xml for context root; if found, use as Web application's context root.
• If context root is not set in application.xml, and the Web application is being deployed as part of an EAR, check whether context root is defined in weblogic.xml. If found, use as Web application's context root. If the Web application is deployed standalone, application.xml does not come into play and the determination for context-root starts at weblogic.xml and defaults to URI if it is not defined there.
• If context root is not defined in weblogic.xml or application.xmll, then infer the context path from the URI, giving it the name of the value defined in the URI minus the WAR suffix. For instance, a URI MyWebApp.war would be named MyWebApp.

Use the wl-dispatch-policy element to assign the Web application to a configured execute queue by identifying the execute queue name.

Use the servlet-descriptor element to aggregate the servlet-specific elements.

This is an equivalent of <run-as> for init method for servlets.

<init-as>

<servlet-name>FooServlet</servlet-name>

<principal-name>joe</principal-name>

</init-as>

This is an equivalent of <run-as> for destroy method for servlets.

<destroy-as>

<servlet-name>BarServlet</servlet-name>

<principal-name>bob</principal-name>

</destroy-as>