SecureWay Directory Server Access Control Overview

When Lightweight Directory Access Protocol (LDAP) was first developed, it was only a protocol for accessing data in an X500 directory server. Therefore, many specifics of how the server itself was supposed to work were left out. Even when the new standard was written for LDAP version 3 (RFC2251), some important issues were left out simply because the people involved had already picked an implementation, and didn't want a new standard to force them to redesign and reimplement large portions of their servers. Access control was one of those important issues. That is why when discussing access control, it is important to remember that each vendor has a different mechanism, and very little is portable from one server to another.

Access control starts with authentication. There are several mechanisms to accomplish the authentication, but all must eventually resolve to a distinguished name (DN) that exists in the directory. This distinguished name is then used to determine the access that is granted to a user. The process of associating a distinguished name with a user is called binding. A user can bind to a server using the DN and a password, or they can bind anonymously, providing no credentials.

Authentication is accomplished using access control permissions that you set for objects in the IBM Secureway directory. For information on using the Integration Technologies Administrator to specify access control permissions, Setting Access Control for Objects.

SecureWay Syntax

There are four attribute types which determine the access that is allowed on an entry:

These attributes can only be modified by the entry owner, or the directory administrator. There are two other attributes which are maintained by the server, and are not user modifiable, but are available to read for informational purposes:

AclEntry

The aclEntry attribute describes the access granted to the entry object. It describes who has rights (the subject), what rights they have to the object itself, and what rights they have to the attributes of the object. The format of the aclEntry attribute is:
<subject-type>:<subjectDN>:<object-access>:<attribute-access>

AclPropagate

This attribute will have a value of "true" or "false". The default is "true", and indicates that the aclEntry values for this entry should propagate down the hierarchy to apply to any entries below it which don't have their own aclEntry attribute(s).

EntryOwner

Like the subject clause of the aclEntry, the entryOwner has a subject type and a subjectDN. The subject type can be access-id, group, or role. The subjectDN should be the distinguished name of an entity that represents the correct type of entry (person, accessGroup, or accessRole).
Example: access-id:cn=SAS,o=SAS Institute,c=US

OwnerPropogate

A value of "true" or "false" that determines whether the entryOwner value will propogate to down the hierarchy to apply to entries below it.

ACI Rule Considerations

AclEntry attributes in SecureWay propogate down (assuming aclPropogate is true) to all its subordinates until the aclEntry is overridden. Any aclEntry will override all the values of the previous aclSource. That is to say, if you want to add access by another individual or group at a given point in the tree, while retaining the access controls specified higher up, you must copy the aclEntry attribute values that the entry is already inheriting, and add the new values. Just creating an aclEntry with the new value will revoke the access provided by the previous aclSource.

Access Control Examples

AclEntry: access-id:cn=Portal User,ou=People,o=SAS Institute,
c=US:object:ad:normal:rwsc:sensitive:rwsc:critical:rwsc

Note: The previous code should be entered as a single line.

This example allows the user with a DN of cn=Portal User,ou=People,o=SAS Institute,c=US all access to everything in the directory. This level of access is unusual, but acceptable for this example because the Portal User identity is used by an application that performs very specific operations in the directory.

AclEntry: group:cn=Sales,ou=Groups,o=SAS Institute,c=US:object:
a:normal:rsc

Note: The previous code should be entered as a single line.

This example allows access to the group: cn=Sales,ou=Groups,o=SAS Institute,c=US. The permissions allow read, search, compare, and add. The add permission is important because it allows members of these groups can create archive entries under the channel Orders for Manufacturing Materials. If the administrator wished, the add permission could have been moved down to the archivepath entry. This would have restricted who could publish archives to be stored under the channel.

SAS application requirements

There are several places in the SAS hierarchy that do not require any special access control. There are other places, however, that require careful thought when applying the ACI rule. The following are the places in the hierarchy that require special attention.

Cn=SAS

This is the top of the SAS application tree. Special permissions for an administrative user, or application identity can go here, if desired.

Cn=sasSubscribers,sascomponent=sasPublishSubscribe

No sensitive data is contained in this part of the tree, so allowing public read access is acceptable. It's also good to provide a way for users to update their own subscriber entries. The only way to do this is to make the personDn the entryOwner for each entry, or put an aclEntry on each subscriber granting write access to the person.

Cn=saschannels,sascomponent=sasPublishSubscribe

The level of control you implement here depends on how you want to secure channels, archive paths and archives. The way publishing works, if a user can read a channel entry, they can publish TO_SUBSCRIBERS, which sends email to all of the users subscribed to a channel. This is allowed even if the publishing user is not subscribed to the channel and therefore cannot write to the channel. This situation can be covered by only allowing read access to specific groups. The other consideration is how archive paths are secured. Allowing add access to an archive path means a user can create archives under that path (assuming they have permission on the physical path).

Cn=sasArchivePaths,sascomponent=Archiving

This area has the same considerations as the channels. To define the ACI rule, you must decide how you want to protect the global archive paths.

Cn=saslogins,sascomponent=sasserver

This requires careful consideration, because the saslogins below this container contain user names and passwords. These attributes are defined as being critical, but the appropriate user needs to be able to read those attributes in order to access their data. The best answer is to make the entryOwner of individual logins the individual they belong to, and for group logins, set the aclEntry to allow access to critical attributes by the appropriate group, and set the owner to a group administrator.

Cn=sasStoredProcessPaths,sascomponent=sasApplications

It is likely that each storedprocesspath entry will have its own ACI rule set. This is because the stored processes will generate information that will be intended for a certain audience. The stored processes should be grouped under a sasstoredprocesspath according to the group that needs access to them.

Sascomponent=sasDataSources

This is another location that requires careful consideration. Libraries, tables, infomarts and other data sources may all have individual security requirements.