Managing administrative access in IBM PureApplication System

In IBM® PureApplication™ System, administrators organize users into groups who perform the same sets of tasks and control their access to system functionality by granting permissions. As an administrator setting up a PureApplication System, what are the users and user groups that you should create, and how should you manage their permissions?

Share:

Bobby Woolf, Certified Consulting IT Specialist, IBM

Photo of Bobby WoolfBobby Woolf is a Consultant for IBM Software Services for WebSphere (ISSW), focusing on IBM PureApplication System, service-oriented architecture, event-driven architecture, and application integration. He is the author of Exploring IBM SOA Technology and Practice, and a co-author of Enterprise Integration Patterns and The Design Patterns Smalltalk Companion.


developerWorks Master author
        level

14 November 2012

Also available in Spanish

Introduction

In IBM PureApplication System W1500 V1.0 (hereafter called PureApplication System), administrators organize users into groups who perform the same sets of tasks and control their access to system functionality by granting permissions. As an administrator setting up a PureApplication System, what are the users and user groups that you should create, and how should you manage their permissions?

User groups enable an administrator to grant permissions to users in such a way that all users in the same role are granted the same permissions. To understand what user groups we need, we first need to understand PureApplication System's features for managing users and permissions, as well as some essential guidelines for managing its security. Then we will consider some step-by-step guidance for setting up security on PureApplication System and a strategy for refining that for various user tasks. Finally, we will see what general principles we can draw from the strategy that will apply even when the strategy changes.

Scripting

Included with this article is a corresponding script and a read-me file on how to use it:

  • Python script: ipas_usersetup_bestpractice.py
  • Read-me text:IPAS_UserSetup_README.txt

This script automates the effort to create the default set of groups and users described in this article. As shown in the read-me file, the user you use to run the script will need to be the default administrator, admin.

You should consider the script to be more of an example of how to create these users and groups than something that should be run as-is for a production system. PureApplication System should be configured to perform its authentication using an external LDAP repository. Since the script cannot create its users and groups in LDAP, by necessity it creates them locally within PureApplication System's built-in user repository. Ideally, to make best use of this script, write another script to create these users and groups in your LDAP repository, and modify this script to bind the users and groups in your PureApplication System to their LDAP counterparts.


PureApplication System role-based security

Before we discuss what user groups to create, first you need to understand:

  • User management resources: This is how PureApplication System organizes permissions.
  • User and user group permissions: This is how PureApplication System enables permissions to be granted to users.
  • Essential PureApplication System security: This covers some essential guidelines for the most basic security setup in PureApplication System.

This section discusses how a user can grant permissions to other users. The discussion assumes the actions described are being performed by a powerful user with the ability to grant permissions to others, such as the default administrator user who has all permissions.


User management resources

PureApplication System organizes permissions for using the system into security roles. A security role is not the same as a user group (nor a user in a user group).

  • A security role is a set of permissions to perform a related set of functionality in the system, such as by accessing the console pages or CLI commands for performing that functionality.
  • A user group is a collection of users who all perform the same tasks.
  • A user is an account that provides the ability to log into the system.

Granting a security role to a user group gives the users in that group the permissions they need to perform the functionality associated with that role. A security role can also be granted to an individual user, but a best practice is to grant roles to groups, not to individual users.

Figure 1 shows the relationship between users, user groups, and security roles.

Figure 1. Relationship of PureApplication System user management resources
Relationship of PureApplication System user management resources

Users and user groups are created by a PureApplication System administrator (specifically, as you will see, any user with the system administration role). The PureApplication System software includes a predefined set of security roles. You cannot change the existing roles nor add new ones. This article explains what the predefined security roles are, the functionality each one provides access to, and how to grant them to user groups.

Security roles

PureApplication System includes a built-in set of security roles that cannot be changed. Each role represents the ability to perform a set of functionality in PureApplication System, as accessed through the console or via CLI commands. The predefined set of security roles is organized in a hierarchy with two layers, Administrators and Workload Management as shown in Figure 2. There is also an additional default security role, "Deploy patterns in the cloud," which is automatically granted to all users. This default role is not shown in the console, but it is shown in Figure 2 for completeness.

Figure 2. Conceptual security roles hierarchy
Conceptual security roles hierarchy

There are five different administrative security roles, that is, types of administrators. They divide system administration responsibility into five major functional areas:

  • Administrators:
    • Workload resources administration
    • Cloud group administration
    • Hardware administration
    • Auditing
    • Security administration

Each administration role has one of two level-of-access settings:

  • View all workload resources (Read-only): This is reader or read-only access. It enables the user to view the resources on those pages, but not make any changes.
  • Manage workload resources (Full permission): This is writer or read/write access. It enables the user to not only view the resources on those pages, but also to change their settings, create new resources, and delete them.

A user can also optionally be given the delegation capability. A user with this capability who has been granted any full permission administration roles can, in turn, grant and revoke those same roles (read-only or full permission) to other existing users and groups. You can think of this as delegating the role to other users and groups. To enable this capability, select this delegation capability, Allow delegation when full permission is selected.

In addition to the nine security roles (five administrative roles discussed above, plus four workload management roles discussed below) shown in the console, there is a tenth implied security role:

  • Workload Management
    • Deploy patterns in the cloud

This special workload management role is not shown in the console. It cannot be granted or revoked. The system automatically grants it to all users. It enables every user to view patterns, pattern instances, and catalog content; but not to create, change, or delete patterns. It also enables them to deploy the virtual application patterns and virtual system patterns.

There are four different workload management security roles, subsets of the workload resources administration role's capabilities, which extend the capabilities of the default pattern deployment role:

  • Workload Management:
    • Create new patterns
    • Create new environment profiles
    • Create new catalog content
    • IBM License Metric Tool (ILMT)

Users and groups who are granted the workload resources administrative writer role are automatically granted all workload management roles as well. Furthermore, you can grant workload management roles to a user or group that does not have any administrative roles granted, which augments the capabilities of the pattern deployer role.

Console menu visibility

In general, the permissions granted by a security role are manifested as access to certain menus and pages in the PureApplication System console, which this article will explain in detail in the next section.

User roles for IBM PureApplication System W1500 contains a table, "Table 1: Visibility of console menus for each security role," which explains the permissions granted by security roles in finer detail. Each table row describes a security role. Each administration role gets multiple rows in the table to explain differences between the read-only and full permissions levels-of-access. The columns in the table represent menus within the PureApplication System console. For most menus, either a role has access or it does not. But for some of the menus, even access to specific menu items is role-dependent. The documentation then explains each security role in more detail.

That table in the Information Center still does not provide a complete explanation of which menu items are enabled for each role. This article attempts to be more complete.

Command line interface permission

The permissions granted by a security role are also manifested as permission to execute specific commands in the PureApplication System's command line interface (CLI). Whereas the console enables a user to view and change the configuration of the system via a GUI, the CLI enables a user to do so programmatically. In both cases, the actions are performed in the context of a user who is logged into the system, which means that the user's security roles determine which actions the system allows the user to perform.

For a general introduction to the CLI, see Using the command-line interface.


User and user group permissions

Permissions for accessing functionality in PureApplication System are organized into predefined security roles. A user or user group is granted a set of permissions by granting it a security role. When a role is granted to a group, the system thereby grants it to all members of the group. Roles can also be granted to and revoked from individual users, thereby adding to and subtracting from the roles a user inherits from its groups, though a best practice is to grant roles to groups, not individual users. For convenience, this article will usually express roles being granted to a user, which is also a shorthand way of saying that the user will also receive the role if it is granted to one of the user's groups.

To view and grant the roles on a user: On the System Console, go to System > Users and select a user. In Figure 3, we have selected the user called "DemoAdmin." In the properties pane for the user, scroll down to the Permissions property, as shown in Figure 3.

Figure 3. Permissions in the user's properties page
Permissions in the user's properties page

To view and grant the roles on a user group: On the System Console, go to System > User Groups and select a user group. In Figure 4, we have selected the user group called "Everyone." In the properties pane for the user group, scroll down to the Permissions property, as shown in Figure 4.

Figure 4. Permissions in the user's properties page
Permissions in the user's properties page

The security roles hierarchy is displayed in the permissions pane of the user's or user group's properties. We will review each section of the pane one at a time. For each role, we will explain which console menus and pages the role makes accessible and which CLI commands it enables.

Workload management

The workload management settings apply to specific tasks that are performed in the Workload Console. The workload management settings are set in the section of the Permissions properties panel shown in Figure 5.

Figure 5. Workload management permissions panel
Workload management permissions panel

Each setting enables the user to perform a specific task:

  • Create new patterns: This role grants the capability to create new patterns.
    • Console: The add icon appears on the page for each pattern type on the Workload Console > Patterns menu.
    • CLI: The create()method is enabled for each pattern collection object. For example:
      • To create a virtual application pattern via the ApplicationPatterns object: deployer.applications.create(<specific attributes>)
      • To create a virtual system pattern via the Patterns object: deployer.patterns.create(<specific attributes>)
  • Create new environment profiles: This role grants the capability to create new environment profiles.
    • Console: The add icon appears on the Workload Console > Cloud > Environment Profiles page.
    • CLI: The create() method is enabled for the EnvironmentProfiles object: deployer.environmentprofiles.create(<specific attributes>)
  • Create new catalog content: This role grants the capability to create new artifacts (virtual images, script packages, add-ons, and so on).
    • Console: The add icon appears on the page for each artifact type on the Workload Console > Catalog menu.
    • CLI: The create() method is enabled for each artifact type's collection object. For example:
      • To create a virtual image via the VirtualImages object: deployer.virtualimages.create(<specific attributes>)
      • To create an add-on via the AddOns object: deployer.addons.create(<specific attributes>)
  • IBM License Metric Tool (ILMT): This role grants the capability to manage licenses via the REST API. There is no corresponding console page or CLI commands.

Note: The add icon on the console pages looks like a green plus sign (+).

Role delegation

The role delegation capability is enabled in the section of the Permissions properties panel shown in Figure 6.

Figure 6. Role delegation permissions panel
Role delegation permissions panel

When a user has their role delegation capability enabled, if they have one or more full permission administration roles, they can grant and remove those same roles (read-only or full permission) to other existing users and groups. You can think of this as delegating the role to other users and groups.

The default administrator can create other users and groups and grant them any and all roles because it has all roles granted to it and has the delegation capability enabled.

Workload resources administration

The workload resources administration settings are set in the section of the Permissions properties panel shown in Figure 7.

Figure 7. Workload resources administration permissions panel
Workload resources administration permissions panel

When a user or group is granted the Workload administrative writer role, it is automatically granted all Workload administrative sub-roles (see Workload management).

When workload resources administration is enabled, the user gets access to all functionality on the Workload Console, as shown in Figure 8.

Figure 8. Workload resources administration menu
Workload resources administration menu

Specifically, in addition to the default pattern deployment functionality and the workload management functionality, a workload resources administrator also gets access to all functionality on these menus:

  • Workload Console > Instances > Shared Services
  • Workload Console > Catalog > Database Workload Standards
  • Workload Console > Catalog > DB2 Fix Packs
  • Workload Console > Cloud > Shared Services
  • Workload Console > Cloud > System Plug-ins
  • Workload Console > Cloud > Pattern Types
  • Workload Console > Cloud > Default Deploy Settings
  • Workload Console > System > Troubleshooting
  • Workload Console > System > Storehouse Browser

The corresponding CLI commands include:

  • List of shared services via the SharedServices object: deployer.sharedservices
  • List of pattern types via the PatternTypes object: deployer.patterntypes
  • A trace file specification map (for troubleshooting) via the Trace object: deployer.trace.spec()

Cloud group administration

The cloud group administration settings are set in the section of the Permissions properties panel shown in Figure 9.

Figure 9. Cloud group administration permissions panel
Cloud group administration permissions panel

When cloud group administration is enabled, the user gets access to all functionality on these menus, as shown in Figure 10:

  • System Console > Cloud
  • System Console > Reports
  • System Console > System > Product Licenses
Figure 10. Cloud group administration menu
Cloud group administration menu

The corresponding CLI commands include:

  • List of cloud groups: admin.clouds
  • List of IP groups: admin.ipgroups
  • List of virtual machines: admin.virtualmachines
  • The ILMT server information: admin.ilmt

Hardware administration

The hardware administration settings are set in the section of the Permissions properties panel as shown in Figure 11.

Figure 11. Hardware administration permissions panel
Hardware administration permissions panel

When hardware administration is enabled, the user gets access to all functionality on these menus, as shown in Figure 12:

  • System Console > Hardware
  • System Console > Reports
  • System Console > System > Settings
  • System Console > System > Customer Network Configuration
  • System Console > System > Job Queue
  • System Console > System > Events
  • System Console > System > Troubleshooting
  • System Console > System > Problems
  • System Console > System > Product Licenses
Figure 12. Hardware administration menu
Hardware administration menu

The corresponding CLI commands include:

  • List of compute nodes: admin.computenodes
  • List of management nodes: admin.managementnodes
  • List of storage devices: admin.storagedevices
  • List of network devices: admin.networkdevices
  • The maintenance report: admin.maintenancereport
  • List of jobs: admin.jobs
  • List of events: admin.events
  • List of trace settings: admin.tracesettings

Auditing

The auditing settings are set in the section of the Permissions properties panel as shown in Figure 13.

Figure 13. Auditing permissions panel
Auditing permissions panel

When auditing is enabled, the user gets access to all functionality on these menus by selecting System Console > System > Auditing, as shown in Figure 14.

Figure 14: Auditing menu
Auditing menu

The corresponding CLI commands include:

  • List of auditing records: admin.audits
  • Retrieve auditing utilization: admin.audits.getUtilization()
  • Retrieve system public key for auditing: admin.audits.getKey()

Security administration

The security administration settings are set in the section of the Permissions properties panel as shown in Figure 15.

Figure 15. Security administration permissions panel
Security administration permissions panel

When security administration is enabled, the user gets access to all functionality on these menus, as shown in Figure 16.

  • System Console > Reports
  • System Console > System > Users
  • System Console > System > User Group
  • System Console > System > Security (not included with View users/groups (Read-only))
Figure 16. Security administration menu
Security administration menu

The corresponding CLI commands include:

  • List of users: admin.users
  • List of user groups: admin.groups
  • List current LDAP setting: admin.ldap

Essential PureApplication System security

User management for compliance and cloud security explains a fundamental security practice that should be followed when configuring the users and groups in a PureApplication System:

  • Best practice 1: Separate the duties of PureApplication System users.

A consequence of that practice is itself another best practice:

  • Best practice 2: Create one or more auditors with full permissions.

Once a new system as been configured, a third best practice applies:

  • Best practice 3: Secure the default administrator (admin).

Each of these practices is explained in detail below. Best practices 1 and 2 overlap significantly so they are discussed as one.

Separate administration duties and create at least one auditor

Of all the security roles in PureApplication System, the most fundamental responsibility for the system is split across two root-level functions:

  • Administrators: This function is for users who manage the system resources.
    • The corresponding security roles are Workload resources administration, Cloud group administration, Hardware administration, and Security administration.
  • Auditors: This function is for users who monitor activities in the system.
    • The corresponding security role is Auditing.

It is important to create two corresponding user groups with fundamentally different missions and divide the administration roles amongst them so that no role is granted to both groups:

  • System Auditors: This user group is:
    • Only granted the Auditing (full permission) security role.
    • Not granted any of the Administration security roles.
    • Not granted any of the Workload management security roles.
  • System Administrators: This user group is:
    • Granted all of the Administration security roles, including the Workload management security roles.
    • Not granted the Auditing (full permission nor read-only) security role.

Of course, each user group also needs at least one member, a user with the group's permissions.

Table 1 shows how the permissions and responsibilities of the two groups are mutually exclusive.

Table 1. Fundamental user groups and security roles
User group Administration security roles Auditing security role
System Administrators
System Auditors

This separation is necessary so that the auditors can police the administrators' actions. The auditors will always have a record of the tasks performed by the administrators and will not perform any administration actions for which there needs to be a record.

If an administrator also has the Auditing full access role, he can delete the auditing records that show the administration tasks he performed.

For the lifetime of a PureApplication System, whenever granting security roles to user groups or users, you must take care not to grant the auditing role to a user or user group that also possesses administrative or workload management roles. Likewise, when adding a user to groups, do not add it to both a group with administrative or workload management roles and also to one with the auditing role.

In the System Console, when viewing a user or group granted the auditing role (reader or writer), a warning icon appears next to the Auditing permission which says, "It is not recommended to assign other permissions along with Auditing permissions", as shown in Figure 17. This is a reminder not to grant this user or group any other roles. This warning appears on any user or group with auditing privileges. There is no way to eliminate the warning (other than to remove all auditing privileges).

Figure 17. Warning on the auditing permissions panel
Warning on the auditing permissions panel

Secure the default administrator

When a brand new system is first configured, one of the artifacts created is a default user, the default administrator named "admin". This is initially the only user, the only account to log into the system, and therefore, is an all-powerful user (similar to the root user in Unix) with the permissions of all security roles, including administration and auditing. It is used to initialize and configure a newly installed PureApplication System, including subsequently creating other users and user groups. Be sure at a minimum to use the default administrator to create the two fundamental user groups (and users) described in Separate administration duties and create at least one auditor.

Once a new system's initialization and configuration is complete, this default administrator account should be kept for emergencies. For this reason, the account cannot be deleted, nor can its roles be removed. Although it exists, it should not be used for day-to-day operations and should be secured to prevent backdoor access to all PureApplication System functionality.

To secure this default administrator account, rename the user and change its password to something only a few trusted employees know.

This approach creates three types of fundamental users:

  • Default administrator
  • Members of the System Administrators group
  • Members of the System Auditors group

To preserve the separation of these three fundamental user types, no employee should know the passwords for more than one of the fundamental user types.


Strategy for using role-based security

Now that you understand the features PureApplication System provides for granting permissions, next we will discuss how best to make use of those. We will discuss:

  • Basic roles procedure: This explains some basic security setup that you need to perform on any PureApplication System when first preparing it for use by a customer.
  • Additional deployer groups: We will consider what other groups may be needed for administration and for deploying patterns.
  • Additional users: We will consider what users are needed.

The guidance in this article applies to the full lifecycle of using a PureApplication System, but it is especially relevant to configuring a new system that does not yet have any users or groups defined (other than the default ones). Therefore, this strategy describes the system from the point of view of a brand new one that needs its initial set of users and groups to be configured.

First, here is an overview of the user groups that you will create. User groups and security roles are not hierarchical (that is, there is no inheritance), but you can think of the groups as a specialization hierarchy as shown in Figure 18. The user at the top, admin, is the default administrator and, as such, is the most powerful one because it has been granted all roles. The leaf groups at the bottom have just one role each. Each child has a subset of the roles its parent has.

Figure 18. Conceptual user group hierarchy
Conceptual user group hierarchy

Here are the directions to set up the groups shown in Figure 18.


Basic roles procedure

These steps are some basic security setup that should be performed on any PureApplication System before a customer starts to use it for their own custom workloads. The staff that performs these steps may be the customer's or may be IBM's.

There is a CLI script that you can download from this article, ipas_usersetup_bestpractice.py, which automates the process described in this section. The script creates the users and groups and prompts the user to change the default administrator's password. You can either perform the steps manually as described below, making any changes to these procedures you feel are necessary, or you can run the script and use this article as a description of what the script will do and why. You will need to run the script as admin since that is the only user defined thus far.

The script, by necessity, creates the users and groups locally in the PureApplication System's built-in user repository. Ideally, create these in your LDAP repository and modify the script to bind the PureApplication System users and groups to their counterparts in LDAP.

Step 1: Identify employees

Identify one or more people in the customer's organization (that is, the organization that owns PureApplication System) for each of the three fundamental administrative functions:

  • Super administrator: This person is responsible for the password for the admin user. He will not use it day-to-day, but in case of emergency, the customer or IBM will need that password.
  • System administrator: This person is the ultimate one responsible for the PureApplication System's hardware and middleware. He might be a hands-on administrator or the leader of a team with such responsibilities. At a minimum, he needs to be technical enough to use the PureApplication System user and user group administration GUIs. Either he will use the administration screens himself, or he will create other users to do so.
  • System auditor: This person is the ultimate one responsible for performing auditing of PureApplication System. He can be hands-on with PureApplication System's auditing screens, or may be a project manager who supervises the functioning of the team that administrates PureApplication System. At a minimum, he needs to be technical enough to use the PureApplication System user and user group administration GUIs. Either he will use the auditing screens himself, or he will create other users to do so.

Step 2: Create fundamental users and groups

At this point, the only user defined in the system is the all-powerful default administrator, admin. Log in as admin to create these users and groups.

Create two fundamental user groups and grant them roles:

  • System Auditors: Create this group and grant it the Auditing role. Do not grant it any other administration or workload management roles. Enable delegation so that these users can optionally grant the same role (read-only or full permission) to other existing users and groups.
  • System Administrators: Create this group and grant it all four administration roles (every one except Auditing). Also grant it the workload management roles. These should have been automatically granted when the workload administrator role was granted, but confirm that they were. Enable delegation so that these users can create others and delegate the roles to others.

The roles for these two groups are summarized in Table 2. Set each group's account type as LDAP. Local also works, but LDAP is more secure.

Table 2. Fundamental administrative groups
Group Name Security Role
System Auditors
  • Manage auditing (Full permission)
  • Allow delegation
System Administrators
  • Manage workload resources (Full permission)
  • Manage cloud resources (Full permission)
  • Manage hardware resources (Full permission)
  • Manage security (Full permission)
  • Allow delegation

Create two fundamental users that correspond to these groups. Again, set each user's account type as LDAP (not Local).

  • sysadmin: This user is the customer's system administrator.
    • Add this user to the System Administrators user group.
    • Give the password for this user to the employee who was earlier selected for this assignment.
  • sysauditor: This user is the customer's system auditor.
    • Add this user to the System Auditors user group.
    • Give the password for this user to the employee who was earlier selected for this assignment.

Once these employees are given the passwords for their respective accounts, they should each change their password and be certain not to forget it. They should store the passwords somewhere safe where the passwords can be recovered even if the employee is not available.

Step 3: Secure the default administrator

You can perform this step once these criteria are met:

  • The two fundamental users and groups in the previous step have been created.
  • Both the customer's system administrator and customer's system auditor have:
    • Stored their login credentials (that is, user name and password) somewhere securely.
    • Logged into PureApplication System successfully using their credentials.
    • Have at least a basic comfort level with navigating their respective parts of the PureApplication System console.
  • IBM is finished helping the customer configure the system and is ready to turn it over to the customer.

Once these criteria are true, the super administrator (or this can also be performed by the system administrator) should:

  • Log into PureApplication System (as admin or sysadmin).
  • Go to System Console > System > Users and select the user named admin.
  • This user cannot be deleted and its roles cannot be revoked. Instead, the person identified in the first step as the super administrator should rename the account to something like "backupAdmin" and change the user's password and store it somewhere safe.

Step 4: Create additional administration and viewing groups

After performing Step 2: Create fundamental users and groups, the customer has one administrator user for the entire system, the user we have referred to as the system administrator. The administration tasks will often need to be performed by more specialized administrative users, and those users should belong to more specialized administrative groups.

Logged in either as sysadmin (or as admin, if that account is still enabled), go to System Console > System > User Groups and create these user groups shown in Table 3. Each group's account type should be LDAP (not Local). Users belonging to these groups can administer the respective parts of the system and to grant that role to other users.

Table 3. Specialized administrative groups
Group Name Security Role
Workload Resources Administrators
  • Manage workload resources (Full permission)
  • Allow delegation
Cloud Group Administrators
  • Manage cloud resources (Full permission)
  • Allow delegation
Hardware Administrators
  • Manage hardware resources (Full permission)
  • Allow delegation
Security Administrators
  • Manage security (Full permission)
  • Allow delegation

Do not create a group for auditing. That group has already been created, the System Auditors group.

You may also want to create these groups for the read-only variations on the roles. These groups are not required, but they are helpful. Create some or all of the user groups shown in Table 4.

Table 4. System viewing groups
Group Name Security Role
Workload Resources Viewers View all workload resources (Read-only)
Cloud Group Viewers View all cloud resources (Read-only)
Hardware Viewers View all hardware resources (Read-only)
Auditing Viewers View all auditing reports (Read-only)
Security Users Viewers View users/groups (Read-only)
Security Resources Viewers View all security resources (Read-only)

You are also going to need groups for users who manage workloads. Create the user groups shown in Table 5.

Table 5. Specialized workload management groups
Group Name Security Role
Pattern Creators Create new patterns
Environment Profile Creators Create new environment profiles
Catalog Content Creators Create new catalog content
ILMT Managers IBM License Metric Tool (ILMT)

Additional deployer groups

Keep in mind that there is no need to create a "Pattern Deployers" group. That is an implied role, so by default, every PureApplication System user has permission to deploy patterns, and this permission cannot be revoked. In practice, without additional permissions, a user wishing to deploy a pattern needs access to a pattern that has already been created by someone else and access to deploy using an environment profile that has already been created by someone else. So although everyone has permission to deploy patterns, a user cannot do so without help from others.

Your organization needs additional user groups to represent different teams who need access to certain environment profiles to deploy patterns. How many such user groups are needed depends on the breakdown of your organization's total development process: the number of teams deploying applications and the number of environment profiles used for deployment. For guidance on these issues, see the separate article, Managing application runtime environments in IBM PureApplication System. These groups should be defined in LDAP, so set their account type as "LDAP".


Additional users

Create a separate user for each person who will log into PureApplication System. The user logged in to create these users must have the Manage security (Full permission) role, so that user must be a member of Security Administrators (or System Administrators). Typically, these users are created from an LDAP directory that PureApplication System has been given access to, so set their account type as "LDAP".

Naming convention: Name each user in PureApplication System after the name of the employee the user represents. For example, if his corporate e-mail address is "jdoe@acme.com," a good name for this user account would be "jdoe."

People who need users include administrators and auditors (as described earlier), those who are going to create patterns, deploy them, create other workload management artifacts like environment profiles and browse pattern instances. They are going to interact with the system via the console and CLI scripts. In general, create a user for each of these people and add each user to groups with roles the user needs.


Principles of security roles

This strategy makes consistent use of a few principles:

  • Grant security roles to user groups, not to individual users. Then add users to the groups. This approach simplifies granting and revoking roles to multiple users. A user group shows its group members, thereby showing everyone who has the roles that have been granted to the group.
  • Do not grant administrative roles and the auditing role to the same user group. See Separate administration duties and create at least one auditor. Therefore, create a System Auditors group for users who can only perform audits and a System Administrators group for users who can do everything but audit. (Most users will not belong to either of these highly-privileged groups.)
  • Once PureApplication System is set up, secure the default administrator (admin). To do this, rename the account and change its password.
  • Create a user group for every security role and every level-of-access setting. This enables you to grant any user a role by adding it to the corresponding group.
  • Create a user group for each team that will use environment profiles to deploy patterns. This requires designing the user groups and environment profiles together, which is explained in the separate article, Managing application runtime environments in IBM PureApplication System.
  • Create a separate user for each person who will log into PureApplication System. Do not let people share logins.

Conclusion

This article explained the security roles in PureApplication System and how to make use of them to control which functionality in the system various users can administer. It explained what security roles are, and their relationship to user groups and users. It listed each of the system's built-in security roles, the permissions they grant, and showed how those permissions are reflected in the administrative console and the CLI commands. It reviewed best practices for securing a system's administrative access and presented a step-by-step strategy for applying these best practices, including a CLI script for automating this procedure, and reviewed principles that are drawn from this strategy. With this information, you are now prepared to administer the administrative access to your PureApplication System.

Acknowledgements

The author would like to thank the following IBMers for their help with this article: Vishy Gadepalli, Tamiko Brown, Chris Laffoon, and Ching-Yun Chao. Special thanks goes to Tamiko and Chris for developing the CLI script that creates the users and groups, and for guidance on the CLI commands that correspond to the various roles.


Download

DescriptionNameSize
Code sampleipas_usersetup_bestpractice.zip3KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Cloud computing on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • developerWorks Labs

    Experiment with new directions in software development.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing, WebSphere
ArticleID=845513
ArticleTitle=Managing administrative access in IBM PureApplication System
publish-date=11142012