security role assignment weblogic

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 reboot 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, that 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 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.

Action	Description
Add Condition	Adds a new condition to the policy. You can choose to add the new condition above or below another condition.
Combine	When multiple conditions are selected, you can combine them to create a compound condition.
Uncombine	When a compound condition is selected, you can break it into independent conditions.
Remove	Deletes a simple or compound condition from the policy. When there are no conditions in a policy, the default policy will apply.
Negate	Reverses the meaning of a condition. The criteria to access a resource becomes the opposite of the original condition.
Reset	Reverts the policy to its last change, not the last change. It’s recommended that you save your policy frequently or you may unintentionally lose several changes using the Reset action.

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 reboot 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>



		elements to map principals to a role. For more information on security realms, see the .

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


		returns cookies to any server in the domain. or is invalid.
		. You may provide a more specific name for your application.
		, the cookie expires when the user exits the browser.
		if unset. You may set this to a more specific name for your application.
		(slash), where the browser sends cookies to all URLs served by WebLogic Server. You may set the path to a narrower mapping, to limit the request URLs to which the browser sends cookies.
		. You might turn this option off to test on your site.

		to , this parameter sets the directory path where WebLogic Server will store the sessions. The directory path is either relative to the temp directory or an absolute path. The temp directory is either a generated directory under the directory of the Web Application, or a directory specified by the context-param . multiplied by the . You can find the size of a session by looking at the files created in the .
		.
		-disables persistent session storage -uses file-based persistence (See also , above) -uses a database to store persistent sessions. (see also , above) -same as , but session data is replicated across the clustered servers
		limit has been reached.


		element (defined in minutes) in . For more information, see .


		.

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


	, or the Java compiler defined for a server under the configuration /tuning tab of the WebLogic Server Administration Console	.

		or .)
		.
		, the intermediate Java files are deleted after they are compiled.
		exception when compiling, use this flag to allow the JSPs to compile correctly.

		, page checking and recompiling is disabled.
		, debugging information is printed out to the browser, the command prompt, and WebLogic Server log file.

© 2000 BEA Systems, Inc. All rights reserved.
Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.

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

Install App

Application Development Software

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

Security in weblogic.xml

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, 2024

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.

リリース1 (12.1.1)
B65890-02

B weblogic.xmlデプロイメント記述子の要素

このドキュメントでは、WebLogic Server固有のデプロイメント記述子 weblogic.xml の要素に関する詳細なリファレンスを提供します。お使いのWebアプリケーションに weblogic.xml デプロイメント記述子が含まれていない場合、WebLogic Serverによってこのデプロイメント記述子の要素にデフォルトの値が自動的に選択されます。

次の各項では、 weblogic.xml デプロイメント記述子でルート要素 weblogic-web-app の下に定義できる複合的なデプロイメント記述子要素について説明します。

weblogic.xmlのネームスペース宣言とスキーマの場所

Description, weblogic-version, security-role-assignment, run-as-role-assignment, resource-description, resource-env-description, ejb-reference-description, service-reference-description, session-descriptor, jsp-descriptor, auth-filter, container-descriptor, charset-params, virtual-directory-mapping, url-match-map, security-permission, context-root, wl-dispatch-policy, servlet-descriptor, work-manager, library-ref, async-descriptor, async-work-manager, webコンテナのグローバル構成.

WebLogic Serverの weblogic.xml ファイルのネームスペース宣言とスキーマの場所を表す正確なテキストは次のとおりです。

weblogic.xml のスキーマについては、 http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd を参照してください。

description 要素は、Webアプリケーションの説明文です。

weblogic-version 要素は、(ルート要素 weblogic-web-app 内に定義されている)当該Webアプリケーションのデプロイ先となるWebLogic Serverのバージョンを示します。この要素は参照用で、現在WebLogic Serverでは使用されていません。

security-role-assignment 要素は、Webアプリケーションのセキュリティ・ロールとWebLogic Serverの1つまたは複数のプリンシパルとのマッピングを宣言します。次に例を示します。

この要素を使用すると、次の例のように、特定のロールを外部定義されたロールとしてマークすることもできます。

注意:

要素には、またはのどちらかが定義されている必要があります。この両方を省略することはできません。

次の表では、 security-role-assignment 要素内で定義できる要素について説明します。

表B-1 security-role-assignment要素

要素	必須/省略可能	説明
	必須	セキュリティ・ロール名を指定します。
	が定義されていない場合、必須	セキュリティ・レルムで定義されるプリンシパルの名前を指定します。複数の要素を使用して、複数のプリンシパルを1つのロールにマップできます。セキュリティ・レルムの詳細は、『Oracle WebLogic Serverの保護』を参照してください。
	が定義されていない場合、必須	特定のセキュリティ・ロールがセキュリティ・レルムでグローバルに定義されていることを指定します。WebLogic Serverでは、このセキュリティ・ロールをグローバル・レルム内でルックアップするのではなくプリンシパル名として使用します。セキュリティ・ロールとprincipal-nameのマッピングが別の場所で定義されている場合、これは暗示的なプレースホルダーとして使用されます。

security-role-assignment 要素およびその下位要素を定義していない場合は、Webアプリケーション・コンテナによってロール名がプリンシパル名として暗黙的にマップされ、ログに警告メッセージが出力されます。マッピングが定義されていないと、EJBコンテナはモジュールをデプロイしません。

以下に、ロール名が「role_xyz」の場合の使用例を示します。

weblogic.xml で「role_xyz」をユーザー「joe」にマップすると、role_xyzがローカル・ロールになります。

role_xyzを外部定義されたロールとして指定すると、これがグローバルになります(レルム・レベルで定義されたロールを参照します)。

security-role-assignment 要素を定義しないと、role_xyzがローカル・ロールになります。この場合、Webアプリケーション・コンテナによって暗黙的なマッピングが作成され、ログに警告メッセージが出力されます。

run-as-role-assignment 要素は、 web.xml の run-as ロール名( servlet 要素の下位要素)をシステムの有効なユーザー名にマップします。この値は、 servlet-descriptor の run-as-principal-name 要素によって任意のサーブレットについてオーバーライドできます。ロール名の run-as-role-assignment がない場合は、Webアプリケーション・コンテナにより security-role-assignment に定義されている最初の principal-name が使用されます。次の例に、 run-as-role-assignment 要素の使用方法を示します。

次の表では、 run-as-role-assignment 要素内で定義できる要素について説明します。

表B-2 run-as-role-assignment要素

要素	必須/省略可能	説明
	必須	セキュリティ・ロール名を指定します。
	必須	プリンシパルの名前を指定します。

resource-description 要素は、サーバー・リソースのJNDI名を、WebLogic ServerのEJBリソースの参照にマップするために使用されます。

次の表では、 resource-description 要素内で定義できる要素について説明します。

表B-3 resource-description要素

要素	必須/省略可能	説明
	必須	リソース参照名を指定します。
	必須	リソースのJNDI名を指定します。

resource-env-description 要素は、 ejb-jar.xml デプロイメント記述子で宣言された resource-env-ref を、それが表しているサーバー・リソースのJNDI名にマップします。

次の表では、 resource-env-description 要素内で定義できる要素について説明します。

表B-4 resource-env-description要素

要素	必須/省略可能	説明
	必須	リソース環境参照名を指定します。
	必須	リソース環境参照のJNDI名を指定します。

次の表では、 ejb-reference-description 要素内で定義できる要素について説明します。

表B-5 ejb-reference-description要素

要素	必須/省略可能	説明
	必須	Webアプリケーションで使用するEJB参照の名前を指定します。
	必須	参照のJNDI名を指定します。

次の表では、 service-reference-description 要素内で定義できる要素について説明します。

表B-6 service-reference-description要素

要素	必須/省略可能	説明


		要素には次の下位要素があります。
		要素には次の下位要素があります。

session-descriptor 要素には、サーブレット・セッションのパラメータを定義します。

表B-7 session-descriptor

要素名	デフォルト値	値
		WebLogic Serverでセッションをタイムアウトするまでに待機する時間を秒単位で指定します。デフォルト値は3600秒です。トラフィックの多いサイトでは、セッションのタイムアウトを調整すると、アプリケーションの動作を最適化できます。ブラウザ・クライアントでいつでもセッションを終了できるようにする必要がある場合でも、ユーザーがサイトを離れるか、ユーザーのセッションがタイムアウトになれば、サーバーに接続する必要はなくなります。この属性は、の要素(分単位で定義)によってオーバーライドされる可能性があります。
		WebLogic Serverが、タイムアウトの無効なセッションに対してハウス・クリーニング・チェックを実行してから古いセッションを削除してメモリーを解放するまでの待機時間を秒単位で設定します。この要素を使用して、トラフィックの多いサイトでWebLogic Serverのパフォーマンスが最適化されるようにチューニングします。デフォルト値は60秒です。
		アプリケーション・レベルでこの値をに設定した場合、複数のWebアプリケーションでHTTPセッションを共有できます。 Webアプリケーション・レベルで有効になっている場合、この要素は無視されます。
		HTTPセッションのデバッグ機能を有効にします。デフォルト値はです。
		セッションIDのサイズを設定します。最小値は8バイト、最大値はで指定した値。 WAPアプリケーションを作成する場合、WAPプロトコルはCookieをサポートしていないため、URLを書き換える必要があります。また、一部のWAPデバイスでは、URLの長さに128文字(属性も含む)の制限があり、URL書換えで転送できるデータ・サイズが限られます。属性用の領域を確保するには、WebLogic Serverでランダムに生成されるセッションIDのサイズをこの属性で制限します。 WAPEnabled属性を設定して、長さを52文字までに制限し、特殊文字の使用を禁止することもできます。詳細は、を参照してください。
		HTTPリクエスト間のセッション・トラッキングを有効にします。
		JDBCとファイル永続セッションのキャッシュ・サイズを設定します。
		メモリー/レプリケートされたセッションの最大セッション数を設定します。メモリー内で使用できるサーブレット・セッションの上限数を構成する機能がない場合、新しいセッションが作成され続けると、最終的にはサーバーでメモリー不足となります。これを回避するため、WebLogic Serverでは作成されるセッション数に対して、構成可能な制限を設けています。この数を超えると、新しいセッションの作成が試行されるたびに、が発生します。この機能は、レプリケートされたインメモリー・セッションと、レプリケートされないインメモリー・セッションの双方に適用されます。メモリー内で使用できるサーブレット・セッションの上限を構成するには、この要素に上限値を設定します。デフォルトは (無制限)。負の値を指定してもと同じ無制限になります。
		セッションCookieの使用はデフォルトで有効になっているが(推奨)、このプロパティをに設定して無効にすることも可能です。テストのためにこのオプションをオフにする場合もあります。
		セッション・トラッキングCookieの名前を定義します。設定しない場合、デフォルトは。アプリケーションに対して、より詳細な名前を指定できます。
		セッション・トラッキングCookieのパスを定義します。この属性を設定しない場合、デフォルトは (スラッシュ)。デフォルト値では、ブラウザは、WebLogic Serverで指定されているすべてのURLにCookieを送信します。マップ対象を絞り込んだパスを設定し、リクエストURLを、ブラウザがCookieを送信するものに限定できます。
		Cookieが有効になるドメインを指定します。たとえば、をに設定すると、ドメイン内のすべてのサーバーにCookieが返されます。ドメイン名には少なくとも2つのコンポーネントが必要です。名前をまたはに設定すると無効になります。この属性を設定しない場合、デフォルトは、Cookieを発行したサーバーのドメイン。詳細は、Servlet仕様のを参照してください。
		Cookieファイル内のセッション・トラッキングを行うCookieを識別するコメントを指定します。
		CookieをHTTPS接続でのみ返信するようブラウザに指示します。これにより、Cookie IDが保護され、HTTPSを使用するWebサイトでのみ使用されるようになります。この機能を有効にすると、HTTPでのセッションCookieは機能しなくなります。この機能を使用する場合、要素は無効にする必要があります。
		セッションCookieの存続期間を秒単位で設定します。時間が経過すると、Cookieはクライアントで期限切れになります。任意の整数を設定可能です。デフォルト値は -1 (無制限)。 Cookieの詳細は、を参照してください。
		永続ストレージの方法を次のいずれかに設定します。 - 永続セッション・ストレージを無効にします。 - と同じですが、セッション・データはクラスタリングされたサーバー間でレプリケートされます。 - Webアプリケーションがクラスタリングされているサーバーにデプロイされている場合は、有効ながレプリケートされます。それ以外の場合は、がデフォルトです。 - アプリケーションまたはWeb Applicationで非同期セッションのレプリケーションができます。『Oracle WebLogic Serverパフォーマンスおよびチューニング』の非同期HTTPセッションのレプリケーションに関する項を参照してください。 - クラスタ環境にデプロイされる場合、アプリケーションまたはWebアプリケーションで非同期セッション・レプリケーションを有効にします。単一のサーバー環境にデプロイされる場合、セッションの永続性/レプリケーションはデフォルトでインメモリーになります。これにより、デプロイメント・エラーなしで単一サーバーでのテストが可能になります。 - ファイル・ベースの永続性を使用します( も参照)。 - アプリケーションまたはWebアプリケーションでHTTPセッションの非同期JDBC永続性を有効にします。を参照してください。 - データベースを使用して永続セッションを格納します( も参照)。 - すべてのセッション・データはユーザーのブラウザ内のCookieに格納されます。
		Cookieベースの永続性に使用するCookieの名前を設定します。 Cookieはセッション状態を保持します - これは、Webアプリケーション間で共有されないことが必要です。詳細は、を参照してください。
		ファイル・ベースの永続化に使用されるストレージ・ディレクトリを指定します。各セッションのサイズに有効なセッション数をかけたサイズを保存できるのみのディスク・スペースを確保する必要があります。セッションのサイズはに作成されているファイルで確認できます。各セッションのサイズは、シリアライズされたセッション・データの変更のサイズによって異なります。各サーバー・インスタンスには、構成不要なデフォルトの永続ファイル・ストアがあります。したがって、ディレクトリが指定されていない場合は、デフォルトのストアが server-name ディレクトリに自動的に作成されます。ただし、デフォルトのストアをクラスタリングされたサーバーの間で共有することはできません。複数サーバー間で共有しているディレクトリにカスタム永続ストアを作成すると、ファイル永続セッションをクラスタリング可能にできます。ただし、その場合はこのディレクトリを手動で作成する必要があります。
		永続ストレージに使用されるJDBC接続プールの名前を指定します。
		JDBCベースの永続セッションの保存に使用するデータベース表名を指定します。これはがjdbcに設定されている場合にのみ適用されます。要素は、デフォルト以外のデータベース表名を選択した場合にのみ使用されます。
		列名の代替名として使用されます。この要素はJDBCベースの永続性にのみ適用されます。長い列名をサポートしていないデータベースでは必須です。
		注意:この要素はこのリリースでは非推奨です。 WebLogic ServerがJDBC接続をタイムアウトするまでの待機時間を秒単位で設定します(秒数)。
		URL書換えを有効にします。これによって、セッションIDがURLにエンコーディングされ、Cookieがブラウザで無効の場合にセッション・トラッキングが実行されます。
		に設定されている場合、レスポンスにはヘッダーが以下のように追加されます。 "Cache-control: no-cache=set-cookie" これは、プロキシ・キャッシュでCookieがキャッシュされないことを示します。
		最新のサーブレットの仕様では、パス・パラメータでセッションIDをエンコードするためにコンテナが必要です。特定のWebサーバーは、パス・パラメータを使用して機能しません。このような場合、要素をに設定する(デフォルトは )。
		で使用されます。ので返されるセッション属性の値で、この要素の文字列がキーとして使われます。例: この要素は、様々なセッションのセッション実行時情報をタグ付けする場合に役立ちます。
		のCookieが有効になっているかを指定します。この要素は、に設定されている場合、すべてのCookieがブラウザ・スクリプトに対して、無効になります。デフォルト値はです。デフォルトでは、のCookieが有効になっています。

jsp-descriptor 要素には、JSPコンパイラの構成パラメータのリストを指定します。次の表で、 jsp-descriptor 要素内に定義できる要素について説明します。

表B-8 jsp-descriptor要素

要素	デフォルト値	説明
		JSPファイルが変更されたために再コンパイルする必要があるかどうかをチェックする間隔を秒単位で設定します。変更されている場合は、依存関係もチェックされ、再帰的に再ロードされます。の場合、ページのチェックは行われません。これは、本番環境でのデフォルト値です。の場合、ページは常にチェックされます。の場合、ページは毎秒チェックされます。この値は、開発環境でのデフォルト値です。 JSPを変更することが稀な本番環境では、チューニング要件に応じて、pageCheckSecondsの値を60以上に設定することを検討してください。
		展開されたWARにのみ適用されます。更新されたJSPファイルがチェックされます。つまり、ファイルのタイムスタンプがビルド時のタイムスタンプよりも後(新しい)かどうかがチェックされます。新しいファイルが古いファイルを置換できるのみです。 falseに設定した場合は、タイムスタンプが変更されたかどうかのみがチェックされます。変更されていれば、ファイルが置換されます。
		trueに設定すると、Webアプリケーションのデプロイ(再デプロイ)時またはWebLogic Serverの起動時に、変更されたすべてのJSPが自動的にあらかじめコンパイルされます。
		trueに設定すると、いずれかのJSPのコンパイルに失敗しても、変更されたすべてのJSPがプリコンパイルされます。precompileがtrueに設定されている場合にのみ有効です。
		JSPコンパイル・プロセスの間に生成されるJavaファイルを保存します。このパラメータをに設定しない限り、中間生成されたJavaファイルはコンパイル後に削除されます。
		に設定すると、デバッグ情報がブラウザ、コマンド・プロンプト、およびWebLogic Serverログ・ファイルに出力されます。
		WebLogic Serverが、JSP用に生成されたJavaとコンパイル済みのクラス・ファイルを保存するディレクトリの名前。注意: でが定義されている場合、Webアプリケーションがアンデプロイされても、WebLogic Serverはこのディレクトリを削除しません。
		falseに設定すると、"null"を含む式は" "として出力されます。
		に設定すると、下位互換性が有効になります。詳細は、を参照してください。
		JSPページで使用されるデフォルトの文字セットを指定します。標準のJava文字セット名を使用します( を参照)。この属性を設定しない場合、デフォルトはユーザーのプラットフォームのエンコーディング。 JSPコードに含まれるJSPページ・ディレクティブはこの設定をオーバーライドします。例:
		すべてのJSPページのコンパイル先となるパッケージの接頭辞を指定します。
		trueの場合、JSPの最初のリクエスト時に新しく作成されるJspStubが正確なリクエストにマップされます。exactMappingがfalseに設定されている場合、Webアプリケーション・コンテナはJSP用に正確ではないurlマッピングを生成します。はJSPページのパス情報を提供します。
		JSP用の生成済みJavaおよびコンパイル済みクラス・ファイルを保存するファイルのデフォルト名。
		タグのname属性に実行時の式の値を指定できるようにします。デフォルトではに設定されます。
		trueの場合、JSPコンパイラによりJava式が最適化され実行時のパフォーマンスが改善されます。
		trueの場合、JSPテンプレート・ブロック内のHTMLが圧縮され実行時のパフォーマンスが改善されます。 JSPのHTMLテンプレート・ブロックに HTMLタグが含まれる場合は、この機能を有効にしないでください。

auth-filter 要素は、認証フィルタのHttpServletクラスを指定します。

注意:

この要素は現在のリリースでは非推奨とされています。かわりにサーブレット認証フィルタを使用してください。

container-descriptor 要素には、Webアプリケーションの動作に影響するパラメータのリストを指定します。

check-auth-on-forward

サーブレットまたはJSPから転送されたリクエストの認証を必須にする場合は、 check-auth-on-forward 要素を追加します。再認証を必要としない場合、このタグは省略します。例:

注意:

ベスト・プラクティスとして、プロパティを無効にしておくことをお薦めします。

filter-dispatched-requests-enabled

filter-dispatched-requests-enabled 要素は、ディスパッチされたリクエストにフィルタを適用するかどうかを制御します。デフォルト値は false です。

注意:

(2.4仕様によると)2.4サーブレットは2.3サーブレットと下位互換性があるため、2.3の記述子要素がWebLogic Serverで検出された場合、要素のデフォルトはになります。

redirect-with-absolute-url

redirect-with-absolute-url 要素は、 javax.servlet.http.HttpServletResponse.SendRedirect() メソッドでのリダイレクトに相対URLと絶対URLのどちらを使用するかを制御します。プロキシHTTPサーバーを使用しており、URLを非相対リンクに変換したくない場合は、この要素を false に設定します。

デフォルトの動作では、URLが非相対リンクに変換されます。

注意:

リダイレクトで使用されるユーザーが読めるデータ。

index-directory-enabled

index-directory-enabled 要素は、適切な索引ファイルが見つからない場合にHTMLディレクトリのリストを自動的に生成するかどうかを制御します。

デフォルト値は false です(ディレクトリは生成されません)。値は true または false です。

index-directory-sort-by

index-directory-sort-by 要素は、 weblogic.servlet.FileServlet で生成されるディレクトリ・リストのソート順序を定義します。有効なsort-by値は、 NAME 、 LAST_MODIFIED 、および SIZE です。デフォルトのsort-by値は NAME です。

servlet-reload-check-secs

servlet-reload-check-secs 要素は、サーブレットが変更されたかどうかをWebLogic Serverがチェックして、変更されていた場合に再ロードするかどうかを定義します。

値 -1 の場合、サーブレットのチェックは行われません。これは、本番環境でのデフォルト値です。

値 0 の場合、サーブレットは常にチェックされます。

値 1 の場合、サーブレットは毎秒チェックされます。この値は、開発環境でのデフォルト値です。

管理コンソールで指定する値は、手動で設定する値よりも常に優先されます。

resource-reload-check-secs

resource-reload-check-secs 要素は、Webアプリケーション・スコープのリソース・パスで見つかったキャッシュされたリソースに対してメタデータ・キャッシングを実行する場合に使用します。このパラメータでは、リソースが変更されているかどうかをチェックして変更されていた場合に再ロードを行う頻度を特定します。

値 -1 の場合、再ロードは行われません。これは、本番環境でのデフォルト値です。

値 0 の場合、常に再ロードが行われます。

値 1 の場合、毎秒再ロードが行われます。この値は、開発環境でのデフォルト値です。

このパラメータの値としては管理コンソールを使用して指定したものに優先権が与えられます。

注意:

要素でが指定されている場合、の値がの値をオーバーライドします。

single-threaded-servlet-pool-size

single-threaded-servlet-pool-size 要素は、 SingleThreadMode インスタンス・プールに使用されるプールのサイズを定義します。デフォルト値は 5 です。

注意:

インスタンス・プールは、このリリースでは非推奨とされています。

session-monitoring-enabled

session-monitoring-enabled 要素をtrueに設定すると、セッションに対してランタイムMBeanを作成できます。デフォルト値の false に設定すると、ランタイムMBeansは作成されません。管理コンソールで指定した値は、手動で設定する値よりも優先されます。

save-sessions-enabled

save-sessions-enabled 要素は、再デプロイまたはアンデプロイ時にセッション・データをクリーン・アップするかどうかを制御します。これはメモリーとレプリケート・セッションに影響します。値をtrueに設定すると、セッション・データは保存されます。falseに設定すると、Webアプリケーションが再デプロイまたはアンデプロイされるときにセッション・データは破棄されます。デフォルトは false です。

prefer-web-inf-classes

prefer-web-inf-classes 要素をtrueに設定すると、Webアプリケーションの WEB-INF ディレクトリにあるクラスが、アプリケーションまたはシステム・クラスローダー内にロードされたクラスに優先してロードされます。デフォルト値は false です。管理コンソールに指定した値は、手動で設定する値よりも優先されます。

注意:

内でが有効になっている場合、もも指定できません。

prefer-application-packages

prefer-application-packages 要素は、常にアプリケーションからロードする必要のあるクラスに対してパッケージ・リストを指定します。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の prefer-application-packages に関する項を参照してください。

prefer-application-packages または prefer-application-resources を使用するためには、 prefer-web-inf-classes をfalseに設定する必要がありますので注意してください。

prefer-application-resources

prefer-application-resources 要素は、リソースがシステム・クラスローダーにある場合を含め、常にアプリケーションからロードする必要があるリソースのリストを指定します。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の prefer-application-resources に関する項を参照してください。

default-mime-type

default-mime-type 要素のデフォルト値は null です。この要素を使用すると、拡張がマップされていないcontent-typeのデフォルトのMIMEタイプを指定できます。

client-cert-proxy-enabled

client-cert-proxy-enabled 要素のデフォルト値は true です。trueの場合、WebLogic ServerによってクライアントからのID証明書がバックエンドのサーバーに渡されます。また、受信したWL-Proxy-Client-Certヘッダーを受け入れるのか、破棄するのかがWebLogic Serverに通知されます。

WL-Proxy-Client-Certヘッダーの各ID証明書はプロキシ・サーバー・プラグインによってエンコードされ、バックエンドのWebLogic Serverインスタンスに渡されます。各WebLogic Serverインスタンスでは、このヘッダーから証明書情報を受け取り、安全なソースに由来するものであると確認してから、その証明書情報でユーザーを認証します。バックグラウンドのWebLogic Serverインスタンスでは、このパラメータが(クラスタ、サーバーまたはWebアプリケーションのレベルで) true に設定されている必要があります。

この要素を true に設定する場合、weblogic.security.net.ConnectionFilterを使用して、各WebLogic Serverインスタンスで確実に、プロキシ・サーバー・プラグインが実行されているマシンからの接続のみを受け付けるようにします。 true を指定した場合に接続フィルタを使用しないとWL-Proxy-Client-Certヘッダーのなりすましが可能になるため、セキュリティに脆弱性が生じるおそれがあります。

relogin-enabled

relogin-enabled 要素は下位互換性のためのパラメータです。すでにログインしているユーザーが権限を持たないリソースにアクセスしようとすると、 FORBIDDEN (403) レスポンスが発生します。

allow-all-roles

Webアプリケーションの web.xml 記述子に定義されているsecurity-constraints要素の中では、 auth-constraint 要素が、当該リソース・コレクションへのアクセスを許可する必要があるユーザー・ロールを示します。role-name = "*"とすると、Webアプリケーション内のすべてのロールを示す構文を簡単に記述できます。なお、role-name = "*"は以前のリリースでは、レルム内に定義されているすべてのユーザーおよびロールを示すものとして扱われていました。

この allow-all-roles 要素は、以前の動作に戻すための下位互換性スイッチです。デフォルトの動作では、Webアプリケーションに定義されているすべてのロールが許可されます。 weblogic.xml に指定されている値が、 WebAppContainerMBean に定義されている値よりも優先されます。

native-io-enabled

weblogic.servlet.FileServlet (暗黙的に登録されているデフォルトのサーブレット)で静的ファイルを提供しているときにネイティブI/Oを使用するには、 native-io-enabled を true に設定します。(デフォルト値は false です。) native-io-enabled 要素はWindows上でのみ適用されます。

minimum-native-file-size

minimum-native-file-size 要素は native-io-enabled が true に設定されている場合にのみ適用されます。この要素には、ネイティブI/Oを使用する際の最小ファイル・サイズをバイト単位で指定します。提供するファイルのサイズがこの値よりも大きいと、ネイティブI/Oが使用されます。この値を設定しない場合、デフォルト値として 4000 が使用されます。

disable-implicit-servlet-mappings

disable-implicit-servlet-mappings フラグが true に設定されている場合、Webアプリケーション・コンテナでは内部サーブレット( *.jsp 、 *.class など)の暗黙的なマッピングが作成されず、デフォルト・サーブレットのマッピングのみが作成されます。通常、暗黙的なサーブレット・マッピングを無効にするのは、 HttpClusterServlet や HttpProxyServlet を構成している場合です。

デフォルト値は false です。

temp-dir 要素は、 "javax.servlet.context.tempDir" 属性で戻されるように、Webアプリケーション用の一時ディレクトリの場所を指定します。

optimistic-serialization

optimistic-serialization が有効になっている場合、リクエストがサーブレット・コンテキストを超えてディスパッチされるときに getAttribute(name) のコンテキストとリクエスト属性はシリアライズおよびデシリアライズされません。

つまり、複数のWebアプリケーションに共通する属性は、共通の親クラスローダーにスコープ指定するか(アプリケーション・スコープ指定)、2つのWebアプリケーションが同じアプリケーションに属していない場合はシステムのクラスパスに配置する必要があります。

optimistic-serialization がオフ(デフォルト値)になっている場合、WebLogic ServerはClassCastExceptionの発生を回避するために getAttribute(name) のコンテキストおよびリクエストの属性をシリアライズおよびデシリアライズします。

optimistic-serialization 値は、 WebAppContainerMBean でドメイン・レベルで指定することもでき、その場合すべてのWebアプリケーションに適用されます。 weblogic.xml に値を指定した場合、その値によってドメイン・レベルの値がオーバーライドされます。

show-archived-real-path-enabled

show-archived-real-path-enabled 要素は、アーカイブされたWebアプリケーションの getRealPath() の動作を指定します。

true に設定されている場合、 getRealPath() はリソース・ファイルの標準のパスを戻します。

show-archived-real-path-enabled 要素が false に設定されている場合、サーブレット・コンテナは、アーカイブされたWebアプリケーションのファイルのフルパスを null として戻します。

require-admin-traffic

require-admin-trafffic 要素は、トラフィックが管理チャネルを通過する必要があるかどうかを定義します。 true に設定すると、トラフィックが管理チャネルを通過できます。それ以外の場合、トラフィックが管理チャネルを通過できるのは、Webアプリケーションが管理モードにある場合のみです。例:

access-logging-disabled

access-logging-disabled 要素は、基底のWebアプリケーションのアクセス・ロギングを無効にするかどうかを定義します。このプロパティを true に設定すると、ロギングのオーバーヘッドが小さくなり、サーバーのスループットが改善されます。このプロパティを指定しないか false に設定すると、アプリケーションのアクセスがロギングされます。

prefer-forward-query-string

転送リクエストで HttpServletRequest.getQueryString() が呼び出されたとき、WebLogic Serverは、RequestDispatcher経由で転送サーブレットによって送信されたqueryStringとクライアントによって送信されたオリジナルなqueryStringを戻します。

prefer-forward-query-string フラグを true に設定した場合、WebLogic Serverは、転送された問合せ文字列が指定されている場合、それのみを戻します。デフォルト値は false です。

charset-params 要素は、Unicode以外の処理のコード・セット動作を定義するために使用します。例:

input-charset

input-charset 要素を使用して、 GET データと POST データの読取りに使用する文字セットを定義します。例:

詳細は、「HTTPリクエストのエンコーディングの識別」を参照してください。

次の表では、 input-charset 要素内で定義できる要素について説明します。

表B-9 input-charset要素

要素	必須/省略可能	説明
	必須	このパスがリクエストのURLに含まれている場合、で指定されているJava文字セットを使用するようにWebLogic Serverに指示されます。
	必須	使用するJava文字セットを指定します。

charset-mapping

charset-mapping 要素を使用して、IANA文字セット名をJava文字セット名にマップします。例:

詳細は、「IANA文字セットのJava文字セットへのマッピング」を参照してください。

次の表では、 charset-mapping 要素内で定義できる要素について説明します。

表B-10 charset-mapping要素

要素	必須/省略可能	説明
	必須	要素で指定されたJava文字セットにマップされるIANA文字セット名を指定します。
	必須	使用するJava文字セットを指定します。

virtual-directory-mapping リクエストは、特定の種類のリクエスト(画像のリクエストなど)用に、Webアプリケーションのデフォルト・ドキュメント・ルート以外のドキュメント・ルートを指定するために使用します。Webアプリケーション・セット用のすべての画像は単一の場所に格納でき、それらを使用する各Webアプリケーションのドキュメント・ルートにコピーする必要がありません。リクエストを受信した場合、仮想ディレクトリが指定されていれば、サーブレット・コンテナは要求されたリソースをまず仮想ディレクトリで検索し、次にWebアプリケーションのデフォルト・ドキュメント・ルートで検索します。これにより、同じドキュメントが両方の場所に存在する場合の優先順位が決まります。

次の表では、 virtual-directory-mapping 要素内で定義できる要素について説明します。

表B-11 virtual-directory-mapping要素

要素	必須/省略可能	説明
	必須	ディスク上の物理位置を指定します。
	必須	マッピングのURLパターンを含みます。Servlet API仕様の11.2項で指定されているルールに準拠している必要があります。

仮想ディレクトリ・マッピングのWebLogic Server実装では、マッピングのurl-patternに一致するディレクトリが必要です。上記の画像の例であれば、 c:/usr/gifs/images にimagesというディレクトリを作成する必要があります。これにより、サーブレット・コンテナがimagesディレクトリにある複数のWebアプリケーションの画像を見つけることが可能になります。

この要素は、URLパターン・マッチング用のクラスを指定するために使用します。WebLogic ServerのデフォルトURLマッチ・マッピング・クラスは、Java EE仕様に基づいた weblogic.servlet.utils.URLMatchMap です。また、WebLogic Serverには SimpleApacheURLMatchMap も実装されています。これは、 url-match-map 要素を使用してプラグインできます。

SimpleApacheURLMatchMap のルールを示します。

*.jws を JWSServlet にマップする場合、

http://foo.com/bar.jws/baz は pathInfo = baz を使用して JWSServlet に解決されます。

次の例に示すように、使用する URLMatchMap を weblogic.xml で構成します。

security-permission 要素は、セキュリティ・ポリシー・ファイル構文に基づいて単一のセキュリティ権限を指定します。セキュリティ権限仕様の実装については、 http://download.oracle.com/javase/1.3/docs/guide/security/PolicyFiles.html#FileSyntax を参照してください。

オプションの codebase および signedBy 句は無視してください。

permission java.net.SocketPermission は許可・クラス名。

"*" はターゲット名。

resolve はアクション。

context-root 要素は、このスタンドアロンWebアプリケーションのコンテキスト・ルートを定義します。WebアプリケーションがスタンドアロンではなくEARの一部の場合、EARの META-INF/application.xml ファイルにコンテキスト・ルートを指定します。 application.xml の context-root 設定は、 weblogic.xml の context-root 設定より優先します。

この weblogic.xml 要素は、2フェーズ・デプロイメント・モデルを使用するデプロイメントに対してのみ有効に機能します。

Webアプリケーションのコンテキスト・ルートの優先順位は次のとおりです。

application.xml のコンテキスト・ルートがチェックされ、見つかった場合はこれがWebアプリケーションのコンテキスト・ルートとして使用されます。

コンテキスト・ルートの設定が application.xml になく、WebアプリケーションがEARの一部としてデプロイされる場合、コンテキスト・ルートが weblogic.xml に定義されているかどうかがチェックされます。見つかった場合、これがWebアプリケーションのコンテキスト・ルートとして使用されます。Webアプリケーションがスタンドアロンとしてデプロイされる場合、 application.xml は使用されず、コンテキスト・ルートのチェックは weblogic.xml で開始されます。このファイルに定義されていない場合、デフォルトによってURIが使用されます。

コンテキスト・ルートが weblogic.xml と application.xml のどちらにも定義されていない場合、コンテキスト・パスはURIから推定され、URIに定義されている値からWAR接尾辞を取り除いた名前が付けられます。たとえば、URIが MyWebApp.war の場合は、 MyWebApp という名前が付けられます。

注意:

要素をEARライブラリ内の個々のWebアプリケーションに対して設定することはできません。Webアプリケーション・ライブラリに対してのみ設定できます。

wl-dispatch-policy 要素を使用して、ワーク・マネージャ名を指定し、Webアプリケーションを構成されたワーク・マネージャに割り当てます。このWebアプリケーション・レベルのパラメータは、 per-servlet-dispatch-policy 要素を使用して個々のサーブレットやJSPレベルでオーバーライドできます。

servlet-descriptor 要素を使用して、サーブレット固有の要素を集約します。

次の表では、 servlet-descriptor 要素内で定義できる要素について説明します。

表B-12 servlet-descriptor要素

要素	必須/省略可能	説明
	必須	デプロイメント記述子ファイルのサーブレット要素に定義されたサーブレット名を指定します。
	省略可能	デプロイメント記述子に定義されたに対するプリンシパル名を含みます。
	省略可能	サーブレットのメソッドのと同じ。ここに指定するIDはシステムの有効なユーザー名である必要があります。を指定しない場合、コンテナは要素を使用します。
	省略可能	サーブレットのメソッドのと同じ。ここに指定するIDはシステムの有効なユーザー名である必要があります。を指定しない場合、コンテナは要素を使用します。
	省略可能	この要素は非推奨です。実行キュー名を指定して、ある特定のサーブレットを割り当てるために構成されたに使用します。この設定は、で定義したWebアプリケーション・レベルのディスパッチ・ポリシーをオーバーライドします。

work-manager 要素は weblogic-web-app 要素の下位要素です。 work-manager 要素の内部には以下の要素を定義できます。

表B-13 work-manager要素

要素	必須/省略可能	説明
	必須	ワーク・マネージャの名前を指定します。
	省略可能	以下の4つの要素から選択できます。 - アプリケーションのレスポンス時間リクエスト・クラスを定義します。レスポンス時間はgoal-ms属性にミリ秒単位で定義します。増分は((目標値 - T) Cr)/Rです - Tは平均スレッド使用時間、Rは到着率、Crはフェア・シェアよりもレスポンス時間目標値を優先するための係数です。 - フェア・シェア・リクエスト・クラスを定義します。フェア・シェアは、デフォルト・シェアに対する属性値の割合で定義されます。したがって、デフォルトは100です。増分はCf/(P R T)です - Pは割合、Rは到着率、Tは平均スレッド使用時間、Cfはフェア・シェアの優先順位をレスポンス時間目標値よりも低くするための係数です。 - コンテキスト・クラスを定義します。コンテキスト情報(現在のユーザーまたはそのロール、Cookie、作業領域などのフィールド)をサービス・クラス名にマッピングした複数のケースを指定して、コンテキストを定義します。 - リクエスト・クラス名を定義します。
	省略可能	以下の2つの要素から選択できます。 - 制約対象の作業セットのリクエストに割り当てられるスレッドの数を確保して、デッドロックを回避するために使用します。デフォルトはゼロ。min-threadsの値を1に設定すると、ピアから同期的に呼び出されるレプリケーション更新リクエストなどの場合に役立ちます。 - 要素の名前を定義します。
	省略可能	以下の2つの要素から選択できます。 - 制約対象の作業セットからのリクエストを実行する同時スレッドの数を制限します。デフォルトは無制限。たとえば、最大スレッド数が10に定義された制約を3つのエントリ・ポイントで共有するとします。このスケジューリング・ロジックでは、統合された3つのエントリ・ポイントからのリクエストを10個以下のスレッドで実行します。 - 要素の名前を定義します。
	省略可能	以下の2つの要素から選択できます。 - 制約を定義して、「制約対象の作業セット」と呼ばれるエントリ・ポイントのセットに適用できます。この容量に達した場合にのみ、サーバーはリクエストの拒否を開始します。デフォルトはゼロ。容量には、制約対象の作業セットからのすべてのリクエスト(キューにあるリクエストと実行中のリクエスト)が含まれます。この制約は、独自にフロー制御を行うJMSのようなサブシステムを主な対象としています。この制約は、グローバル・キューのしきい値とは無関係。 - 要素の名前を定義します。

logging 要素は weblogic-web-app 要素の下位要素です。 logging 要素の内部には以下の要素を定義できます。

表B-14 logging要素

要素	必須/省略可能	説明
	必須	ログ・ファイルの名前を指定します。ファイル名は絶対アドレスで指定する必要があります。
	省略可能	またはに対してログ・ライターが設定されているかどうかを示します。この要素をtrueに設定すると、またはから生成された出力は、要素で指定したファイルに送られます。この値を指定しないと、WebLogic Serverでは定義されているデフォルト値が使用されます。値の範囲: またはデフォルト値:
	省略可能	ファイルのローテーション・タイプを設定します。値は、です。 - ログ・ファイルがに指定したサイズに達すると、ファイル名がに変更されます。 - に指定した間隔で、ファイル名がに変更されます。ファイル名が変更されると、以後のメッセージはに指定した名前の新しいファイルに蓄積されます。 - メッセージは1つのファイルに蓄積されます。サイズが大きくなった場合、ファイルの内容を消去する必要があります。デフォルト値:
	省略可能	当該サーバー・インスタンスで、古いメッセージの保存用に作成するファイルの数を制限するかどうかを指定します。( でを指定する必要があります。)この制限に達すると、最も古いファイルが上書きされます。このオプションを有効にしない場合、新しいファイルが無限に作成されていくため、必要に応じてこれらのファイルを削除する必要があります。をに設定して有効にした場合、サーバーは変数を参照してログ・ファイルのローテーション方法を判断します。ローテーションでは、新しいファイルを作成するのではなく、既存のファイルがオーバーライドされます。をに設定すると、サーバーは同じログ・ファイルをオーバーライドしないで、多数のログ・ファイルを作成します。値の範囲: またはデフォルト値:
	省略可能	サーバーがログをローテーションする際に作成するログ・ファイルの最大数。この数には、現在のメッセージを格納するためにサーバーで使用されているファイルは含まれません。( を有効にする必要があります。) デフォルト値:
	省略可能	サーバーがログ・メッセージを別のファイルに移動するきっかけとなるサイズ( でを指定する必要があります。)ログ・ファイルが指定の最小サイズに到達すると、以後サーバーは、ファイル・サイズをチェックする際に、現在のログ・ファイルの名前をに変更し、それ以降のメッセージを保存するための新規ログ・ファイルを作成します。デフォルト値:
	省略可能	起動サイクル中にサーバーがログ・ファイルをローテーションするかどうかを指定します。値の範囲: またはデフォルト値:
	省略可能	ローテーションされたログ・ファイルが格納されるディレクトリ・パスを指定します。
	省略可能	ログ・ファイルの時間ベースのローテーション・シーケンスの開始時間で、フォーマットは (ここでは1 - 24)です。( でを指定する必要があります。)指定された時間に、現在のログ・ファイル名が変更されます。以後、で指定した間隔でログ・ファイル名が変更されます。指定した時間がすでに過ぎている場合、サーバーはただちにファイルのローテーションを開始します。デフォルトでは、ローテーション・サイクルはただちに開始されます。
	省略可能	古いログ・メッセージが別のファイルに移される間隔(単位は時間)。( でを指定する必要があります。) デフォルト値:

library-ref 要素では、現在のWebアプリケーションのWebアプリケーション・ライブラリとして使用されるライブラリ・モジュールを参照します。

Webアプリケーションに関連する下位要素は library-name 、 specification-version 、 implementation-version 、および exact-match のみです。

library-ref 要素の内部には以下の要素を定義できます。

表B-15 library-ref要素

要素	必須/省略可能	説明
	必須	ライブラリ・モジュールの参照用にライブラリの名前を提供します。デフォルト値は。
	省略可能	ライブラリ・モジュールの参照用に仕様のバージョンを提供します。デフォルト値はです。(これはfloatです。)
	省略可能	ライブラリ・モジュールの参照用に実装のバージョンを提供します。デフォルト値は。
	省略可能	デフォルト値はです。

次の表では、 fast-swap 要素内で定義できる要素について説明します。

FastSwapデプロイメントの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。

表B-16 fast-swap要素

要素

必須/省略可能

説明

省略可能

に設定すると、現在のアプリケーションでFastSwapデプロイメントが有効化されます。

省略可能

FastSwapによって、HTTPリクエストの受信時に、アプリケーション・クラスでの変更がチェックされます。秒以内に以降のHTTPリクエストを受信しても、変更はチェックされません。秒が経過して最初のHTTPリクエストの受信時に、クラスの変更チェックが再度実行されます。

省略可能

FastSwapのクラスの再定義は、再定義タスクによって非同期に行われます。再定義タスクは、JMXインタフェースを使用して制御および検査できます。

この要素では、FastSwapシステムで保持される再定義タスクの数を指定します。この制限をタスク数が超えると、古いタスクが自動的に削除されます。

async-descriptor 要素を使用して、Webアプリケーションの非同期処理動作を構成します。次の表では、 async-descriptor 要素内で定義できる要素について説明します。

表B-17 async-descriptor要素

要素

必須/省略可能

説明

省略可能

WebLogic Serverで非同期ジョブがタイムアウトになるまでに待機する時間を秒単位で設定します。デフォルト値は120秒です。

タイムアウトをに設定すると、非同期ジョブはタイムアウトになりません。

省略可能

WebLogic Serverでタイムアウト・ジョブのチェックを行う間隔の待機時間を秒単位で設定します。デフォルト値は30秒です。

async-work-manager 要素を使用して、非同期ジョブ( AsyncContext dispatch メソッドを使用して開始される非同期ディスパッチや、 AsyncContext start メソッドを使用して開始される実行可能ジョブなど)にワーク・マネージャを指定します。ワーク・マネージャが指定されていない場合、非同期ジョブは現在のリクエスト・ワーク・マネージャで実行されます。

WebLogic Serverでは、WebLogic Server 9.2以前のリリースに対する下位互換性は jsp-descriptor 要素の backward-compatible 要素を介してサポートされます。

JSP 2.0 Webアプリケーションとの互換性

JSP 2.1はWebLogic Server 10.0からサポートされています。Webアプリケーションのバージョン(バージョン2.4または2.5)とweblogic.xml記述子ファイルの backward-compatible 要素の設定によっては、JSP 2.0もWeblogic Serverでサポートされます。

JSPの動作とバッファ接尾辞

Webアプリケーションのバージョンが2.5であり(つまり、 web.xml に2.5のバージョン属性があり)、 backward-compatibility フラグが false に設定されている場合、

バージョン2.1のすべてのJSP/TAGファイルは新しいJSP動作に従います。

バージョン2.0以前のすべてのJSP/TAGファイルはJSP 2.0以前の動作に従います。

Webアプリケーションのバージョンが2.5であり、 backward-compatibility フラグが true に設定されている場合、すべてのJSP/TAGファイルはJSP 2.0以前の動作に従います。

Webアプリケーションのバージョンが2.4以前である場合は、 backward-compatibility フラグの設定に関係なく、すべてのJSP/TAGファイルはJSP 2.0以前の動作に従います。

Servlet 2.5パッケージの暗黙的なインポート

Servlet 2.5仕様では、 java.lang.* 、 javax.servlet.* 、 javax.servlet.jsp.* 、および javax.servlet.http.* パッケージのみが暗黙的にインポートされると規定されています。Servlet 2.5仕様に準拠して、WebLogic Serverではこれらの規定されているパッケージのみがインポートされます。一方、WebLogic Serverの以前のリリースでは、 java.io.* 、 java.util.* 、および javax.servlet.jsp.tagext.* パッケージもインポートされていました。

以下のいずれかの状態である場合、WebLogic Serverは2.4以前の動作に従い、上記の規定されていないパッケージもインポートします。

weblogic.xml記述子ファイルの backward-compatible フラグが true に設定されています。

Webアプリケーションのバージョンが2.4以前です。

バージョン2.5のWebアプリケーションにある個々のJSP/TAGファイルがバージョン2.0以前です。

Webコンテナをグローバル・レベルで構成するには、 WebAppContainerMBean を使用します。 WebAppContainerMBean 属性の詳細と、この属性を使用してすべてのWebアプリケーションに対しドメイン全体のデフォルトを指定する方法については、「WebAppContainerMBean」を参照してください。

Stack Overflow Public questions & answers
Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
Talent Build your employer brand
Advertising Reach developers & technologists worldwide
Labs The future of collective knowledge sharing
About the company

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

Why do I list security roles in web.xml when they're in jdbcRealm database?

I run JavaEE 6 web application on Glassfish 3. I use JAAS with jdbcRealm and default principal to role mapping. In my database I have table for mapping usernames to their roles:

Why do I need to list these roles once again in my web.xml ?

Without that isUserInRole() always returns false .

security-roles

looks close to stackoverflow.com/questions/5294252/… – Michail Nikolaev Commented Mar 5, 2013 at 21:50
It doesn't actually although they're about security realms. – Jacek Laskowski Commented Mar 6, 2013 at 4:31

You don't redefine security roles in web.xml . You list them so an application server knows about their use in your code.

When you deploy a secured application, an application server reads a deployment descriptor to solicit information about security configuration. It knows about roles that are used in your application. The application can then use the roles and expect the application server is able to map them to users and groups (that ultimately resolve to users again as users are the security finest building blocks).

Speaking of mapping roles to users, that's where a realm comes in. It offers the mapping so you know that a role X in a deployment descriptor maps to the role X in a database that in turn map to users A and B.

With that said, the database that's used by jdbcRealm has exactly the same roles because they're the keys to users that the application server needs to map to roles in the application.

What you use in your code and a deployment descriptor is a logical name of a group of users that are resolved to real users via the mapping that's offered by the jdbcRealm.

2 In my simple "hello-world"ish application; I have not specified <security-role> tag. Still everything works as expected. i.e. browser asks for authentication. And entered user and its role is correctly identified by tomcat. So is it just nice-to-have feature ? – Kaushik Lele Commented Mar 6, 2015 at 9:15

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged java jakarta-ee jaas security-roles or ask your own question .

Featured on Meta
Upcoming sign-up experiments related to tags
The 2024 Developer Survey Is Live
The return of Staging Ground to Stack Overflow
Policy: Generative AI (e.g., ChatGPT) is banned

Hot Network Questions

Question regarding validity of argument
Meaning of "virō" in description of Lavinia
What was Jessica and the Bene Gesserit's game plan if Paul failed the test?
Is it possible that the editor is still looking for other reveiwers while one reviewer has submitted the reviewer report?
How to temporarily disable a primary IP without losing other IPs on the same interface
UTF-8 characters in POSIX shell script *comments* - anything against it?
Convention of parameter naming - undocumented options
What was the title and author of this children's book of mazes?
What can I add to my too-wet tuna+potato patties to make them less mushy?
How is Leetcode able to compile a C++ program without me writing a 'main()' function?
Finding a mystery number from a sum and product, with a twist
How to use SSReflect to prove commutativity and associativity of addition idiomatically?
Looking for a story that possibly started "MYOB"
How to Find Efficient Algorithms for Mathematical Functions?
Would you be able to look directly at the Sun if it were a red giant?
How can non-residents apply for rejsegaranti with Nordjyllands Trafikselskab?
Does every proof need an axiom saying it works?
Meaning of 電話も出ない
Approximating an Ellipse with Circular Arcs.
Possible negative connotations of "Messy Kitchen" for a blog and social media project name
Bibliographic references: “[19,31-33]”, “[33,19,31,32]” or “[33], [19], [31], [32]”?
Should I practise a piece at a metronome tempo that is faster than required?
Was Croatia the first country to recognize the sovereignity of the USA? Was Croatia expecting military help from USA that didn't come?
Why don't they put more spare gyroscopes in expensive space telescopes?

IMAGES

PPT
BEA WebLogic Enterprise Security Architecture
Using RolesAllowed and SecurityRole annotations to secure Webservices
Understanding WebLogic Server Security
WebLogic Security Service Architecture
WebLogic Security Service Architecture

VIDEO

Security Role Overview in Power Apps
Spring Tips (a short): the Spring Health Assessment #java #springboot #springframework
security roles
PRESENTATION VIDEO FOR SECURITY & SAFETY AUDIT ASSIGNMENT DEM2643 (NURUL ERNA EZARINA BINTI MALI)
Securing Spring Functions By Breaking In
🚨 Oracle WebLogic Server Command Injection Flaw Under Attack! #cyberattack #oracle

COMMENTS

Assigning Roles Using security-role-assignment
A basic security-role-assignment element definition in weblogic.xml declares a mapping between a security-role defined in sip.xml and one or more principals or roles available in the Converged Application Server security realm. If the security-role is used in combination with the run-as element in sip.xml, Converged Application Server assigns the first principal or role name specified in the ...
java
I think that the user RobMon does not exist in your security realm. You probably wanted to assign the role to the user monitor. So the configuration in weblogic.wml should be: <wls:security-role-assignment> <wls:role-name>RobMon</wls:role-name> <wls:principal-name>monitor</wls:principal-name> </wls:security-role-assignment>
Users, Groups, And 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. (See Security Policies .)
weblogic.xml Deployment Descriptor Elements
security-role-assignment The security-role-assignment element declares a mapping between a Web application security role and one or more principals in WebLogic Server, as shown in the following example. ... WebLogic Server uses this security role as the principal name, rather than looking it up in a global realm. ...
Editing security data :: WebLogic Remote Console
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.xml Deployment Descriptor Elements
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>
auth-constraint in WEB.xml and security-role-assignment in WEBLOGIC.xml
</security-role-assignment> 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.
The security-role-assignment references an invalid security-role ...
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. ... </security-role-assignment> An example of the entry found in the web.xml is as follows: <security-role>
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:Web.xml:<security-constraint> <auth-constraint> ...
security-role-assignment element in weblogic.xml
I get the principal name as "system" instead of the user logged in to the application. I understand that I started weblogic server using the userid "system". Is there any way to propagate the user role-name defined in <security-role-assignment> to the EJB container? This is related to my earlier posting about UserManager.setPassword() method call.
weblogic.xml Deployment Descriptor Elements
The following sections describe the complex deployment descriptor elements that can be defined in the weblogic.xml deployment descriptor under the root element <weblogic-web-app>: description. weblogic-version. security-role-assignment. run-as-role-assignment. reference-descriptorGroup. session-descriptor.
Security in weblogic.xml
in weblogic.xml security <wls:security-role-assignment> <wls:role-name>Role</wls:role-name> <wls:principal-name>principal</wls:principal-name> </wls:security-role-assignment> you must enter all the principals? .. if I create a new principal I need to enter by force? I can not insert a tag that treats them all? Thanks to all and good job Peppe
Using weblogic security roles in authentication: weblogic 9
I use the simple form based authentication. While trying to deploy my application, I get the error: weblogic.management.DeploymentException: [HTTP:101168]The security-role-assignment references an invalid security-role: LTVORole. But I have defined the role LTVORole in weblogic using the administrator console.
weblogic.xml Deployment Descriptor Elements
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. ... WebLogic Server uses this security role as the principal name, rather than looking it up in a global realm. When the security role and its principal-name mapping are defined elsewhere ...
Users, Groups, And 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. (See Security Policies .)
OBIEE Server Throws the Error
My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.
weblogic.xmlデプロイメント記述子の要素
security-role-assignment. security-role-assignment要素は、Webアプリケーションのセキュリティ・ロールとWebLogic Serverの1つまたは複数のプリンシパルとのマッピングを宣言します。次に例を示します。 <security-role-assignment> <role-name>PayrollAdmin</role-name> <principal-name>Tanya</principal-name> <principal-name>Fred</principal-name ...
Migration from Weblogic to Apache Tomcat
5. In Tomcat, these things can be defined in a couple of different places. For the security-role re-mapping, use the standard <security-role-ref> in web.xml to re-map role names. If you are using a servlet-3.0-spec webapp, then many of your session- and cookie-related items are available via web.xml: <session-config>. <cookie-config>.
java
8. You don't redefine security roles in web.xml. You list them so an application server knows about their use in your code. When you deploy a secured application, an application server reads a deployment descriptor to solicit information about security configuration. It knows about roles that are used in your application.