 | Level: Introductory Nicholas Chase, President, Chase and Chase, Inc.
01 Sep 2003 It's never a good idea to have one of your administrators use the default administrative account for a system, let alone all of them. This tip explains how the MetroSphere staff added new administrative accounts -- and limited their power to just what they needed.
The first thing any good system administrator will tell you is that you should never log directly into a system as root, or Administrator, or whatever the default administrative account is named. The same goes for a WebSphere Portal site.
This tip explains how to add a user to the wpsadmins group, and how to create a class of administrators with more limited power.
|
Editor's update
The Web site MetroSphere.com -- the online technical community discussed in this article -- is no longer live. However, the information and screen captures regarding the installation of IBM WebSphere Portal are still accurate and relevant.
|
|
Why new administrators?
We actually started out with two major reasons to create new administrators for the
MetroSphere site. The first is just common sense; good practice says that users
should never be logging in as the default administrator account. Instead, their
own accounts should be added to the administrator group. This part is easy, and
I'll talk about it in a moment.
The second reason is more problematic. Because the community aspects of the site
are so important, we realized early on that we were going to be recruiting other
people to help out with day-to-day administrative functions. In some cases, these
will be MetroSphere employees, but I could foresee a time when we might have volunteers
performing administrative functions for their own "areas." This means that we
had to find a way to provide them with administrative functions without giving
them complete control over the site. To do that, we created a new group of
administrators with a few privileges missing.
Creating a new administrator
If you want to create a new administrator, you first need to add your personal accounts to the wpsadmins
group, so that you have administrator privileges. To start with, log in as wpsadmin
and go to Portal Administration > Users and Groups > Manage Users.
If the accounts you're
trying to promote haven't been created yet, create them by clicking Create new user.
Otherwise, or when you're finished, click Manage Groups. To select the
wpsadmins group, enter * under
Search for groups and click Get groups. Select the wpsadmins
group and click Membership.
Find the users to add by entering a * under Add
users to group and clicking Go, as shown in Figure 1.
Figure 1. Add new users to the wpsadmins group
Select the users you want to add (using <ctrl> to
select multiple users) and click Add to group. Click OK to finish the process.
Creating a new type of administrator
Now that Tom (our administrator) and I have added ourselves to the wpsadmins group,
we can turn our attention to creating a "lesser admin" group. This group will have
most of the functions the regular admins do, but won't be able to do things like
manage the portal itself, create new portlet applications, and so on. Creating a new
group also makes it easier for us to remove privileges from all of the lesser admins
at once, should we find that something's becoming a problem. Once the group's created,
we can add new users to it just as we added ourselves to wpsadmins.
To create a group for yourself, start at the Manage User Groups page. Enter a
name for the new group and click Create Group, as shown in Figure 2.
Figure 2. Create the new group
From here you can add any users to the group, just as you added users to the wpsadmins
group. Now you just have to remove the offending permissions from this group.
|
Multiple group permissions
It's important to realize that there's no way to specifically "deny" privileges
for a user or a group. A user will have the highest permission level for any
of their groups, so if GroupA has MANAGE permissions on a resource and GroupB
has no privileges, a user in both groups will have MANAGE permissions. The only way to prevent a user from doing something is to never give them
permissions at all.
In some cases, you might find that the only way to do this is to create a group
for all of your "regular" users, then remove various privileges from "all
authenticated users."
|
|
Setting permissions for the new group
Now, you and I know that this is supposed to be a group of administrators, but as far
as the system is concerned, the new group has absolutely no privileges of its own. A
user that's part of this group will have only the privileges assigned to "all authenticated users."
To correct that problem, you're going to assign the new group most of the privileges
that wpsadmins has.
To assign privileges:
- Click the Access Control List under Security and click Get groups and users so you can select just the new
lesserAdmins group.
- Enter a
* under Search for groups and click Go.
- Select the new group and click Add to list to add it to the bottom box.
- If any other
groups are in the bottom box, select them and click Remove from list to make sure
that
lesserAdmins is the only group selected.
- Click OK
to go back to the Access Control List page.
Make sure lesserAdmins is selected and choose places under Select the objects for the permissions. Click Go.
The resulting page, shown in Figure 3 enables you to add specific
permissions for pages and page groups on the site. But before you do that, take
a moment to look at what each of these privileges means:
-
NONE: A user won't even see the
particular resource. (NOTE: It's possible to set the portal so that the user
sees an "access denied" message, but usually the resource is just missing.)
-
VIEW: A user will see the page/portlet/whatever but
won't be able to make any changes to it.
-
EDIT: A user will be able to see the resource, and
will be able to make changes such as configuration values, but any changes will
only be seen by that user.
-
MANAGE: A user can see the resource and make changes,
and any changes the user makes will apply to all users of the portal.
-
DELEGATE: A user can assign any privilege up to and
and including their own to another user. So a user that has EDIT
and DELEGATE privileges can grant another user VIEW or
EDIT privileges.
We wanted the lesserAdmins to be able to
manage pages on the MetroSphere site, but we didn't want them to be able to administer
the site itself, except to add users to groups, so we gave them view permissions only
on the appropriate pages, as shown in Figure 3.
Figure 3. Add new privileges
In this case, give the new group VIEW privileges for the
Administration place and the Users and Groups page, and all the pages
under Work with Pages. Click Save to save the changes.
To complete the process, set permissions for each of the types of objects. You will
have to consider your own security arrangements, but here are some suggestions -- your
mileage may vary:
-
user groups: Obviously, you don't want to give your
lesserAdmins the ability to MANAGE
the wpsadmins group. That would defeat the entire
purpose of the exercise. But you might want to give them the ability to add other
lesserAdmins, or to manage general permissions. You decide.
-
places and pages: These were discussed
above.
-
portlet applications: It's probably best to enable
permissions for your lesserAdmins on a portlet-by-portlet
basis, so leave this alone.
-
portlets: In our case, we gave the lesserAdmins
MANAGE access to Access Control List, Choose Skins,
Edit Layout, Manage Page Groups and Pages, Manage User Groups,
Manage Users, and Themes and Skins. The important thing to remember
here is that you never want to assign MANAGE
privileges to a portlet such as iNotesToDoPortlet, which is intended for
individual customization, because a user with MANAGE
access makes changes that affect all users.
-
resource type permissions: You'll probably want to
assign CREATE privileges for Pages, Places,
User groups, and Users, but it's up to you whether to enable this group
to delegate these privileges.
-
resource collections: Resource collections are directories
of documents handled by the Content Organizer. In our case, we kept that away from
the lesserAdmins, but we may change that eventually.
-
external access control and portal: These two areas should probably be off-limits to your lesserAdmins.
 |
Summary
In this tip, we looked at adding users to the default administrator group, and
at creating a group of lesser administrators that had just enough power to do
their jobs, but not enough to wreak havoc on the portal itself. (Adding users
to this group can be accomplished in the same way that we added users to the
wpsadmins group.) Always consider
carefully the implications of any permissions you give out, and create a group
of users so you can easily remove or add privileges if you notice that changes
must be made.
Resources
About the author | 
| |
Nicholas Chase, a Studio B author, has been involved in Web site development for companies such as Lucent Technologies, Sun Microsystems, Oracle, and the Tampa Bay Buccaneers. Nick has been a high school physics teacher, a low-level radioactive waste facility manager, an online science fiction magazine editor, a multimedia engineer, and an Oracle instructor. More recently, he was the Chief Technology Officer of Site Dynamics Interactive Communications in Clearwater, Florida, and is the author of four books on Web development, including XML Primer Plus (Sams). |
Rate this page
| |
