168 lines
10 KiB
HTML
168 lines
10 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
<!DOCTYPE html
|
||
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
<html lang="en-us" xml:lang="en-us">
|
||
|
<head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
<meta name="security" content="public" />
|
||
|
<meta name="Robots" content="index,follow" />
|
||
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
<meta name="DC.Type" content="concept" />
|
||
|
<meta name="DC.Title" content="Authorization lists" />
|
||
|
<meta name="abstract" content="Like a group profile, an authorization list allows you to group objects with similar security requirements and associate the group with a list of users and user authorities." />
|
||
|
<meta name="description" content="Like a group profile, an authorization list allows you to group objects with similar security requirements and associate the group with a list of users and user authorities." />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzamvconcepts.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzamvplanauthlists.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzamvcreateauthlist.htm" />
|
||
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
|
||
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
|
||
|
<meta name="DC.Format" content="XHTML" />
|
||
|
<meta name="DC.Identifier" content="authlists" />
|
||
|
<meta name="DC.Language" content="en-us" />
|
||
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
<!-- US Government Users Restricted Rights -->
|
||
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
<title>Authorization lists</title>
|
||
|
</head>
|
||
|
<body id="authlists"><a name="authlists"><!-- --></a>
|
||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
<h1 class="topictitle1">Authorization lists</h1>
|
||
|
<div><p>Like a group profile, an authorization list allows you to group
|
||
|
objects with similar security requirements and associate the group with a
|
||
|
list of users and user authorities.</p>
|
||
|
<p>Authorization lists provide an efficient way to manage the authority to
|
||
|
similar objects on the system and aid in the recovery of security information.</p>
|
||
|
<p>Providing each user with explicit access to every object they need to work
|
||
|
with might create a great deal of duplicated effort, because many users need
|
||
|
to access the same group of objects. A much easier way to provide this access
|
||
|
is to create authorization lists. Authorization lists consist of a list of
|
||
|
users or groups, the type of authority (*USE, *CHANGE, and *EXCLUDE) for each
|
||
|
user or group, and a list of objects to which that this list provides access.</p>
|
||
|
<p>For example, you can create an authorization list to contain a list of
|
||
|
objects related to an inventory database. A user responsible for ordering
|
||
|
new inventory items can be granted authority to see the contents of the database
|
||
|
objects. Additionally, a user group in shipping and receiving needs to update
|
||
|
this database as parts come in and out of stock. This group can have authority
|
||
|
to change the contents of the objects.</p>
|
||
|
<div class="p">An authorization list has these advantages:<ul><li>Authorization lists simplify managing authorities. User authority is defined
|
||
|
for the authorization list, not for the individual objects on the list. If
|
||
|
a new object is secured by the authorization list, the users on the list gain
|
||
|
authority to the object.</li>
|
||
|
<li>One operation can be used to give a user authority to all the objects
|
||
|
on the list.</li>
|
||
|
<li>Authorization lists reduce the number of private authorities on the system.
|
||
|
Each user has a private authority to one object, the authorization list. This
|
||
|
gives the user authority to all the objects on the list. Reducing the number
|
||
|
of private authorities in the system has the following advantages:<ul><li>Reduces the size of user profiles.</li>
|
||
|
<li>Improves the performance when saving the system (SAVSYS) or saving the
|
||
|
security data (SAVSECDTA).</li>
|
||
|
</ul>
|
||
|
</li>
|
||
|
<li>Authorization lists provide a good way to secure files. If you use private
|
||
|
authorities, each user will have a private authority for each file member.
|
||
|
If you use an authorization list, each user will have only one authority.
|
||
|
Also, files that are open cannot have authority granted to the file or revoked
|
||
|
from the file. If you secure the file with an authorization list, you can
|
||
|
change the authorities, even when the file is open.</li>
|
||
|
<li>Authorization lists provide a way to remember authorities when an object
|
||
|
is saved. When an object is saved that is secured by an authorization list,
|
||
|
the name of the authorization list is saved with the object. If the object
|
||
|
is deleted and restored to the same system, it is automatically linked to
|
||
|
the authorization list again. If the object is restored on a different system,
|
||
|
the authorization list is not linked, unless ALWOBJDIF(*ALL) is specified
|
||
|
on the restore command.</li>
|
||
|
</ul>
|
||
|
</div>
|
||
|
<p>From a security management view, an authorization list is the preferred
|
||
|
method to manage objects that have the same security requirements. Even when
|
||
|
there are only a few objects that would be secured by the list, there is still
|
||
|
an advantage to using an authorization list instead of using private authorities
|
||
|
on the object. Because the authorities are in one place (the authorization
|
||
|
list), it is easier to change who is authorized to the objects. It is also
|
||
|
easier to secure any new objects with the same security level authorities
|
||
|
as the existing objects.</p>
|
||
|
<p>If you use authorization lists, you should not have private authorities
|
||
|
on the object. Two searches of the user's private authorities are required
|
||
|
during the authority checking if the object has private authorities and the
|
||
|
object is also secured by an authorization list. The first search is for the
|
||
|
private authorities on the object; the second search is for the private authorities
|
||
|
on the authorization list. Two searches require additional system resources;
|
||
|
therefore, system performance can be impacted. If you use only the authorization
|
||
|
list, only one search is performed. Also, because of the use of authority
|
||
|
caching with the authorization list, the performance for the authority check
|
||
|
will be the same as it is for checking only private authorities on the object.</p>
|
||
|
<div class="section" id="authlists__comparison"><a name="authlists__comparison"><!-- --></a><h4 class="sectiontitle">Comparison of group profiles and authorization
|
||
|
lists</h4><p>Group profiles are used to simplify managing user profiles
|
||
|
that have similar security requirements. Authorization lists are used to secure
|
||
|
objects with similar security requirements. The following table shows the
|
||
|
characteristics of the two methods.</p>
|
||
|
|
||
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><caption>Table 1. Authorization list and
|
||
|
group profile comparison</caption><thead align="left"><tr><th valign="top" id="d0e57">Usage considerations</th>
|
||
|
<th valign="top" id="d0e59">Authorization List</th>
|
||
|
<th valign="top" id="d0e61">Group Profile</th>
|
||
|
</tr>
|
||
|
</thead>
|
||
|
<tbody><tr><td valign="top" headers="d0e57 ">Can use to secure multiple objects</td>
|
||
|
<td valign="top" headers="d0e59 ">Yes</td>
|
||
|
<td valign="top" headers="d0e61 ">Yes</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" headers="d0e57 ">User can belong to more than one</td>
|
||
|
<td valign="top" headers="d0e59 ">Yes </td>
|
||
|
<td valign="top" headers="d0e61 ">Yes</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" headers="d0e57 ">Private authority overrides other authority</td>
|
||
|
<td valign="top" headers="d0e59 ">Yes</td>
|
||
|
<td valign="top" headers="d0e61 ">Yes </td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" headers="d0e57 ">User must be assigned authority independently</td>
|
||
|
<td valign="top" headers="d0e59 ">Yes</td>
|
||
|
<td valign="top" headers="d0e61 ">No</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" headers="d0e57 ">Authorities specified are the same for all objects</td>
|
||
|
<td valign="top" headers="d0e59 ">Yes</td>
|
||
|
<td valign="top" headers="d0e61 ">No</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" headers="d0e57 ">Object can be secured by more than one</td>
|
||
|
<td valign="top" headers="d0e59 ">No</td>
|
||
|
<td valign="top" headers="d0e61 ">Yes</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" headers="d0e57 ">Authority can be specified when the object is created</td>
|
||
|
<td valign="top" headers="d0e59 ">Yes</td>
|
||
|
<td valign="top" headers="d0e61 ">Yes</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" headers="d0e57 ">Can secure all object types</td>
|
||
|
<td valign="top" headers="d0e59 ">No</td>
|
||
|
<td valign="top" headers="d0e61 ">Yes</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" headers="d0e57 ">Association with object is deleted when object is deleted</td>
|
||
|
<td valign="top" headers="d0e59 ">Yes</td>
|
||
|
<td valign="top" headers="d0e61 ">No</td>
|
||
|
</tr>
|
||
|
<tr><td valign="top" headers="d0e57 ">Association with object is saved when the object is
|
||
|
saved</td>
|
||
|
<td valign="top" headers="d0e59 ">Yes</td>
|
||
|
<td valign="top" headers="d0e61 ">No</td>
|
||
|
</tr>
|
||
|
</tbody>
|
||
|
</table>
|
||
|
</div>
|
||
|
<p>You can find more detailed information about authorization
|
||
|
lists in <span class="q">"Comparison of group profiles and authorization lists"</span> in the <cite>iSeries™ Security
|
||
|
Reference</cite>.</p>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div>
|
||
|
<div class="familylinks">
|
||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzamvconcepts.htm" title="To effectively create a security policy and plan security measures for your system, you need to understand the following security concepts, some of which are general concepts and some of which are specific to the hardware type.">Concepts</a></div>
|
||
|
</div>
|
||
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
<div><a href="rzamvplanauthlists.htm" title="You can group objects with similar security requirements by using an authorization list.">Plan authorization lists</a></div>
|
||
|
<div><a href="rzamvcreateauthlist.htm" title="This article describes the task, create an authorization list, explains why it is important, and provides step-by-step instructions.">Create an authorization list</a></div>
|
||
|
</div>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|