AMO Security Classes
New: 5 December 2005
Security in Microsoft SQL Server 2005 Analysis Services (SSAS) security is managed by using roles and permissions. Roles are groups of users. Users, also called members, can be added or removed from roles. Permissions for objects are specified by roles, and all members in a role can use the objects for which the role has permissions. All members in a role have equal permissions to the objects. Permissions are particular to objects. Each object has a permissions collection with the permissions granted on that object, different sets of permissions can be granted on an object. Each permission, from the permissions collection of the object, has a single role assigned to it.
This topic contains the following sections:
- Role and RoleMember Objects
- Permission Objects
The following illustration shows the relationship of the classes that are explained in this topic.
Role and RoleMember Objects
A role is a containing object for a collection of users (members). A Role definition establishes the membership of the users in Analysis Services. Because permissions are assigned by role, a user must be a member of a role before the user has access to any object.
A Role object is composed of the parameters Name, Id, and Members. Members is a collection of strings. Each member contains the user name in the form of "domain\username". Name is a string that contains the name of the role. ID is a string that contains the unique identifier of the role.
A Role object is created by adding it to the roles collection of the database, and updating the Role object to the server by using the Update method. A Role object has to be updated before it can be used.
To remove a Role object, it has to be dropped by using the Drop method of the Role object. The Remove method, from the roles collection, only prevents you from seeing the role in your application, but it does not remove the role from the server. A Role object cannot be dropped if there are any permissions associated with it.
A RoleMember object is created by adding a user to the members collection of the role and updating the Role object to the server by using the Update method. Only Server Administrators or Database Administrators are permitted to create roles. A Role object has to be updated to the server before any of its members is allowed to use any the objects to which the user has been granted permission.
To remove a RoleMember object, it has to be removed from the collection by using the Remove method of the collection, and then updating the role by using the Update method.
For more information about methods and properties available for these objects, see Microsoft.AnalysisServices.Role and Microsoft.AnalysisServices.RoleMember in the Microsoft.AnalysisServices namespace.
Permission Objects
Permissions are associated with an object (cube, dimension, others) for a particular role. Permissions specify what operations the member of that role can perform on that object.
The Permission class is an abstract class. Therefore, you must use the derived classes to define permissions on the corresponding objects. For each object, a permission derived class is defined.
Object | Class |
---|---|
Possible actions enabled by permissions are shown in the list:
Action
Values
Explanation
Process
{true, false}
Default=false
If true, members can process the object and any object that is contained in the object.
Process permissions do not apply to mining models. MiningModel permissions are always inherited from MiningStructure.
ReadDefinition
{None, Basic, Allowed}
Default=None
Specifies whether members can read the data definition (ASSL) associated with the object.
If Allowed, members can read the ASSL associated with the object.
Basic and Allowed are inherited by objects that are contained in the object. Allowed overrides Basic and None.
Allowed is required for DISCOVER_XML_METADATA on an object. Basic is required to create linked objects and local cubes.
Read
{None, Allowed}
Default=None (Except for DimensionPermission, where default=Allowed)
Specifies whether members have read access to schema rowsets and data content.
Allowed gives read access on a database, which lets you discover a database.
Allowed on a cube gives read access in schema rowsets and access to cube content (unless constrained by CellPermission and CubeDimensionPermission).
Allowed on a dimension grants that read permission on all attributes in the dimension (unless constrained by CubeDimensionPermission). Read permission is used for static inheritance to the CubeDimensionPermission only. None on a dimension hides the dimension and gives access to the default member only for aggregatable attributes; an error is raised if the dimension contains a non-aggregatable attribute.
Allowed on a MiningModelPermission grants permissions to see objects in schema rowsets and to perform predict joins.
Note Allowed is required to read or write to any object in the database.
Write
{None, Allowed}
Default=None
Specifies whether members have write access to data of the parent object.
Access applies to Dimension, Cube, and MiningModel subclasses. It does not apply to database MiningStructure subclasses, which generates a validation error.
Allowed on a Dimension grants write permission on all attributes in the dimension.
Allowed on a Cube grants write permission on the cells of the cube for partitions defined as Type=writeback.
Allowed on a MiningModel grants permission to modify model content.
Allowed on a MiningStructure has no specific meaning in Analysis Services.
Note:
Write cannot be set to Allowed unless read is also set to Allowed
Administer
Note:
Only in Database permissions
{true, false}
Default=false
Specifies whether members can administer a database.
true grants members access to all objects in a database.
A member can have Administer permissions for a specific database, but not for others.
A Permission object is created by adding it to the permissions collection of the object and updating the Permission object to the server by using the Update method.
To remove a Permission object, it has to be dropped by using the Drop method of the object. The remove method, from the permissions collection, only prevents you from seeing the permission in your application, but it does not remove the Permission object from the server. A role cannot be deleted if there is any permission associated with it.
For more information about methods and properties available, see Microsoft.AnalysisServices.Permission in the Microsoft.AnalysisServices namespace.
See Also
Reference
Concepts
Programming AMO Security Objects
Introducing AMO Classes
Other Resources
Permissions and Access Rights (SSAS)
Securing Analysis Services
Analysis Services Concepts and Objects
Analysis Services Objects