Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 4 Implementing ActiveSpaces Security : User Access Control

User Access Control
TIBCO ActiveSpaces security provides user access control to the operations on a metaspace or space. User access control allows you to control the types of TIBCO ActiveSpaces functionality a user is allowed to perform. User access can be allowed or denied for the following permissions:
read  Allows reading the contents of a space. The tuple_get operation requires read access. Get browsers also require read access.
Read is the minimum permission required on any scope, because it implies the right to connect to a metaspace.
write  Allows writing data to a space. Examples of operations that require write access are:
Take browsers, lock browsers, and transaction also require write access.
Write permission implies that a user also has read permission, because most ActiveSpaces operations that write to a space must first be able to read data from the space. For example, to take a tuple from a space, an application must first do a read to find the tuple before it can remove the tuple.
invoke  Perform remote invocations on a a space
seeder  Allows the user to seed tuples.
encrypt  Allows the user to encrypt tuples.
You can grant or deny a user all of the above permissions by specifying one of the following:
You can also arrange users into groups and apply permissions to all users in a group or to the users in several groups. And you can specify which spaces in a metaspace the permissions for users and groups should be applied to.
Permissions can be applied for:
User access control works in conjunction with user authentication. Do not enable authorization (access control) unless user authentication is enabled
See User Authentication for information on how to configure the security policy file to enable user authentication.
Enabling User Access Control
The following example shows the format of the access_control setting in the security policy file:
access_control=<true|false(default>;default=<deny|grant>
After you have configured user authentication in the security policy file, you then need to enable user access control in the security policy file by specifying the following setting:
access_control=true;default=deny
The default setting specifies whether a user should be denied any access or granted all access permissions, if no access permissions have been defined for a user.
Access Control Groups
To group users so that permissions can easily be applied to multiple users, you must define each group of users that you would like to apply permissions to in the security policy file. Locate the groups heading in the security policy file and add a line after it for each group of users. For example, specify the following:
groups
group1=davidl,robertb,tomd
group2=susanh,joannd,nicolem
group3=group1,miket,joew
A group name can consist of any combination of letters and numbers but can only be defined once. A group can be assigned to other groups.
A user name is either a user's logon user name, if user name/password authentication is used, or the common name of the user's leaf certificate when LDAP certificate authentication is used.
Access Control Permissions
Once you have defined your user groups, you can now apply permissions to each group of users or to single users. Locate the permissions heading in the security policy file and add a permissions declaration after the permissions heading for each metaspace or space that you want to control the access to. A permissions declaration has the following format:
<<metaspace name>|<space name>|<metaspace name>/<space name>> <<user name>|<group name>>=<permission>,...
where permission can be any of the following:
For detailed information on the permissions, see User Access Control.
You can use a wildcard character (*) for the metaspace name or space name. A single wildcard character (*) can replace both the metaspace name and space name to designate that the permissions will apply to all metaspaces and all spaces. For example:
// Examples:
// domain1-ms1/* group1=read, seeder
// domain2-ms4/sp1 group2=write, encrypt
// */sp2 group1=write, invoke
//
permissions
ms/* group1=seeder,read,write,encrypt
 
 
Permissions Precedence
Permissions precedence is based on the following evaluation rules:
1.
2.
3.
4.
5.
The permissions rules work as follows:
Scope rule   When an access control list (ACL) is enabled, any connection request to a metaspace must be associated with a valid space-level permission entry, which implicitly grants access to the metaspace.
If there is no space-level permission, the client’s connection to the controller fails even if authentication is successful. The only exception is when the user cannot be mapped to the group list and the ACL’s default access is grant_all. In other words, any successful connection to a metaspace requires that one or more permissions with a corresponding scope exist in the permissions table.
The minimum permission required on any scope is read, which implies the right to connect to a metaspace.
Denial rule  A deny_all declaration for a user or group takes ultimate precedence over any other permission declaration that might apply to the same user or group.
Ambiguity rule  If there are multiple permissions that can be applied to a metaspace or space, then the permissions declaration that explicitly names the metaspace or space takes precedence over any permissions declarations that use a wildcard character (*).
Owner rule  If there are multiple permissions that can be applied to a user, the permissions declaration that explicitly names the user takes precedence over any permissions declarations applied to a group that the user is a member of.
Order rule  If after applying the above rules there is still more than one permission that applies to the authenticated user’s context, the effective privilege is retrieved from the most recent (lowest) matching permission in the table.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved