|
|
Integration Technologies Administration |
|
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 information (ACI) rules. An ACI rule specifies the LDAP object to which the rule applies, whether the rule allows the specified permission or denies it, and what type of permission is being allowed or denied. For information on using the Integration Technologies Administrator to specify ACI rules, see Setting Access Permissions for an Object and Specifying Bind Rules.
The Netscape mechanism for administering access controls is flexible and powerful, but can also be complex. Some basics may make things clearer.
(target="ldap:///dn")(targetattr="attrname")[(targetfilter="rfc2254-style filter")]( version 3.0; acl "name"; (allow | deny) (read, write, search, compare, selfwrite, add, delete ) (userdn | groupdn)="ldap:///dn";)Details about each element in the syntax are as follows:
The target specifies the entry where ACI rule will be effective. Usually, the
target is the same as the entry where the ACI attribute exists. In other words,
if the ACI attribute is added to the entry with DN cn=SAS,o=SAS Institute,c=US, then
the target will be ldap:///cn=SAS,o=SAS Institute,c=US. The target
parameter can point at an entry which is a direct descendant, but that can
become hard to manage. The parameter can also
cause the server to process access control information that does not apply to the
search it is carrying out.
Targetattr specifies one or more attributes that the access control information applies to. Access control rules can apply to specific attributes. This parameter provides more strict access to attributes such as userpassword.
This is an optional parameter that can be used to apply to specific entries based on a filter. The filter has the same syntax as a filter provided to the ldapsearch command. This type of ACI rule is expensive to process and should be used sparingly.
The permissions parameter consists of the version number (currently always 3.0), the ACI name, the operation (either allow or deny), the permissions and the subject to which to apply the rule (typically either a user or a group). Most ACI rules are written to allow permissions, because deny ACI rules can quickly become complex. The following permissions are supported:
Some of these permission make the most sense when they are applied to an attribute. For example, allowing selfwrite of the member attribute above the area where groups are stored will allow a user to add himself to or remove himself from a group.
The subject specification will normally be made using the userdn or groupdn
keyword. The value will be an ldap URL with the distinguished name of the
user or group. Wildcard characters can be used in the DN to specify more
than one user. Also, there are two special strings: ldap:///all specifies
all bound users, and ldap:///anyone specifies any users, including anonymous
users. If the groupdn keyword is used, the DN points to a groupOfUniqueNames.
If the DN of the bound user exists in the group as a uniqueMember attribute,
the rule is applied.
There are two other subject specifications that are sometimes used: userdnattr and groupdnattr. These specify that an attribute on the entry will contain a DN, and if the DN matches the bound user, it will apply the rule.
Since ACI rules are cumulative, it is important to be careful granting
access at a node that has a deep tree under it. For example, if read access
is granted to all users at the node cn=SAS,o=SAS Institute, c=US, then it
becomes difficult to restrict that access further down, such as at the container
where logins are stored. Therefore, it is important to look at the whole
directory tree before deciding on an access policy.
From an efficiency point of view, the fewer access control instructions the better, as long as the data is secured in a meaningful way. Using groups is a good way to accomplish this, and make access control easier to manage at the same time. It is a lot easier to add or remove a user from a group than try to find all of the ACI rules that reference that user's DN, or figure out all of the different kinds of access a user requires.
ACI: (target="ldap:///o=SAS Institute,c=US")(targetattr=*)( version 3.0; acl " allow portal user"; allow (all) userdn="ldap:///cn=Portal User,ou=People,o=SAS Institute,c=US";)
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.
ACI: (target="ldap:///o=SAS Institute,c=US")(targetattr=*)(targetfilter="(| (objectclass=sascontainer)(objectclass=sascomponentcontainer))") (version 3.0; acl "see sascontainers"; allow (compare, read, search) userdn="ldap:///all";)
This example is somewhat unusual, but it has a specific purpose. It allows all non-anonymous users to see sascontainers and sascomponentcontainers in order to facilitate browsing.
ACI: (target="ldap:///cn=sassubscribers,sascomponent=saspublishsubscribe,cn=sas,o=sas institute,c=us")(targetattr="*")(version 3.0; acl "owner has all rights"; allow (all) userdnattr = "saspersondn";)
This example is also unusual, because it uses the userdnattr specifier. This ACI rule grants all permissions to a user whose bind DN is found in the saspersondn attribute of an entry below cn=sassubscribers,sascomponent=saspublishsubscribe,cn=sas,o=sas institute,c=US. This is important to allow users to update their own subscriber entries.
ACI: (target="ldap:///saschannelcn=Orders for Manufacturing Materials,cn=saschannels,sascomponent=sasPublishSubscribe,cn=SAS,o=SAS Institute,c=us")(targetattr="*")(version 3.0; acl "allow valid users"; allow (compare,add,read,search) groupdn = "ldap:///cn=IDBGroup,ou=Groups,o=SAS Institute,c=US||ldap:///cn=Sales,ou=Groups,o=SAS Institute,c=US"; )
This example allows access to two groups: cn=IDBGroup,ou=Groups,o=SAS Institute,c=US and 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 to 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.
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.
This is the top of the SAS application tree. If some accommodation for browsing is desired, a filtered ACI rule that allows reading sascontainer and sascomponentcontainer by all bound users can be placed here.
No sensitive data is contained in this part of the tree, but an ACI rule that allows a user to update their own subscriber information is useful. Using the userdnattr on saspersondn allows this function.
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). An ACI rule needs to be created to allow users to manage the archives they create, based on the saspublisher attribute. An ACI rule with a userdnattr=saspublisher that allows all is recommended.
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.
This requires careful consideration, because the saslogins below this container contain user names and passwords. The sasreferencedn and sasallowedclientdn attributes contain the distinguished names of the user represented by this login, as well as the DNs of clients who are allowed to use the login. ACI rules should be written to allow read and write access based on these attributes. Using the userdnattr and groupdnattr is appropriate in this case. The groupdnattr is necessary because the sasreferencedn can refer to a group (for a group login).
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.
The SAS Information Delivery Portal Installation Guide contains guidelines for setting the access controls on portal entries.
This is another location that requires careful consideration. Libraries, tables, infomarts and other data sources may all have individual security requirements. The most important thing to remember is to not place access controls at the container level unless you want that access to apply to all of the entries below it.
Other areas can be opened for read by any bound user, but you must make sure you do not put the ACI rule too far up in the tree. For instance, the container cn=sasservers,sascomponent=sasServer can be opened for read by all, but granting that access at sascomponent=sasServer gives access to logins.
Using deny ACI rules is a useful tool in certain situations, but it can be dangerous. If you want to limit access to a segment of the tree, when higher-level ACI rules have allowed access, you can use deny to accomplish that. Remember, though, that a deny cannot be undone. In other words, if you deny access at a directory entry to all users who are not in a specified group, you cannot then allow a user who is not in that group to access the directory at a lower level in the tree.
You must also remember that an explicit deny is not the same as an implicit allow. If you deny everyone except one group, it does not necessarily mean that everyone in that group is allowed. If no explicit allow was ever specified, the users in that group still do not have access. Deny ACI rules are usually most useful when used with a != operator on the subject, for example:
ACI: (target="ldap:///sasUniqueName=Security Group A - A000000E.WHSECGRP.A00001X7,cn=sasContentObjects,sasmetadatacn=A0000001.WHDW.A000000E,cn=sasMetadata Repositories,sascomponent=sasMetadataRepository,cn=sas,o=sas institute,c=us") (targetattr="*") (version 3.0; acl "Security Policy"; deny (all) groupdn != "ldap:///cn=Distributed Technologies,ou=groups,o=SAS Institute,c=US||ldap:/ //cn=IDBGroup,ou=groups,o=SAS Institute,c=US" ;)
This rule denies access to everything below this entry to everyone that is not a member of the IDBGroup group. The rule to remember is this: do not use deny unless there is no other way to accomplish what you need to do.
|
|
Integration Technologies Administration |
|