Role Management

In this section, we will demonstrate creating users, groups and assigning roles to groups.

Administrative roles

We may want some people to have only the ability to start and stop applications; others, we may wish to allow full configuration access. WebSphere implements a way of delegating privileges through the use of administrative roles. There are 8 predefined roles in WebSphere 8, as outlined in the following table, which users can be mapped to.

Administrative Role Description
Monitor A user or group with the monitor role can do the following:

  • View the WebSphere Application Server configuration
  • View the current state of the Application Server
Configurator Assigned monitor privilege plus the ability to configure. For example, a configurator role can do the following:

  • Create a resource
  • Map an application server
  • Install and uninstall an application
  • Deploy an application
  • Assign users and groups-to-role mapping for applications
  • Set up Java 2 security permissions for applications
Operator Assigned monitor privileges and can stop and start the server and monitor the server status in the administrative console.
Administrator An individual or group which can be assigned this role will have the operator and configurator privileges, plus additional privileges that are granted for administration.
Iscadmins Available to administrative console users. Users who are granted this role have administrator privileges for managing users and groups in the federated repositories.
Deployer Use this role to grant users the ability to completely deploy an application and configure application runtime settings.
Admin Security Manager By using the Admin Security Manager role, you can assign users and groups to the administrative user roles and administrative group roles.
Auditor This role allows users to modify the configuration settings for security auditing and the role includes the monitor role. This allows the auditor to view but not change the rest of the security configuration.

 

Users and groups can be added or removed from administrative roles using the WebSphere Application Server administrative console by a user given the appropriate authority. The administrator role is for this purpose.

 

We would need to map wasadmin to both Administrator and Configurator to allow most of the core admin actions.

Presuming we now have Global Security enabled, let’s log into the secure console using wasadmin/wasadmin.

 

We know at this point of the process, that we have a single administrative user called wasadmin, we can see this by navigating to Users and Groups/Manage Users

 

In the Manage Users screen we see that we have only one user called wasadmin. It has a unique name using the schema defined by the defaultWIMFileBasedRealm for example uid=wasadmin,o=defaultWIMFileBasedRealm.

On this page, we can see where can create new users. But before we do that, we want to know what roles the “wasadmin” user is assigned, so we do this by navigating to User and Groups / Administrative user roles as seen below

 

We can see that no roles are listed for the Primary Administrative User Name, in fact, it is assigned al Roles for complete access to the Admin Console. If we wish to delegate access to other users, we must first create the user and or group, then assign the role.

In this example I am going to create a Group called was_admins, and then assign the Administrator and, Configurator and ISCAdmins Roles to this Group,. Then I will create a user called was_admin, which will be an administration user which is assigned to the was_admins group.

  • To create a Group, navigate to Manage Groups
  • Click the Create button as seen above
  • Add a group name, for example, was_admins

Click Create, the Close

You will then be returned to the Manage Groups screen as seen below

We can see above that we now have a group created called was_admins. If we look at fileRegistry.xml file we discussed earlier, we now have a new group entry.

<wim:entities xsi:type=”wim:Group”>
<wim:identifier externalId=”12ae9226-2507-4a24-b1fe-24d0155b3938″ externalName=”cn=was_admins,o=defaultWIMFileBasedRealm”

uniqueId=”12ae9226-2507-4a24-b1fe-24d0155b3938″ uniqueName=”cn=was_admins,o=defaultWIMFileBasedRealm”/>

<wim:parent>

<wim:identifier uniqueName=”o=defaultWIMFileBasedRealm”/>

</wim:parent>

<wim:createTimestamp>2015-04-14T16:16:26.651+01:00</wim:createTimestamp>

<wim:cn>was_admins</wim:cn>

<wim:description>A group of users which are considered was admins</wim:description>

</wim:entities>

 

We will now assign roles to the group.

Navigate to User and Groups/Administrative group roles

  • When on the Administrative group roles page, click Add, seen below

  • Once on the Group screen, CTRL-Select the Role(s) required, search for was* and you will see the was_admins group is displayed in the available list box.
  • Click the arrow pointing right to assign the roles, then click OK to save.

The assigned role will display in the Administrative group roles list

If we view the admin-authz.xml file located in the same folder as the fileRegistry.xml file

 

We will see the following XML

 

<?xml version=”1.0″ encoding=”UTF-8″?>
<rolebasedauthz:AuthorizationTableExt xmi:version=”2.0″ xmlns:xmi=”http://www.omg.org/XMI” xmlns:rolebasedauthz=”http://www.ibm.com/websphere/appserver/schemas/5.0/rolebasedauthz.xmi” xmi:id=”AuthorizationTableExt_1″ context=”domain”>

<authorizations xmi:id=”RoleAssignmentExt_1″ role=”SecurityRoleExt_1“>


<groups xmi:id=”GroupExt_1429025698660″ name=”was_admins@defaultWIMFileBasedRealm” accessId=”group:defaultWIMFileBasedRealm/cn=was_admins,o=defaultWIMFileBasedRealm”/>

<specialSubjects xmi:type=”rolebasedauthz:ServerExt” xmi:id=”ServerExt_1″/>

<specialSubjects xmi:type=”rolebasedauthz:PrimaryAdminExt” xmi:id=”PrimaryAdminExt_1″/>

</authorizations>

<authorizations xmi:id=”RoleAssignmentExt_2″ role=”SecurityRoleExt_2″/>


<authorizations xmi:id=”RoleAssignmentExt_3″ role=”SecurityRoleExt_3“>

<groups xmi:id=”GroupExt_1429025698788″ name=”was_admins@defaultWIMFileBasedRealm” accessId=”group:defaultWIMFileBasedRealm/cn=was_admins,o=defaultWIMFileBasedRealm”/>

</authorizations>

<authorizations xmi:id=”RoleAssignmentExt_4″ role=”SecurityRoleExt_4″/>

<authorizations xmi:id=”RoleAssignmentExt_5″ role=”SecurityRoleExt_5″/>

<authorizations xmi:id=”RoleAssignmentExt_6″ role=”SecurityRoleExt_6″>

<specialSubjects xmi:type=”rolebasedauthz:ServerExt” xmi:id=”ServerExt_2″/>

<specialSubjects xmi:type=”rolebasedauthz:PrimaryAdminExt” xmi:id=”PrimaryAdminExt_2″/>

</authorizations>

<authorizations xmi:id=”RoleAssignmentExt_7″ role=”SecurityRoleExt_7″/>


<authorizations xmi:id=”RoleAssignmentExt_8″ role=”SecurityRoleExt_8″>

<groups xmi:id=”GroupExt_1429025698868″ name=”was_admins@defaultWIMFileBasedRealm” accessId=”group:defaultWIMFileBasedRealm/cn=was_admins,o=defaultWIMFileBasedRealm”/>

</authorizations>


<roles xmi:id=”SecurityRoleExt_1” roleName=”administrator”/>

<roles xmi:id=”SecurityRoleExt_2″ roleName=”operator”/>


<roles xmi:id=”SecurityRoleExt_3” roleName=”configurator”/>

<roles xmi:id=”SecurityRoleExt_4″ roleName=”monitor”/>

<roles xmi:id=”SecurityRoleExt_5″ roleName=”deployer”/>

<roles xmi:id=”SecurityRoleExt_6″ roleName=”adminsecuritymanager”/>

<roles xmi:id=”SecurityRoleExt_7″ roleName=”nobody”/>


<roles xmi:id=”SecurityRoleExt_8″ roleName=”iscadmins”/>

</rolebasedauthz:AuthorizationTableExt>

Looking at the XML we can see that there is mapping structure ie Groups to Roles.

Now we can add was_admin user to the group was_admins to map the user to these roles, which are mapped to a group.

Note: Mapping to groups requires a little more planning, but the dynamic nature lends best when you have multiple users who might be using the console or running admin scripts because it provides flexibility.

  • Create a new user called was_admin, by navigating to Users and Groups

 

  • Click Create

One the Create a User screen, fill out the fields as shown below

I used was_admin as the username and was_admin as the password

  • Click Create, then Close

When we are returned to the Search for Users screen, we see that there is now a new User.

Now we can add the new was_admin user to the was_admins group. There are two ways to do this.

  • We can either open the user, and then click Groups tab and add the user to the group
  • We can Navigate to Manage Groups as seen below

To add a was_admin to the was_admins group, click Manage Groups

In the Group Properties screen, click the Members tab, then the Add Users button to assign users

  • Click Search, then then select was_admin user from the list and then click Add

A message will be displayed incating the user has been added to the group.

  • Click Close to exit, and return to the Group Properties screen (Members Tab)

Now we have create a new user, a new group with assigned roles, and assigned the new user to a group, we can log out and try the was_admin user and validate that all is OK. Also note that fileRegistry.xml has been modified, and this is what it may look like/

 

<?xml version=”1.0″ encoding=”UTF-8″?>
<sdo:datagraph xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”

xmlns:sdo=”commonj.sdo” xmlns:wim=”http://www.ibm.com/websphere/wim”>

<wim:Root>

<wim:entities xsi:type=”wim:PersonAccount”>

<wim:identifier externalId=”abbea27e-252d-4790-a3c3-da0ecb41af7d” externalName=”uid=wasadmin,o=defaultWIMFileBasedRealm”

uniqueId=”abbea27e-252d-4790-a3c3-da0ecb41af7d” uniqueName=”uid=wasadmin,o=defaultWIMFileBasedRealm”/>

<wim:parent>

<wim:identifier uniqueName=”o=defaultWIMFileBasedRealm”/>

</wim:parent>

<wim:createTimestamp>2015-04-14T11:42:54.323Z</wim:createTimestamp>

<wim:password>U0hBLTE6cjlqcmFnYWs5eWh6OnJiTms1WGx3RzJwdDJDaWJlYkt1ekp2TmJNaz0K</wim:password>

<wim:uid>wasadmin</wim:uid>

<wim:cn>wasadmin</wim:cn>

<wim:sn>wasadmin</wim:sn>

</wim:entities>

<wim:entities xsi:type=”wim:Group”>

<wim:identifier externalId=”12ae9226-2507-4a24-b1fe-24d0155b3938″ externalName=”cn=was_admins,o=defaultWIMFileBasedRealm”

uniqueId=”12ae9226-2507-4a24-b1fe-24d0155b3938″ uniqueName=”cn=was_admins,o=defaultWIMFileBasedRealm”/>

<wim:parent>

<wim:identifier uniqueName=”o=defaultWIMFileBasedRealm”/>

</wim:parent>

<wim:createTimestamp>2015-04-14T16:16:26.651+01:00</wim:createTimestamp>

<wim:modifyTimestamp>2015-04-14T17:00:21.476+01:00</wim:modifyTimestamp>


<wim:cn>was_admins</wim:cn>

<wim:members>

<wim:identifier externalId=”33e584a2-5d2c-434a-b9a0-d9297617ea86″ externalName=”uid=was_admin,o=defaultWIMFileBasedRealm”

uniqueId=”33e584a2-5d2c-434a-b9a0-d9297617ea86″ uniqueName=”uid=was_admin,o=defaultWIMFileBasedRealm”/>

</wim:members>

<wim:description>A group of users which are considered was admins</wim:description>

</wim:entities>

<wim:entities xsi:type=”wim:PersonAccount”>

<wim:identifier externalId=”33e584a2-5d2c-434a-b9a0-d9297617ea86″ externalName=”uid=was_admin,o=defaultWIMFileBasedRealm”

uniqueId=”33e584a2-5d2c-434a-b9a0-d9297617ea86″ uniqueName=”uid=was_admin,o=defaultWIMFileBasedRealm”/>

<wim:parent>

<wim:identifier uniqueName=”o=defaultWIMFileBasedRealm”/>

</wim:parent>

<wim:createTimestamp>2015-04-14T16:55:19.780+01:00</wim:createTimestamp>

<wim:password>U0hBLTE6ZHZjajJsZHhja2kwOlJzR3ZFbEFMNGY4TVRjcnBJYng5eXdVSU5Qcz0K</wim:password>

<wim:uid>was_admin</wim:uid>

<wim:cn>WebSphere</wim:cn>

<wim:sn>Administrator</wim:sn>

<wim:mail>wasadmin@localhostcell01.com</wim:mail>

</wim:entities>

</wim:Root>

</sdo:datagraph>

The Elements highlighted in Yellow show the modifications that were performed when we created a new group called was_admins and added the was_admin user to that group. You can even see that the fileRegistry.xm file contains the password as well as the uid.

I know that this section was a little long winded, but it was added to ensure that you fully understand that by default WAS will use an XML-based registry for user/group management when Global security is set to Federated repositories and no LDAP is current. This means simply, all Was administrative users are held in the fileRegistry.xml and the role mapping are held in admin-authz.xml and the current registries assigned to the virtual realm are set and defined in security.xml.

Logging in with the new “was_admin” user

Logout and re-log back in with the new administrative user we have created

When we navigate to Users and Grpups

We can see that we can no longer administer the roles of user and or groups, the options are no longer available.. This is because we did no add Admin Security Manager role to the was_admins group.

Feel free to explore different role combinations. We will not cover more examples, as the information above gives you enough detail to understand how creating user, groups and roles works when using Federated repositories with no LDAP registries, only the internal file-based registry called fileRegistry.xml

 


INTRODUCTION
JEE SECURITY
GLOBAL SECURITY
UNSECURE CONSOLE
TURNING ON GLOBAL SECURITY
Security Configuration Wizard
Virtual Member Manager
ROLE MANAGEMENT
Administrative roles
DISABLING GLOBAL SECURITY
SETTING THE INTERNAL REPOSITORY USING SCRIPTING
APACHEDS
Installing ApacheDS
Adding a new partition
ADDING LDAP TO A FEDERATED REPOSITORY
FEDERATED REPOSITORIES RECAP
Security settings
Wimconfig.xml

CHANGING THE OU FOR LDAP BIND
Looking at User Groups

STANDALONE LDAP
CONFIGURING THE STANDALONE LDAP SERVER
TESTING THE CONNECTION
REVIEW OF SECURITY.XML

SUMMARY

To learn more about the courses available from The Middleware Shop, please go to http://www.themiddlewareshop.com/products to see a full list of the current courses available.

Consulting

If you or your organization require support in architecture, performance tuning, automation or simply advice, then please contact me via my support site and request a conversation, where we can discuss your requirement.

About Steve

Steve is a seasoned passionate technology professional, strategist and leader.

An expert in technical communications, and adept in almost all forms of Internet and mobile related technology, Steve has time and time again proven his tenacity to improve systems around him and deliver.

Steve has worn many hats during his career such as Chief Technical Officer, Founding Member of several business ventures, Programmer, Systems Administrator, Architect, Blogger and Published Author to name a few.

Due to 20 years Industry experience in Middleware, Programming, Networks and Internet Technologies, He combines systems knowledge with efficient working methods and inter personal skills required to build effective relationship with clients and colleagues alike. Exceeding typical expectations in any role undertaken, Steve is certain to become a valuable asset within any organisation He joins.

Key Skills

• Leadership (Team, Project, Business, People).

• Architecture (Solutions, Information, Technical, Applications).

Simply, I help you deal with CANETI: Constant And Never Ending Technological Innovation

Specific IBM WebSphere skills:

WebSphere Application Server (WAS Base, WAS ND & Liberty Profile & Liberty Runtime)

  • Automation
  • Security, SSL
  • Dev Ops
  • Architecture
  • Performance Tuning

Middleware Integration Skills:

  • .NET programming, and Architecture
  • Java Programming, and Architecture
  • SOA, SOAP and XML messaging
  • JBoss Fuse, WMQ, IIB, Mule

Integration Skills:

  • SOA
  • Process Improvement
  • ICD’s
  • Messaging Architecture
  • Governance

General Digital Architecture & Governance

  • Lightweight Architectures
  • Digital Strategy, platform stacks for example IAAS, PAAS, SAAS
  • PCI DSS

Industry Qualifications & Recognition

  • TOGAF 9.1
  • IBM Champion 2013
Facebooktwittergoogle_plusredditpinterestlinkedinmail

Leave a Reply