Components of the Security System

In this section:

The basic components of the security system are privileges, resources, and rules. The security policy for each user is determined by the combination of rules that applies to that user for each specific resource. The rules control which privileges are available to each user under different circumstances. For example, a user may have the privilege to edit a resource in one folder, but not another.

Privileges

In this section:

A privilege controls access to a tool, resource, or ability. For example, different privileges control access to each of the following:

Similar privileges are grouped into roles so they can be used in security rules. Privileges and roles are used in rules that associate users and groups with resources. For example, you might want to create a role containing all the privileges you wish to grant basic users or a role containing all the privileges you wish to grant developers.

For a list of all privileges, see Privileges.

Types of Privileges

In this section:

When you are creating or modifying roles or rules, it is important to understand what the privileges involved do, how they are used, and where they apply.

Local Privileges

Local privileges define functional capabilities that users can be assigned on one or more subsystems. Local privileges are used to enable shortcut menu choices, such as Run on a report or Delete on a folder. Local privileges also determine which items are shown inside tools, such as which users are displayed inside the Security Center or which schedules appear in ReportCaster. For example, group managers may be permitted to see only users in the groups they manage, rather than all the users in the system.

Local privileges are evaluated for each user at every level within a subsystem. They can be permitted for a user on one folder and denied on another. For example, a user might be permitted Access Resources and Run Procedures on the Sales workspace folder but denied these privileges on a subfolder. The user could run reports in the Sales folder but could not see the subfolder or run reports inside it. When users belong to multiple groups, they may be permitted a local privilege in one group and denied the privilege in another. In such cases, the users are denied the privilege.

Local privileges are evaluated when features such as tree controls or tool UIs are rendered. Changes to local privileges take effect immediately, but users may need to refresh or reload the interface to see the changes. For example, if the Access Resource privilege on the Sales subfolder is granted to a user who was previously denied the privilege, the user may need to refresh the display of the Sales folder in order for the subfolder to appear.

In the Security Center, local privileges have one or more IBFS subsystem names listed in the For Subsystem(s) column. An asterisk in this column means that the local privilege can be used with any subsystem.

Session Privileges

Session privileges define functional capabilities that users can be assigned during the sign-in process. Session privileges are used to enable menu bar drop-down list items, nodes on the Resources tree, and other global user capabilities, such as many of the buttons in the desktop products.

Session privileges are evaluated for each user when they sign in. The rules that are set on the Workspaces node (WFC/Workspaces) and on subfolders beneath it to the depth specified by the Session Privilege Search Depth (IBI_SESSION_PRIVILEGE_SEARCH_DEPTH) setting are evaluated. The default value is 1, which means that, by default, the evaluation only looks for session privileges on workspace folders immediately under the Content node.

Note: As you increase the Session Privilege Search Depth (IBI_SESSION_PRIVILEGE_SEARCH_DEPTH) setting, the evaluation searches deeper into the repository for resources accessible to the user during sign-in. This may increase the amount of time it takes to process sign-in operations. To prevent performance issues, we strongly recommend that the Session Privilege Search Depth (IBI_SESSION_PRIVILEGE_SEARCH_DEPTH) setting be no greater than 2. For more information about the Session Privilege Search Depth (IBI_SESSION_PRIVILEGE_SEARCH_DEPTH) setting, see BI Portal Settings.

When session privileges conflict (for example, when a user is permitted a session privilege because of membership in one group and denied the privilege because of membership in another), users are permitted the privilege. For example, a user who is permitted Display Favorites Node (opFavorites) because of membership in one group and denied it because of membership in another will be permitted the privilege, enabling the user to see the Favorites node on the Resources tree.

Note: This is the opposite of the resolution of conflicts for local privileges, where privileges that are both permitted and denied are evaluated as denied.

Changes made to session privileges take effect the next time a user signs in.

In the Security Center, session privileges are listed as Session in the For Subsystem(s) column.

Hybrid Privileges

A privilege that is both a local privilege and a session privilege is a hybrid privilege. Hybrid privileges are used for dual purposes: to enable some global capability and to optionally enable local capabilities within a subsystem.

For example, the hybrid privilege Run Procedures Deferred is listed as Session, WFC. The session privilege part of this hybrid privilege is used to determine whether to show Deferred Status in the Tools menu, and the local privilege is used to determine whether to enable the Run Deferred option on the shortcut menu of procedures under the Workspaces node.

In a typical deployment where the Session Privilege Search Depth (IBI_SESSION_PRIVILEGE_SEARCH_DEPTH) setting is 1, rules that include hybrid privileges should be permitted on at least one top-level workspace folder, although they can also be denied on other top-level folders or on subfolders. This configuration prevents the situation in which a user is able to run a procedure deferred, but is subsequently unable to retrieve the output from the deferred request.

In the Security Center, hybrid privileges are listed with Session and one or more subsystems.

Resources

In this section:

A resource is any folder, item, library content, portal, privilege, report procedure, role, user, or group to which access can be controlled or to whom abilities can be granted.

Different resource types have different controlled privileges. For example, all resource types can be deleted, but report request resources cannot be made members of a group and user resources cannot be run or scheduled.

Users gain access to resources from items listed on the Resources tree or displayed in the content area. For customers with legacy licenses, the visibility of licensed components depends upon the license key installed with the product.

Viewing Resource Components

The most complete display of licensed components appears in the Workspaces area.

To open the Workspaces area directly from the Hub, select Workspaces from the side navigation pane, as shown in the following image.

The Workspaces Area that opens from the Navigation Bar.

You can also open the Workspaces area from the WebFOCUS Home Page by selecting Workspaces in the banner, as shown in the following image.

The Banner on the WebFOCUS Home Page highlighting the Workspaces link.

The WebFOCUS Explorer opens and displays links to existing workspaces and folders, as shown in the following image.

WebFOCUS Home Page Workspaces area.

When you open a folder from the WebFOCUS Home Page, the WebFOCUS Explorer displays the items that folder contains, as shown in the following image.

The Workspaces area showing an individual workspace with folders.

When you open a folder from the Workspaces view in the Hub, the WebFOCUS Explorer displays the items that folder contains, as shown in the following image.

The Workspaces area showing an individual workspace with folders.

Visual cues indicate whether resource items are private or published, shown or hidden, shared or not shared. In the Workspaces area, resources that are shown are visible to users who are not able to use them to create content. Resources that are hidden are not visible to those users.

In the Resources tree, private workspaces are displayed in italics. Published workspaces are not. Hidden workspaces are dimmed. Workspaces that are to be shown are not dimmed. These variations are shown in the following image.

In this example, the Human Resources entry is not dimmed and does not use italics. The folder it represents is published and is shown. The Marketing entry is dimmed and uses italics. The folder it represents is private, and is hidden. The Purchasing entry is not dimmed but uses italics. The folder it represents is private, and is shown. The Sales entry is dimmed and does not use italics. The folder it represents is published, and is hidden.

In the content area, the same conditions affect the display of items in similar ways. Private folders display a Private icon. The private icon pictures a published document with a strikethrough symbol The Private Icon a published document with a strikethrough.. Published folders do not include this icon. Hidden folders include a Hidden icon. The hidden icon pictures an eye with a strikethrough symbol The Hidden Icon represented by a eye with a strikethrough.. Folders that are to be shown do not include this icon. These variations are shown in the following image.

In this example, the Human Resources folder displays no icons. The folder it represents is shown and published.

The Marketing folder displays a hidden and private icon. The folder it represents is hidden and private.

The Purchasing folder displays a private icon. The folder it represents is shown and private.

The Sales folder displays a hidden icon. The folder it represents is hidden and published.

The same visual cues apply to items within folders, as shown in the following images.

The Items panel of the Content view showing report and chart items in their various conditions.

In this example, the SalesByCity report shows no icons in the tile other than the thumbnail for the report itself. The report it represents is published and is shown.

The SalesByCountry chart shows a private icon and a hidden icon in the tile. The private icon pictures a published document with a strikethrough symbol. The Private Icon a published document with a strikethrough. The hidden icon pictures an eye with a strikethrough symbol. The Hidden Icon represented by a eye with a strikethrough. The chart it represents is private, and is hidden.

The SalesByRegion item only shows a private icon in the tile next to the chart thumbnail. The chart it represents is private, and is shown.

The SalesByState report item only shows a hidden icon in the tile next to the report thumbnail. The report it represents is published, and is hidden.

When you right-click a resource, the options presented to you are based on your privileges and the status of that item. When you right-click a published item, you are presented with the option to Unpublish it. If that item is private, you are presented with the option to Publish it.

You can also view the publish or show status of an item from the Properties dialog box. To open it, right-click the item in the Resources tree or content area and select Properties. The Yes option in the Publish setting is selected if the item is published, and the No option is selected if it is private. Similarly, the Yes option in the Show setting is selected if the item is to be shown to users who cannot use it to create content, and the No option is selected if it is to be hidden from those users.

You can share private folders and resources in the My Content folder or in any sub-folder within it. Within the content area of these folders, shared resources are identified with a Shared icon .

Icons for resources that are shared display this additional icon as an overlay .

Icons for resources that are not shared do not display this additional icon .

The overlay applies to folders and to individual items. As shown in the following image, the 11_November_Sales folder, the Pipeline_Prospects report, and the Sales_Expense_Current_Year report are all shared.

Shared folders and resources displayed in the content area of a My Content folder.

As shown in the following image, the Sales By Region chart is shared, but the Sales By City report is not shared.

Shared and unshared resources as shown in the content area.

Note: Tiles representing resources configured to Run With Insight will also include the Run With Insight icon, as shown in the following image.

A resource tile showing the Run With Insight icon.

The Run With Insight icon The Run with Insight icon that represents an index finger selecting a button or onscreen option. represents an index finger selecting a button or onscreen option. For more information, see the TIBCO WebFOCUS® User's Guide.

User and Group Resources

In this section:

A user is identified by a unique ID and may also have additional properties, such as description, email address, password, group memberships, and active, inactive, or AUTOADD status. Groups are formed of users or subgroups, in which all members require similar capabilities or access to the same resources. All users are members of the EVERYONE group, which is the set of all named users in the system.

Note: In multi-tenancy SaaS deployments, although tenant users belong to the EVERYONE group along with the service provider users, the tenant users are only aware of other users within their own organization.

Explicit and Implicit Groups

The groups to which a user is assigned are called explicit groups. Users always have at least one explicit group because they all belong to the EVERYONE group. Groups can also be nested in a hierarchy to simplify administration. In the hierarchy, if a subgroup is nested in a parent group, the users who are members of the subgroup are considered to be members of the parent group. The subgroup is an explicit group for its members and its parent group is an implicit group.

In the following image, the Sales group is the implicit group, and the BasicUsers group under Sales is the explicit group.

Security rules apply to both implicit and explicit groups. That is, rules which apply to the implicit group also apply to the explicit group nested in it.

Note: In multi-tenancy SaaS deployments, the EVERYONE group and its members are not visible to tenant users.

Private and Published Resources

In this section:

Content resources, such as portals, reports, and procedures, are either private or published. Private content is available only to the owner and authorized users with whom it is shared. Published content may also be shared with authorized users, but user access to published content is controlled by rules, rather than the individual decision to share it. Published content is considered authoritative and has usually undergone quality assurance and testing before being published for the user community.

Private Resources

How to:

All resources are initially created as private resources. The security policy for private resources specifies the following:

  • The owner of the resource is the user who created the resource.
  • The resource does not inherit security policies from its parent.
  • The owner has full control over the resource.
  • Administrators with the Manage Private Resources privilege over a group to which the owner belongs can take control of the resource. This allows administrators to manage resources belonging to inactive or deleted users, whether by deleting the resources, publishing them, or transferring their ownership to another user or group.
  • A private resource may be owned by a group or a user, but it may not have multiple simultaneous owners. For a group to own a private resource, an authorized user, such as an owner or an administrator with the appropriate privileges, must transfer the ownership from a user to the group.
  • ReportCaster schedules can only be owned by a user.

Private content comes in the following forms:

My Content

The reports, output, and schedules created by a user. This content remains private to a user unless the user is authorized to share it with others and chooses to do so, or unless an administrative user with the ability to manage private content for that user publishes the content.

Other private content

Private content that is intended to be accessed by a particular group of developers or that is being prepared for publication. This allows new content to be tested before publication even when it is created in a production environment, a situation most typical of SaaS deployments, where tenant developers may only have access to a single environment.

A My Content folder can be created automatically for published folders to give users a place to save items, such as procedures and reports. The parent folder must have the Automatically Create a My Content Folder property enabled and the user must have the My Content Folder privilege.

The Automatically Create a My Content Folder property is activated, by default, for top-level folders created from the Enterprise Domain Resource Template. It is not activated, by default, for top-level folders that are not based on the Enterprise Domain Resource Template. To add a My Content folder to these folders, follow the steps in the topic, How to Add a My Content Folder.

Note: We recommend that you set this property only on top-level folders.

Procedure: How to Add a My Content Folder
  1. Right-click the folder, and select Properties.
  2. In the Properties panel, select the Advanced tab.
  3. Select the Automatically create My Content folders check box, and then select Save.
    • If the folder is published, the screen refreshes, the cursor moves to the parent folder or workspace, and a My Content folder is created. To see it, expand the folder you just updated.
    • If the folder is not published, a My Content folder is created when you later publish the folder.

    Note: If you clear this check box after creating a My Content folder, the My Content folder is not removed.

Published Resources

Authorized users can publish private resources to make authoritative content available to a larger set of users. The security policy for published resources specifies the following conditions:

  • Published resources are owned by the system.
  • A published resource is subject to the security policy defined on its parent folder.
Shared Resources

In this section:

Sharing is a feature that is generally used to enable users to share private content residing in their My Content folders with authorized colleagues.

Shared resources are made available to other appropriate users through a special Shared Content folder. The Shared Content folder is a virtual folder that appears automatically in a folder whenever there is shared content inside that folder.

The Content Sharing Scope privilege determines the users and groups with whom the owner is authorized to share resources. The content owner must also be permitted one or more of the following privileges located under the Advanced Reporting folder of the Role dialog box.

Share Private Resources

The user can share resources by selecting Share from the resource shortcut menu. A resource is shared with everyone who can access the folder that contains it. This does not apply to library content.

Share Private Resources with Specific Users

The user can share resources by selecting Share with from the resource shortcut menu and clicking from a list of authorized users, groups, or users and groups. This does not apply to library content.

Share Private Library Content

The user can share library content.

There are two ways to share private resources from your My Content folder or folders within it. You can use the Share menu option to share a resource with everyone automatically, or you can use the Share With menu option and share the resource with a limited set of users or groups selected from the Share With dialog box. When you use the Share option, you share the resource with the EVERYONE group and grant basic user privileges to all users. When you use the Share With option, you share the resource with a limited number of selected users and groups, and grant privileges to them based on their role in the workspace in which the resource appears. You can use the Share option to make a resource generally available while it is still in development, and use the Share With option to share resource development tasks with other users without making the resource generally available.

When you share a resource from your My Content folder or one of the folders within it, all users other than yourself will see it under a folder entitled Shared Content. When you open a Shared Content folder, you see a subfolder for each user who has shared content with you. This feature helps you distinguish between content you created, which appears in the My Content folder, and content created by others but shared with you. In the following image, the Administrator folder, which contains content the Administrator made available to an individual user, appears under the Shared Content folder as shown in the Content view.

Understanding How Sharing Affects Folders and Resources in the Hierarchy

In order to protect the integrity of unshared resources within a workspace while continuing to grant appropriate access to shared resources, the folders and parent folders that contain a resource adjust their own shared status automatically.

When you share a resource within a folder, that folder and all of its parent folders up to the My Content folder, are shared automatically. This automatic update helps ensure that a newly-shared resource will not be unavailable because it is located in a folder that is not shared. The same behavior occurs if you share a folder within a hierarchy. All folders above the shared folder, up to the My Content folder, are shared automatically. This behavior automatically ensures that no unshared folder in a hierarchy will block access to shared folders or resources under it.

If you unshare a folder after sharing it, the shared resources within it are also unshared automatically in keeping with the unshared status of the folder in which they appear. The same behavior occurs if you unshare a parent folder in a hierarchy. All folders and resources under the newly unshared folder are also unshared automatically. This behavior ensures that all folders and resources within an unshared folder are rendered unavailable and reinforces the decision to make a folder and the resources within it unavailable to other users.

If you share a folder again after unsharing it, the resources within it are not shared automatically. You must open the folder and share the resources within it individually. The same behavior occurs if you share a parent folder in a hierarchy after unsharing it. None of the folders and resources under the re-shared folder are shared again automatically. You must open and share them individually, but remember that sharing a resource within a hierarchy automatically shares the folder and any parent folders that contain it. This behavior enables you to maintain shared and unshared resources in the same folder, and keeps unshared resources unavailable even though they are located within a shared folder.

When you unshare an individual resource within a shared folder, you do not automatically unshare the folder in which it appears. That folder continues to be shared until you unshare the folder itself. This feature ensures that a folder continues to provide access to shared resources even though one or more resources within it are no longer shared. The same behavior occurs if you unshare a folder within a hierarchy, the folders above it remain shared until you change the shared status of those folders individually.

As a rule, sharing a resource or folder automatically shares the folders above it. Unsharing a folder automatically unshares the folders and resources below it. The only exception to this rule are individual resources or folders that have no folders under them. When you unshare these items, there is no impact anywhere else in the hierarchy.

Once you share an individual resource, that resource remains shared until you unshare it or until you unshare the folder or parent folder that contains it. Once you share a folder, it remains shared until you unshare it or a parent folder. You can unshare an individual resource without unsharing the folders that contain it. This behavior keeps shared resources available even if they are included in a folder with unshared resources.

Sharing Resources

The ability to share or unshare private resources only applies to resources located in the My Content folder of a workspace or in one of the child folders within the My Content folder. For more information about how to share resources, see the Configuring and Using Your TIBCO WebFOCUS® Environment technical content.

Rules

In this section:

Rules determine what a user is allowed or not allowed to do in any particular location. A rule associates a resource with a subject (a user or group), a role, an action (such as permit or deny), and a scope (whether the rule applies only to the resource, only to its contents, or to both). Through these rules, users are either permitted or denied the various privileges contained in the role.

Note: Typically, the subject of a rule is a group. It is possible to apply a rule to a single user, but it is not recommended, because managing the rules on an individual user basis can become unwieldy.

Effective Policy

In this section:

How to:

A combination of rules determines whether or not a user can access a particular tool, resource, or ability. Users who belong to multiple groups may be permitted the use of a tool in one group and denied the use of the tool in another. A folder may have no rules explicitly applied to it, but inherit the rules of its parent folder. When a user attempts to access a resource, all of the relevant security rules are evaluated, and the result of the combined rules for the user on that resource is determined. This result is the effective policy for the user on the resource.

Rules that are relevant to the given subject and resource can include:

  • Rules that apply to the resource for the explicit and implicit groups to which the user belongs.
  • Rules that apply to the resource directly for the user account.
  • Inherited rules that apply to the parent of the resource for the user or group.

When a user does not have the abilities that you expect, reviewing the effective policy for users can be a helpful troubleshooting step.

Order of Precedence

Conflicts between rules are resolved by the order of precedence. Listed in descending order, the order of precedence is:

  • Clear Inheritance
  • Over Permitted
  • Denied
  • Permitted
  • Not Set

In general, rules are used to permit privileges, because, by default, privileges are not permitted. Privileges not explicitly permitted (by Permit or Over Permit) are denied. By default, privileges are Not Set, which means they are not permitted. When one rule permits a privilege for a user on a resource and another denies it, the privilege is typically denied. (Session privileges are treated differently, as discussed below.) Permitted rules overturn Not Set rules, resulting in an effective policy that permits the privilege. Denied rules overturn Permitted rules (except for session privileges), resulting in an effective policy that denies the privilege. Over Permitted rules overturn Denied rules, resulting in an effective policy that permits the privilege.

No group takes precedence over another group and user rules do not take precedence over group rules. If you would like to permit individual users a privilege denied to their groups, you cannot permit this privilege simply by creating a rule that permits the privilege for the user on the selected resource, because the effective policy for the user is determined by prioritizing the rule that denies the privilege to the group over the rule that permits the privilege to the user. Instead, you must create a rule that over permits the privilege to the user, which will be prioritized above the rule that denies the privilege to the group.

Over Permitted rules are typically used to address unusual situations, such as when one member of a group needs access to a resource, but access is denied to that group. Over Permitted rules can also be used to ensure that a privilege is always permitted to a particular group, no matter what other rules apply. For example, a built-in rule that Over Permits the Full Control role to members of the Administrators group on IBFS:/ (the entire file system), with the scope of folder and children is included. This rule is a safeguard that prevents administrators from losing control of resources within the system if a Denied rule is applied to the EVERYONE group.

The Clear Inheritance rule removes an inherited rule for a role on a resource, changing the access on the resource to Not Set. When a user belongs to multiple roles with overlapping privileges, any privileges shared with the cleared role are evaluated to Not Set.

Session privileges enable menu bar drop-down list items, nodes on the Resources tree, and other global user capabilities, such as many of the buttons in the desktop products. Because session privileges govern access to tools that may be necessary in multiple locations, a session privilege is permitted when it is denied by one rule but permitted by another. For example, if you are able to run deferred procedures in the Sales folder but denied this ability in the Finance folder, you still need access to the Deferred Status interface so that you can see your deferred reports from the Sales folder.

Procedure: How to View the Effective Policy for a User on a Resource

The Effective Policy dialog box indicates why a user does or does not have a certain capability. To view the effective policy of other users, you must be permitted the following privileges:

  • View Rules on a Resource (opViewRulesOn), which enables the Rules on this Resource and Effective Policy options on the Security shortcut menu.
  • Manage Rules on Resources (opManageRulesOn), which enables the Rules option on the Security shortcut menu.

Users with only the View Rules on a Resource privilege may view the effective policy only for themselves, on particular resources. If a user does not have the appropriate privileges, the options to view or manage rules and effective policy will not appear in the shortcut menus.

  1. Right-click a resource and click Security, then Effective Policy.

    The Effective Policy dialog box appears, listing the effective policy calculated for each privilege appearing in a rule on this resource.

    If you have the appropriate privileges, you can select other users from the User drop-down list to see their effective policies.

  2. To show the effective policy for all privileges for this user on this resource, including those not applied to the resource in any rules, select Show all Privileges.
  3. To see how the effective policy for a privilege is evaluated, select the privilege in the Privileges box.

    The Effective Policy dialog box displays the policy evaluation for all the groups to which the user belongs at every level of the hierarchy above the resource, displaying the following information for each level:

    • Path Element.
    • Effective Policy. The access set on this folder by the combination of all applicable rules.
    • Subject.
    • Role.
    • Access. The access set on this folder by rules applying directly to this level of the hierarchy.
    • Apply To. Whether the policy applies to the folder for the path element only, the folder and its children, or only the children of the folder for the path element.
  4. To produce a rich text version of the information produced in the dialog box, select a privilege and click Create Report.