This article discusses topics only applicable to users created via Azure Active Directory (AAD). For information on how to assign a Permission Group (i.e., an Attribute Based Permission) to a user, see How To Create & Assign Permission Groups. Permission Groups (also known as “Attribute Based Permissions” should not be confused with Content Limitations.
Permission Groups (also known as Attribute Base Permission) are used by Assette Admins to limit the scope of users based on Account, Product, and/or Recipients based on the data. Permission Groups helps to silo users and only show the user pertinent information— be the user a Subject Matter Expert or Portfolio Manager. Within each Permission Group there are several attributes which can be ascribed to each user or group of users and can be created as shown below. The attributes derived from the corresponding System Data Block, though that data ultimately is sourced from the respective Source Data Block.
| Data Block | Description |
|---|---|
| Account Master Data Block | The Account Master (AccountMaster) Data Block is an Assette System Data Block which houses account attribute data such as asset class, share class, whether the account is open or not, etc. The Account Master (AccountMaster) Data Block is a System Data Block and is not usually edited by end users, though the dependency GetAccountMetaDataForSystemBlock Data Block is expected to be edited. |
| Countries Data Block | The Countries Data Block surfaces the country codes and names. By default, this list is retrieved from Assette’s internal database. If a client desires to maintain their own countries list, the Data Block CountriesLocaldb must be modified. |
| Currency Codes Data Block | Retrieves the values for all currency codes including the ID, Symbol, description, isDeleted, and short code from the Source List of Currency Codes Data Block, a Constant Data Block. For more information, see Source List of Currency Codes Data Block. |
| Product Master Data Block | The Product Master (ProductMaster) Data Block houses information related to offered products including the product’s name, asset class, whether it is a marketed or not, among other data points. If you are attempting to edit or update the Product Master, please see Product Master Sync (ProductMasterSync) Data Block and DEMO_SnowFlakeProductMasterExtract instead. The Product Master (ProductMaster) Data Block cannot be deleted though it can be edited. |
| Vehicles Data Block | The Vehicles (Vehicles) Data Block is a System Data Blocks which surfaces vehicle types from the Vehicle Local Database (VehicleLocalDb) Data Block. |
Permission Groups ensure that data-level restrictions are applied both during the generation of output and previewing of templates. This means that users can only generate or preview templates for the accounts and products assigned to them through their Permission Group. For example, if an attribute is defined for “USA” and 8 accounts are associated with that attribute, users in that permission group will be limited to generating or previewing reports for only those 8 accounts. Furthermore, users will also be able to see reports generated by others, but only for the accounts and products within their Permission Group. This ensures permissions are consistently enforced throughout the entire reporting process, from creation to review.
It is important to note that Permission Groups are strictly data-based and operate independently from limitations—which limit contents’ usage or inclusion in a wider context (e.g., a including a Smart Page in a Smart Doc). All users with the proper role can view and access all templates (including Smart Pages, Smart Docs, and Smart Shells), but the ability to generate reports with data is restricted to the accounts and products within their Permission Group. This ensures that while users can see the available templates, the data they can generate, and preview is limited to the accounts assigned to their specific permissions.
Impact on Clients Using SSO #
For clients using SSO, external roles defined within the client’s identity provider (such as Azure Active Directory) are mapped to internal roles defined within Assette. Upon logging in via SSO, a user automatically gains access to the relevant features based on the assigned internal roles, inheriting the appropriate permissions without the need for manual intervention.
To request for SSO users, clients should provide a detailed document outlining their external user roles and how they align with Assette’s internal roles. While roles in Assette restrict access to features, attribute-based permissions (ABP) control access to specific data. For example, a client’s “Authoring Team” might be mapped to the “Content Author” and “Workflow Admin” roles for feature access, with ABPs applied to further restrict data access. Once Assette receives this mapping document, the appropriate permission groups and data restrictions are created in the Admin Center, ensuring that SSO logins are accurately aligned with both user roles and data permissions.
Managing Attributes: What They Are, and How They Are Managed #
Attributes within Assette are defined and managed in the Admin Center’ Attribute Master. Here, administrators can create and manage different attributes that define access at various levels. Attributes could represent anything from accounts and products to specific content types or recipients. Only users with administrative access can create and modify these attributes, ensuring that permissions are tightly controlled.
Examples of Attribute-Based Permissions in Action
- Limiting Access Based on Account: Suppose that a user should only have access to content related to a specific account. An attribute can be created that restricts her access to only the account, both in terms of content generation and viewing output. This means that when Susy logs in, she will only see and interact with data pertaining to the account, ensuring a streamlined and secure experience.
- Restricting Access by Product: Consider a scenario where a user is responsible for generating content only for a particular product, “Equity Funds.” By creating a Permission Groups, permissions can be configured so that the user only has access to information and content generation options related to “Equity Funds.” This helps maintain focus and limits exposure to other unrelated product information.
- Managing Permissions Based on Recipients: In cases where different teams handle content for different recipient groups, such as “Institutional Clients” and “Retail Clients,” attributes can be set up to control access based on these recipient types. For example, a user assigned to the “Institutional Clients” attribute would only be able to generate content and view information meant for institutional recipients, keeping the content generation process efficient and tailored.