In Framework Manager, security is a way of restricting access to metadata and data across Cognos 8 products.
There are different types of security in Framework Manager:
data security 
You create a security filter and apply it to a specific query subject. The filter controls the data that is shown to your users when they set up their reports.
object security
You secure an object directly by allowing users access to the object, denying users access to the object, or keeping it hidden from all users.
package security
You apply security to a package and identify who has access to that package.
Each type of security uses users, groups, and roles to define access.
There are business reasons for restricting access to data. For example, you may have confidential data that only specific users are allowed to see. You may have a variety of data, and your users only need to retrieve data from specific tables or columns. Or, you may have a table that contains many records, and your users only need to retrieve a subset of records from that table.
If you are using SAP BW metadata, there can be underlying SAP BW security that affects your users’ access to level members. You cannot override SAP BW security in Framework Manager. For more information, see Import from an SAP BW Data Source.
Before you add security in Framework Manager, ensure that security was set up correctly in Cognos 8. For more information, see the Administration and Security Guide.
Users and groups are created for authentication and authorization purposes. You can use users and groups created in third-party authentication providers, or you can create your own in Cognos 8.
For more information about security, see the Administration and Security Guide. For more information about users, groups, and roles, see the Content Manager User Guide.
A user entry is created and maintained in a third-party authentication provider to uniquely identify a human or a computer account. You cannot create users in Cognos 8.
Information about users, such as first and last names, passwords, IDs, locales, and e-mail addresses, is stored in the providers.
Users can become members of groups defined in third-party authentication providers and groups defined in Cognos 8. A user can belong to one or more groups. If users are members of more than one group, their access permissions are merged.
Examples of groups are Employees, Developers, or Sales Personnel. Members of groups can be users and other groups. Group membership is part of the user’s basic identity. When users log on, they cannot select a group they want to use for a session. They always log on with all the permissions associated with the groups to which they belong.
A role is a special group. It represents a collection of users that have similar responsibilities and similar privileges in the organization. Members of roles can be users, groups, and other roles. Role membership is not part of the user’s basic identity.
You can use groups created by your organization in third-party authentication providers, or create new groups in the Cognos namespace.
Create Cognos groups when
you cannot create groups in your authentication provider
groups are required that span multiple namespaces
portable groups are required that can be deployed
you want to address specific needs of Cognos 8 administration
you want to avoid cluttering your organization security systems with information used only in Cognos 8
You can restrict the data represented by query subjects in a project by creating a security filter. The security filter controls the data that is shown to your users when they set up their reports.
For example, your Sales team consists of a Sales Director, and four Sales Managers. You create a security filter that includes a group for the Sales Director and a group for Sales Managers, and apply the filter to the Salary query subject. When the package is available for your users, and a report is generated for the Sales Managers and the Sales Director, only the Sales Director can see the salary information for the Sales Managers. For more information about groups, see Users, Groups, and Roles.
If a user has multiple roles, the security filters belonging to these roles are joined together with ORs. If a role is based on another role, the security filters are joined together with ANDs.
You can base the security filter on an existing security filter. If you choose this option, the security filter inherits the filter and all the filter properties.
When you create a security filter, you can also use existing project filters, or create new filters using the expression editor. For more information, see Create a Filter.
Click the query subject you want, and from the Actions menu, click Specify Data Security.
To add new users, groups, or roles, do the following:
Click Add Groups.
In the Select Users and Groups window, add users, groups, or roles. For information about how to do this, see the Content Manager User Guide.
In the Select Users and Groups window, click OK.
If you want to base the group on an existing group, click a group in the Based On column.
Tip: If you do not see the group you want in the list, you must add the group to the security filter.
If you want to add a filter to a group, in the Filter column, click either Create/Edit Embedded Filter or Insert from Model.
If you want row-level security based on UserClass values stored in your data source, implement a parameter map that maps the values in the data source to the corresponding roles and groups based on the user you are logged on as.
You do this by using a parameter map as an argument with the CSVIdentityName macro function. This macro function retrieves account, group, and role information for the current user. It returns a string of comma-separated values from the parameter map in single quotation marks, such as 'clerks', 'technicians', or 'typists'.
The CSVIdentityName macro function is used as a key in the specified map. You can use the list that is returned to build partial In clauses or to filter data based on the identity name of the current user.
For example, you have user classes whose names do not correspond to the Roles_Groups parameter map:
Key (Role or Group) | Value (User Classes) |
Everyone | Group1 |
Authors | Group2 |
System Administrators | Group3 |
Query Users | Group2 |
NTLM | Group2 |
You have this query subject:
(Security_column, value 1, value 2, value 3)
When you add a filter to the query subject, the filter uses a macro to look up a list of values, for example:
Security_column in (#CSVIdentityName(%Roles_Groups)#)
For users in the Everyone, Authors, and System Administrators roles, testing shows this as:
Security_column in ('Group1','Group2','Group3')If security data in the data source is identical to the roles and groups defined in Cognos 8, you can use the CSVIdentityNameList macro function. The macro function optionally accepts a list separator as a parameter and then returns a separator-delimited list that can be used in a filter with the In operator. You do not need a parameter map.
Here is an example:
Security_column in (#CSVIdentityNameList()#)
For users in the Everyone, Authors, and System Administrators roles, testing shows this as:
Security_column in ('Everyone','Authors','System
Administrators')Consider the following:
users can belong to several groups or roles
there is no way to distinguish between groups and roles so each group and role must have a unique name.
this function works only in a filter and always returns 0..n values
Metadata security can be applied directly to objects
in a project. When you add object-based security, you apply a specific
user, group, or role directly to the object. You choose to make
the object visible to selected users or groups. You cannot deny
the Everyone group access to all objects.
If you do not set object-based security, all objects in your project are visible to everyone who has access to the package. Users, groups, or roles that do not have allow or deny settings for an object are considered to be undefined. The object then inherits the security that was defined for its parent object. When you explicitly allow or deny access to an object, you override the inherited settings. The parent and child objects then have different settings. When you apply security to a parent object, all its child objects in the model will also have security applied to them. After you set security for one object, you must set it for all objects. You can do this by setting security on the root namespace.
You may want an object to be visible to only selected users, groups, or roles. For example, in your project, you may have a Salary query subject. You can make the Salary query subject visible to the Managers group, and keep it hidden from everyone else.
If a user is a member of multiple user groups and an object is visible to one user group and denied to the other, the user will not have access to the object. For example, Jane belongs to two user groups: Sales and Marketing. The Sales group has access to the Products and Sales query subjects, and is denied access to the Sales Forecast query subject. The Marketing group has access to Products, Sales, and Sales Forecast query subjects. Jane does not have access to Sales Forecast.
When you secure an object, a package is automatically created in Framework Manager. The package name consists of an underscore (_) and the name of the secured object. These object-based packages are visible in the Explorer. You can use this package to see which objects in the project are included, hidden, or excluded from a specific user group.
Every time you include that object in a package, and publish it for your users, the same security rules apply for that object. When you publish a package that contains secured objects, the visible objects for users are the intersection of the package definition and the object security settings. If object-based security is not used, security applied to a package remains unchanged.
The security you specify for an object is passed to shortcuts that reference the secured object. If you have a shortcut to a secured object, only users with permission to see the secured object are able to see the shortcut in the published package.
If a model query subject, calculation, or filter references a secured object, the object’s security is not passed to the model query subject, calculation, or filter.
When you create a package containing the shortcut, the secured object does not need to be included in the package.
For example, only sales managers are allowed to see the Sales Target query subject. You create a shortcut to Sales Target. When you package the model, you include the shortcut but not the Sales Target query subject. Sales managers are the only ones able to see the shortcut in the published package.
If your model is segmented, object security is not inherited from the master model. You must define object security on all model segments.
To see a list of the object-based packages,
double-click the Packages folder. The list appears
in the Explorer tab. To see which objects are
secured against that specific object-based package, click the Packages folder,
and from the Actions menu, click Packages, Explore
Packages.
To determine if object-based security is set in the model, click
the Packages folder, and from the Actions menu,
click Packages, Explore Packages. Click
the Roles Explorer tab. If object-based security
was set, you see a package for the Everyone role.
To determine which objects are explicitly secured in the model, look at the object’s icon in the Project Viewer. The top left corner of the icon is marked with an overlay.
To find all objects that were explicitly secured under a given object, select the object and, from the Tools menu, click Find All Secured Objects.
To remove object-based security for a particular user, group, or role, delete the package for that user, group, or role from the Project Viewer.
To completely remove object-based security from the model, delete the package for the Everyone role from the Project Viewer.
Click the object you want to secure, and from the Actions menu, click Specify Object Security.
Tip: You can select more than one object at a time.
Select the users, groups, or roles you want to change. Or, click Add to add new users, groups, or roles.
For more information, see the Content Manager User Guide.
Specify security rights for each user, group, or role by doing one of the following:
To deny access to a user, group, or role, select the Deny check box next to the name for the user, group, or role. Deny takes precedence over Allow.
To grant access to a user, group, or role, select the Allow check box.
Tip: To allow everyone to see all objects unless specifically denied access, select the Allow check box for the Everyone role.
Click OK.
A list of new and updated object-based packages appears.
Click the secured object, and from the Actions menu, click Specify Object Security.
Remove security rights by clearing both the Allow and Deny check boxes for all users, groups, or roles.
Click OK.
A list of packages that are affected by these changes appears.
You can define or change metadata security after a package has been published. To define metadata security the first time you publish a package, see Publish a Package. You can also modify the security for a package from Cognos Connection.
You can organize your security by specifying which users, groups, and roles have access to certain parts of the published model.
To add metadata security, do the following:
 | Decide whether the objects can be selected, unselected,
or hidden in the package |
| | Decide which users will have administrative access to a package. |
| | Add users, groups, and roles to the package. |
When you apply administrative access to a package, you give access to the user or users who are responsible for
republishing a package in Framework Manager to the Cognos 8 server
ensuring that no reports are impacted when a Framework Manager package is republished to the server
Click the package you want to edit, and from the Actions menu, click Package, Edit Package Settings.
Click the Permissions tab.
In Cognos Connection, create, add, or remove groups or roles as required. For information about how to do this, see the Cognos Connection User Guide.
After you finish modifying the security for the package, click OK to return to Framework Manager.
