58 lines
6.8 KiB
HTML
58 lines
6.8 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<LINK rel="stylesheet" type="text/css" href="../../../rzahg/ic.css">
|
|
|
|
<title>Assign users to naming roles</title>
|
|
</head>
|
|
|
|
<BODY>
|
|
<!-- Java sync-link -->
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
|
|
|
<h3><a name="seccnam"></a>Assign users to naming roles</h3>
|
|
|
|
<p>WebSphere Application Server - Express extended J2EE security role based access control to protect the WebSphere Application Server - Express naming subsystem. CosNaming security offers increased granularity of security control over CosNaming functions. CosNaming functions are available on CosNaming servers such as the WebSphere Application Server - Express. They affect the content of the WebSphere Application Server - Express Name Space. There are generally two ways in which client programs will result in CosNaming calls. The first is through the JNDI interfaces. The second is CORBA clients invoking CosNaming methods directly.</p>
|
|
|
|
<p>Four security roles are introduced : CosNamingRead, CosNamingWrite, CosNamingCreate, and CosNamingDelete. The name of the four roles are the same with WebSphere Application Server Advanced Edition v4.0.2 However, the roles now have authority level from low to high as follows:</p>
|
|
|
|
<ul>
|
|
<li><p><strong>CosNamingRead.</strong> Users who have been assigned the CosNamingRead role is allowed to do queries of the WebSphere Application Server - Express Name Space, such as through the JNDI lookup() method. The special-subject Everyone is the default policy for this role.</p></li>
|
|
<li><p><strong>CosNamingWrite.</strong> Users who have been assigned the CosNamingWrite role is allowed to do write operations such as JNDI bind(), rebind(), or unbind(), plus CosNamingRead operations. The special-subject AllAuthenticated is the default policy for this role.</p></li>
|
|
<li><p><strong>CosNamingCreate.</strong> Users who have been assigned the CosNamingCreate role is allowed to create new objects in the Name Space through such operations as JNDI createSubcontext(), plus CosNamingWrite operations. The special subject AllAuthenticated is the default policy for this role.</p> </li>
|
|
<li><p><strong>CosNamingDelete.</strong> And finally users who have been assigned CosNamingDelete role are able to destroy objects in the Name Space, for example using the JNDI destroySubcontext() method, as well as CosNamingCreate operations. The special-subject AllAuthenticated is the default policy for this role.</p></li>
|
|
</ul>
|
|
|
|
<p>Additionally, a Server special subject is assigned to all the four CosNaming roles by default. The Server special subject allows a WebSphere Application Server - Express server process, which runs under the server identity, to have access to all the CosNaming operations. Note that the Server special subject is not displayed and cannot be modified through the administrative console nor other administrative tools.</p>
|
|
|
|
<p>Users, groups, or the special subjects AllAuthenticated and Everyone can be added or removed to or from the Naming roles from the WebSphere web based administrative console at anytime. However, a server restart is required for the changes to take effect. A best practice is to map groups or one of the special-subjects, rather than specific users, to Naming roles because it is more flexible and easier to administer in the long run. By mapping a group to an Naming role, adding or removing users to or from the group occurs outside of WebSphere Application Server - Express and doesn't require a server restart for the change to take effect.</p>
|
|
|
|
<p>The CosNaming authorization policy is only enforced when global security is enabled. When global security is enabled, attempts to do CosNaming operations without the proper role assignment will result in a org.omg.CORBA.NO_PERMISSION exception from the CosNaming Server.</p>
|
|
|
|
<p>In WebSphere Application Server Version 4.0.2, each CosNaming function is assigned to only one role. Therefore, users who have been assigned CosNamingCreate role are not able to query the Name Space unless they have also been assigned CosNamingRead. And in most cases, a creator would need to be assigned three roles: CosNamingRead, CosNamingWrite, and CosNamingCreate. This has been changed in the release. The CosNamingRead and CosNamingWrite roles assignment for the creator example in above have been included in CosNamingCreate role. In most of the cases, WebSphere Application Server administrators do not have to change the roles assignment for every user or group when they move to this release from previous one.</p>
|
|
|
|
<p>Although the ability exist to greatly restrict access to the Name space by changing the default policy, doing so may result in unexpected org.omg.CORBA.NO_PERMISSION exceptions at runtime. Typically, J2EE applications access the Name space and the identity they use is that of the user that authenticated to WebSphere when they access the J2EE application. Unless the J2EE application provider clearly communicates the expected Naming roles, care should be taken when changing the default naming authorization policy.</p>
|
|
|
|
<p>To assign users to naming roles, perform these steps:</p>
|
|
|
|
<ol>
|
|
<li><p>In the administrative console, expand <strong>Environment --> Naming</strong>. Click <strong>CORBA Naming Service Users</strong> or <strong>CORBA Naming Service Groups</strong>.</p></li>
|
|
<li><p>Perform the necessary tasks:</p>
|
|
|
|
<ul>
|
|
<li>Click <strong>Add</strong> on the CORBA Naming Service Users or CORBA Naming Service Groups panel.</li>
|
|
<li>To add a new naming service user, enter a user identity in the <strong>User</strong> field, highlight one or more naming roles, and click <strong>OK</strong>. If there are no validation errors, the specified user displays with the assigned security role.</li>
|
|
<li>To add a new naming service group, either select <strong>Specify group</strong> and enter a group name or select <strong>Select from special subject</strong> and then select either EVERYONE or ALL AUTHENTICATED. Click <strong>OK</strong>. If there are no validation errors, the specified group or special subject displays with the assigned security role.</li>
|
|
<li>To remove a user or group assignment, go to the CORBA Naming Service Users or CORBA Naming Service Groups panel. Select the check box next to the user or group that you want to remove and click <strong>Remove</strong>.</li>
|
|
<li>To manage the set of users or groups to display, expand the filter folder on the panel on the right side, and modify the filter text box. For example, setting the filter to <tt>user*</tt> allows only users with the "user" prefix to be displayed.</li>
|
|
</ul><p></p></li>
|
|
|
|
<li><p>After modifications have been made, click <strong>Save</strong> to save the mappings. You must restart the server for the changes to take effect.</p></li>
|
|
</ol>
|
|
|
|
|
|
</body>
|
|
</html>
|
|
|