If you have read the WAS 8.5.5.x silent install guide (which is part of my new WAS 8.5.5.x course available for purchase  in Q2 2015), you will know that we used the custom install script was8manage.sh or manually install WAS, you would hopefully have turned on Global Security by default. The most obvious surety of this action is that you are required enter a d username and password to log in to the Administrative Console.

To turn on global security, log in to the Admin console and navigate to the Security section of the left-hand side navigation panel and click Global security, as shown in the following screenshot:

You will now be taken to the main Global security configuration page as shown in the following screenshot:


Security Configuration Wizard

WebSphere provides a wizard to set up basic security using an internal repository. What we are going to do is run the wizard to secure our admin console.

Click the Security Configuration Wizard button as shown in the previous screenshot. You will be presented with an option to decide on the extent of your security protection. Leave the screen options set to their default and click Next to move on to the next page, where you will select which type of repository you wish to use.


Note: Enable application security is on because usually you want to secure applications and allow role-based management of users/groups for that application. Use Java 2 security to restrict application access to local resources, as seen in the Security Configuration Wizard, is used when you do not trust the application’s code. Since in most cases you trust the code you are installing in your EAR/WAR files, you do not need to turn this option on.

On the Select user repository page, you have four types of repository to choose from these options are discussed below.

Click Next


Global security registry types

Global security is enabled to secure your WAS server, however, to do so requires a user registry. A user registry contains the user and group names for authentication and authorization purposes. Once configured, an application server will connect to the registry and perform lookups to acquire user credentials used in areas where authorization is required.

There are four types of registry which are explained in the table below.

Registry Type Description
Standalone LDAP registry Only uses LDAP for defined users and groups and requires LDAP configuration both for WAS administrative roles and application user roles.
Local operating system Specifies the registry for the local OS.Can be federated with other registries as part of a virtual member repository.
Standalone custom registry Allows a custom registry that is essentially based on Java code implementation.Can be federated with other registries as part of a virtual member repository.
Federated repositories Manages users and groups across multiple repositories using a virtual realm. The registries can also be made up of the combinations of the other registry types.Note:


Note: The default repository is built into WebSphere and is based on the platform you are running on.

Completing the Wizard usingFederated repositories

We are going to turn on Global security using the internal File Registry, we do this by choosing Federated repositories as an option. What this means is that we can later federate other registries such as custom or LDAP registries that can be used for user/group role-based management.

Note: However please understand that when you use Federated repositories and you have not removed the internal repository, then you can only assign users/groups from the internal fil registry to assign role-based access to the Was Admin console.


  • Choose Federated repositories option in the Select user repository page (Shown earlier)
  • Click Next
  • Fill in the Primary admin user, I have used wasadmin as my primary admin, also enter a password. I have also used wasadmin for the password.

  • Click Next
  • Click Finish

  • Click Save to persist the changes to the underlying WebSphere XML configuration files.

The result will be that we are presented with the following settings configured in the Global security page.


  • Restart the server for Global security enablement to take effect.
  • Use stopServer.sh and statrServer.sh from the <was_profile_root>bin folder
cd /opt/IBM/WebSphere/AppServer/profiles/DV_AppServer01Prof


./stopServer.sh server1
ADMU0116I: Tool information is being logged in file
ADMU0128I: Starting tool with the DV_AppServer01Prof profile
ADMU3100I: Reading configuration for server: server1
ADMU3201I: Server stop request issued. Waiting for stop status.

ADMU4000I: Server server1 stop completed.

Note: You are not prompted for a username and password when you issue the stopServer command. This is because at this point Global Security is enabled in the underlying sexurity.xml file, but the server has to be restarted for it to take effect.

./startServer.sh server1
ADMU0116I: Tool information is being logged in file
ADMU0128I: Starting tool with the DV_AppServer01Prof profile
ADMU3100I: Reading configuration for server: server1
ADMU3200I: Server launched. Waiting for initialization status.

ADMU3000I: Server server1 open for e-business; process id is 12200

Next time you open the Admin Console, you will be presented with a login screen similar to below


Review of security.xml and fileRegistry.xml

We are now going to look at the underlying WAS file system and see what was done.

We do this by issuing the following command from the <was_profile_root> for example /opt/IBM/WebSphere/AppServer/profiles/DV_AppServer01Prof

find . -type f | xargs grep wasadmin 2>/dev/null

Note: All errors will be piped to /dev/null to stop then from displaying in the results.


./config/cells/DV_AppServer01/security.xml: <userRegistries xmi:type=”security:WIMUserRegistry” xmi:id=”WIMUserRegistry_1″ serverId=”” serverPassword=”{xor}” realm=”defaultWIMFileBasedRealm” ignoreCase=”true” useRegistryServerId=”false” primaryAdminId=”wasadmin” registryClassName=”com.ibm.ws.wim.registry.WIMUserRegistry”/>
./config/cells/DV_AppServer01/fileRegistry.xml: <wim:identifier externalId=”abbea27e-252d-4790-a3c3-da0ecb41af7d” externalName=”uid=wasadmin,o=defaultWIMFileBasedRealm”
./config/cells/DV_AppServer01/fileRegistry.xml: uniqueId=”abbea27e-252d-4790-a3c3-da0ecb41af7d” uniqueName=”uid=wasadmin,o=defaultWIMFileBasedRealm”/>
./config/cells/DV_AppServer01/fileRegistry.xml: <wim:uid>wasadmin</wim:uid>
./config/cells/DV_AppServer01/fileRegistry.xml: <wim:cn>wasadmin</wim:cn>
./config/cells/DV_AppServer01/fileRegistry.xml: <wim:sn>wasadmin</wim:sn>

We can see that there are two files that contain the text wasadmin, this is security.xml and fileRegistry.xml


When we open sexurity.xml we find that the security:Security element has activeUserRegistry set to

<security:Security xmi:version=”2.0″ xmlns:xmi=”http://www.omg.org/XMI” xmlns:orb.securityprotocol=”http://www.ibm.com/websphere/appserver/schemas/5.0/orb.securityprotocol.xmi” xmlns:security=”http://www.ibm.com/websphere/appserver/schemas/5.0/security.xmi” xmi:id=”Security_1″ useLocalSecurityServer=”true” useDomainQualifiedUserNames=”false” enabled=”true” cacheTimeout=”600″ issuePermissionWarning=”true” activeProtocol=”BOTH” enforceJava2Security=”false” enforceFineGrainedJCASecurity=”false” appEnabled=”true” dynamicallyUpdateSSLConfig=”true” allowBasicAuth=”true” activeAuthMechanism=”LTPA_1″ activeUserRegistry=”WIMUserRegistry_1″ defaultSSLSettings=”SSLConfig_DV_AppServer01_1″ adminPreferredAuthMech=”RSAToken_1″>


When we look further down the file we see the following element which defines the settings applied to the registry id of WIMUserRegistry_1

<userRegistries xmi:type=”security:WIMUserRegistry” xmi:id=”WIMUserRegistry_1” serverId=”” serverPassword=”{xor}” realm=”defaultWIMFileBasedRealm” ignoreCase=”true” useRegistryServerId=”false” primaryAdminId=”wasadmin” registryClassName=”com.ibm.ws.wim.registry.WIMUserRegistry“/>


The security.xml file contains elements which define enabled repositories, w s we can see above in the userRegistries elements that we have a default virtual realm that defines the user registry

Now that we know we are the class com.ibm.ws.wim.registry.WIMUserRegistry we know that we are using the internal fileRegistry.xml as our user/group registry.

When we open fileRegistry.xml, we see this XML

<?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: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:identifier uniqueName=”o=defaultWIMFileBasedRealm”/>










We can see that our new user “wasadmin” exists in the fileRegistry.xml (The Internal User Repository).


There is a limitation in WAS when using the internal file registry. If you choose to use the federated repositories option and one of the registries in the internal fileRegistry, then administrative security i.e. for the console seems to only allow users from the fileRegistry.xml to be assigned to WAS console roles. But if we choose standalone LDAP registry then it will use the LDAP entity which is set as the primary Administrator for the primary WAS admin user and any other LDAP entity assigned to WAS Admin roles. Applications and WAS shares the same LDAP, thought they could be in different organisational units.




As seen above in the screen capture of the Global security page, Administrative Security (Global Security) is enabled. The term Global Security is the term for WAS version 7 and below. We also have a Realm that has been set it is called defaultWIMFileBasedRealm and the current Realm definition is set to
Federated repositories. This setting specifies to manage security profiles in multiple repositories under a single realm. The realm can consist of identities in:

  • The file-based repository that is built into the system
  • One or more external repositories
  • Both the built-in, file-based repository and in one or more external repositories

Note: Only a user with administrator privileges can view the federated repositories configuration.

Another point to understand is that when we create a profile and set a username and password, the profile creation process creates and configured a Federated Repository which is using the internal file-based repository built onto the system.

Let’s now take a look at the configuration that exists for the Federated repositories setting.

If we click configure as shown below, we will be able to see more information about the Federated Repositories

Once in the Federated Repositories screen as seen below, we can understand even more about the current registry that is being used in the federated repository.

We can see that we have a Realm name set to defaultWIMFileBasedRealm. As mentioned earlier, we have the Primary administration user name being wasadmin, and there is only one repository in this realm.

Note: We will look at adding LDAP to this federated repository later in this guide.

If we drill down ever further by navigating to the Related Items section and clicking on Manage repositories, we will see what makes up this internal repository.

We can now see that we have a Repository identified as InternalFileRepository.

We see that the internal fileRegistry.xml is governed by this Repository Identifier, sort of like a class of registry type. I would normally not go any further to discover the internal workings of WAS, but I think the next few paragraphs are an interested read.

If we open an ssh session and locate the <was_profile_root> we can issue a find command similar to the following:

cd /opt/IBM/WebSphere/AppServer/profiles/DV_AppServer01Prof
find . – type f | xargs grep InternalFileRepository 2>/dev/null


./config/cells/DV_AppServer01/wim/config/wimconfig.xml: id=”InternalFileRepository” supportPaging=”false” messageDigestAlgorithm=”SHA-1″>

If we then open the file called wimconfig.xml , which was found in: /opt/IBM/WebSphere/AppServer/profiles/DV_AppServer01Prof/config/cells/DV_AppServer01/wim/config/ we can look to understand this file more. The reason we need to be aware of the existence of these type of files is because it could be possible that you may have some complex security requirements in the future and this type of analysis is the kind you may have to do to debug any problems/configuration issues.

If you have a brief look in the file we can see that this file defines the schema for a file repo, but it is not the repo itself.

<?xml version=”1.0″ encoding=”UTF-8″?>
Begin Copyright
Licensed Materials – Property of IBM

Virtual Member Manager


(C) Copyright IBM Corp. 2005 All Rights Reserved.


US Government Users Restricted Rights – Use, duplication or

disclosure restricted by GSA ADP Schedule Contract with IBM Corp.


%Z% %W% %I% %E% %U%


End Copyright


<sdo:datagraph xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”

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

<config:configurationProvider maxPagingResults=”500″ maxSearchResults=”4500″ maxTotalPagingResults=”1000″

pagedCacheTimeOut=”900″ pagingEntityObject=”true” searchTimeOut=”600000″>

<config:dynamicModel xsdFileName=”wimdatagraph.xsd”/>

<config:supportedEntityTypes defaultParent=”o=defaultWIMFileBasedRealm” name=”Group”>



<config:supportedEntityTypes defaultParent=”o=defaultWIMFileBasedRealm” name=”OrgContainer”>






<config:supportedEntityTypes defaultParent=”o=defaultWIMFileBasedRealm” name=”PersonAccount”>



<config:repositories xsi:type=”config:FileRepositoryType” adapterClassName=”com.ibm.ws.wim.adapter.file.was.FileAdapter”

id=”InternalFileRepository” supportPaging=”false” messageDigestAlgorithm=”SHA-1″>

<config:baseEntries name=”o=defaultWIMFileBasedRealm”/>


<config:realmConfiguration defaultRealm=”defaultWIMFileBasedRealm”>

<config:realms delimiter=”/” name=”defaultWIMFileBasedRealm” securityUse=”active”>

<config:participatingBaseEntries name=”o=defaultWIMFileBasedRealm”/>

<config:uniqueUserIdMapping propertyForInput=”uniqueName” propertyForOutput=”uniqueName”/>

<config:userSecurityNameMapping propertyForInput=”principalName” propertyForOutput=”principalName”/>

<config:userDisplayNameMapping propertyForInput=”principalName” propertyForOutput=”principalName”/>

<config:uniqueGroupIdMapping propertyForInput=”uniqueName” propertyForOutput=”uniqueName”/>

<config:groupSecurityNameMapping propertyForInput=”cn” propertyForOutput=”cn”/>

<config:groupDisplayNameMapping propertyForInput=”cn” propertyForOutput=”cn”/>





<config:topicSubscriber topicSubscriberName=”DefaultDAViewProcessor” topicSubscriberType=”ModificationSubscriber”>


<Content Removed for Brevity>











isSecurityEnabled=”true” useSystemJACCProvider=”false” importPolicyFromFile=”true”

isAttributeGroupingEnabled=”true” defaultAttributeGroup=”default”





jaccRoleToPermissionPolicyId=”WIM Policy”

jaccPrincipalToRolePolicyId=”WIM Policy”























The highlighted XML elements are for you to review, but please do not edit this file. I am just showing that there is an internal master continuation file which determines the schema/settings of the available registries, and it uses a syntax similar to LDAP schema which is a simplified version of x.500. This is quite an interesting subject, and it delves into some of the theory of how WAS manages security

Security Configuration Wizard
Virtual Member Manager
Administrative roles
Installing ApacheDS
Adding a new partition
Security settings

Looking at User Groups



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.


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

Industry Qualifications & Recognition

  • TOGAF 9.1
  • IBM Champion 2013

Leave a Reply