Noetix Platform Security Set Up
This chapter explains how Noetix Platform security is set up.
Overview
COPIED SECTION TO NQS ADMIN HELPIn most businesses, access to data is granted to groups of individuals because of their department or job. For instance, the entire sales department may have access to some pieces of data, but only the sales managers can access other pieces of data. Generally, the number of individuals who need special access to data is limited.
Manage Permissions
Permissions are the access rights you grant to users, roles, and organizations. These allow you to determine which permissions you want a user, role, or organization to have to an object.
You may grant permission () or revoke permission (
) to an object. Revoking a permission will deny access to the object even if the user inherits the permission from another role.
When you want to give users the ability to access a virtual table (VTable), you will need to either explicitly or implicitly grant them Select permission to the mapping and connection associated with the VTable.
The Select permission is typically the only permission that you will grant to users on your system. If you have users that also need to be able to develop new objects in Noetix QueryServer (NQS), you can grant them additional permissions.
To move an object, you need to have the Alter permission on it. To copy an object, you need to have the Create permission on the new container you are copying the object into.
There are five different permissions that can be granted to determine how a user can use and modify a folder as shown in the table.
Permission |
Description |
Select |
Allows a user to “see” the objects. This is a read-only permission. |
Allows a user to delete an object or any of its contents. When a Noetix WebQuery (NWQ) folder is deleted, any folders or links to queries within the folder are deleted as well. When a link to an NWQ query is deleted, only the link is deleted; the query still exists in the owner’s Personal folder. |
|
Allows a user to change the attributes of an object, such as the name or description. |
|
Allows a user to create objects within other objects. |
|
Allows a user to adjust the permissions for an object. |
Granting, Revoking, and Inheriting
You can grant or revoke each permission, or allow users to inherit a permission from an organization or another role.
Grant: Explicitly grants a permission to members of this role. When you “grant” a permission, you are directly or “explicitly” giving permission to perform an action on the object.
Revoke: Explicitly disallows a permission to members of this role. Most of the time, administrators will grant permission to objects. Conversely, if want to make sure that a user or organization does not have access to an object, you can explicitly revoke permissions.
If NQS finds a revoked permission while compiling the effective permissions of a user, this will override all other granted permissions from any source and the user will be denied access. Due to the severity of revoking permissions, Magnitude recommends that administrators use this feature infrequently.
Revoking a permission has the same overriding effect that was described for granting permissions.
Inherit: Allows members of a role to be granted or revoked a permission from other roles or organizations. Basically, this leaves their assignment to that permission “as-is.”
Explicit, Implicit, and Effective Permissions
Permissions can be explicit or implicit:
Explicitpermissions: Granted directly to the user, role, or organization.
Implicitpermissions: Inherited from parent organizations, granted roles, and so on. A user has implicit permissions when an organization they belong to or any role granted to them or to an organization they belong to has been granted the permission.
Effective permission: Sum of all the explicit and implicit permissions a user has been granted is called their “effective permission.” All explicit and implicit permissions are “rolled up” to determine the effective permissions that a user has, which then determines what they can and cannot access.
Options for Granting Permission
NEED A NEW SECTION TITLE/HEADERNQS has a robust security model that gives you fine control over who can access what data. You can grant or deny each user, Organization, or Role permissions to every type of object in NQS (Servers, Connections, VTables, Mappings, etc.).
In order to explain how Noetix security works, we will look at how a user is allowed to run a query (or SQL command) against an NQS VTable.
In US.Sales.Orders VTable Set Up in NQS, the following NQS objects have been set up:
A single Server, called “SalesServer,” has been set up in NQS.
The “SsalesServer” has a single Connection, called “Conn1.”
A single VTable called “Orders” has been set up in NQS and placed in a subfolder called “Sales” inside a folder called “US.”
The “Orders” VTable has one Mapping, called “Map1.”A Server in NQS contains information about a physical server in the enterprise, such as the ODBC driver that should be used when connecting to it. A Connection in NQS contains information used to log on to the RDBMS, typically the user name and password of the database user that has access to the data that is being made available. In our case, this is the user that owns the “Orders” table.
US.Sales.Orders VTable Set Up in NQS
Noetix Administrators are in complete control of which folders and subfolders will be created and where VTables will reside. (Folders and subfolders should be used to group VTables based on the type of business information they provide.) A VTable in NQS basically contains a list of columns from which a user can select. A Mapping in NQS contains the SQL command that will be executed against the physical server in order to return one or more of the columns defined in the VTable. In order for NQS to know where this SQL command should be executed, a Mapping is also tied to one or more Connections.
When the user executes a query,the SQL command, NQS checks the following object permissions in this order:
First, NQS determines whether the user has permission on the Mapping that will be used.
If the user does have permission to a Mapping, NQS then checks to make sure that the user has permission to the Connection and the Server tied to this Mapping, and that the Server is enabled for querying.
Last, NQS uses the information stored in the Server and Connection objects to connect to the RDBMS. The transfigured SQL command is then issued to the physical server. This command may still fail if the user stored in the Connection does not have access to the underlying table, view, stored procedure, etc.
The following topics outline the security in more detail. For more information on security in NWQ, see “NWQ Security” on page 130.
Option 1: Grant Permission Directly to a User
If a Noetix Administrator uses the NQS Administrator tool and grants SELECT (+S) permission on a VTable to a user called “Sally,” then Sally has been granted “explicit permission” to the VTable (see Granting Sally Explicit Permission on “Orders” VTable). Sally can then log on to her favorite query tool and run a query against the “Orders” VTable.
Granting Sally Explicit Permission on “Orders” VTable
Option 2: Grant Permission to an Organization
What happens if a new salesperson (“Juan”) is added to Sally’s group? First, a new user account is created for Juan in NQS, and then the account is added to the “Pacific Northwest” Organization. To grant Juan the same permissions as Sally, the Noetix Administrator must now grant Juan the SELECT permission on the “Orders” VTable. This can quickly become quite a chore if there are many VTables in different subfolders that each salesperson needs access to.
One solution would be to grant the “Pacific Northwest” Organization the SELECT permission to the “Orders” VTable (see Granting Permission to “Orders” VTable via a Role) instead of granting permission directly to each individual user. Because Sally and Juan are both members of this Organization, they both will have “inherit permission” to the “Orders” VTable. In addition, any new users that are added to th “Pacific Northwest” Organization will also have the same permissions.
Granting Permission to “Orders” VTable via a Role
Option 3: Grant Permission to a Role, then Assign an Organization to the Role
What happens now if the sales staff in a different Organization also needs access to the “Orders” VTable? For example, there may be another Organization of high-tech sales people in Boston that have been added to the “New England” Organization.
The best solution would be the following:
On the “Orders” VTable, grant the SELECT permission to the “High Tech Sales” Role.
Grant the “High Tech Sales” Role to the “Pacific Northwest” and “New England” Organizations (see Granting the Role to Multiple Organizations).
Now users in either Organization will have “inherit permission” to the “Orders” VTable. In addition, any new users that are added to the Organizations will automatically have the access they need to do their job.
Granting the Role to Multiple Organizations
As an alternative to the previous scenario, we could have done the following:
On the “Orders” VTable, grant the SELECT permission to the “High Tech Sales” Role (same as in previous scenario).
Grant the “High Tech Sales” Role to the “Sales Department” Organization, which is the parent of the “Pacific Northwest” and “New England” Organizations (see Granting the Role to a Parent Organization).
Sally and Juan would not see any effect of this, but all users in any other Organization under “Sales Department” would also now have access to the “Orders” VTable.
Granting the Role to a Parent Organization
How NQS Determines Object Permissions
When determining whether a user has permission to access a virtual table, NQS checks the following permissions in this order:HAVE CRAIG or ALEXChin VERIFY THIS ORDER
NQS first checks to see if the user has been explicitly granted the Select permission on the VTable.
If the Select permission has not been granted explicitly to the VTable, NQS checks the organization that the user belongs to and then the organization that this organization belongs, and so on, all the way up to the root organization.
Next, NQS will check the permissions on all roles that have been granted at any level in this hierarchy.
NQS checks the VTable, subfolder, folder, and tables root to see if the user has permission to the object.
Checking Permissions at Each Level
Finally, all permissions that are found during this search is “added up” and becomes the “effective permission” of that user.
The effective permission of any object can be viewed in NQS Administrator by clicking the Show Effective button found in the Permissions tab of the object.
Permission Conflicts
A user may end up being assigned more than one role, either explicitly or implicitly. When that happens, the granted and revoked permissions of each role are “totaled up” to determine the user’s “effective permissions.”
The basic rules to remember when the permissions conflict with each other:
Revoked beats granted and inherited.
Granted beats only inherited.
Manage Roles
Roles
A role is a set of permissions you can grant to a user. You can also grant roles directly to organizations or to other roles to make granting permissions easier to set up and maintain. You associate a role to a user by making an organization or a user a member of that role.
A role can be thought of as a job title, business function, or business area that one or more users share. Typical roles might include “Sales Manager,” “Administrative Assistant,” “Account Executive,” “Legal Analyst,” and “US Orders.” For example, you might create Roles called “Manufacturing Sales” and “High Tech Sales” that have access to sales data, and a Role called “U.S. Sales Manager” that has access to certain business-sensitive data. If you also grant the “U.S. Sales Manager” Role both the “Manufacturing Sales” and “High Tech Sales” Roles, then the manager Role will have the access explicitly granted to it and the access granted to the two sales Roles. Thus, granting Roles to Roles can aggregate access to data.
For more information about creating and assigning roles, see Creating Roles.
Role Types
Role types are groups of roles, much like organizations are groups of user accounts. Role types are used to organize roles for easier maintenance. Role types are also hierarchical, with no limits to how many levels of role types you can create, as long as each has a unique name within its parent role type.
Each role can exist in only one role type. Creating a role type hierarchy is optional. You can place all of your roles into the Roles root role type if you want to do so.
Role types cannot be granted permissions the way roles can. Role types are different from organizations in this way. A role type is a container for the roles you create.
For more information about organizing roles, see Creating Role Types.
Creating Roles
A role is a set of privileges you can grant to a user. You can also grant roles directly to organizations or to other roles to make assigning permissions easier to set up and maintain.
Roles can be confused with permissions. But unlike a single permission, a role can contain a number of permissions, plus default subfolders, servers, connections, and so on. roles can be set up corresponding to job functions, data sources, or other manageable units. For instance, you could create a role called “Inventory” that includes Select permissions to all of your Inventory VTables, to the servers and connections associated to those VTables, a default subfolder for the “Inventory” subfolder, and a maximum rows limitation appropriate for typical inventory reports. Then, you could grant this role to any user who needs access to the Inventory data through NWQ.
Create a role to:
Group similar permissions to a number of objects so they can be quickly granted to users or organizations.
Give users access to key components and features within NWQ.
Group multiple roles into a “super role” and grant it to specific users.
On installation, NQS gives you a number of default N$ roles that grant permissions to administrative tasks within NQS and NWQ. For more information, see Manage User Accounts in “Managing Users, Organizations.”
In NQS Administrator, right-click the Roles root item in the left-hand list (or the role type under which you want to create the role) and click New > Role.
The role’s property sheets will display.
On the General tab, enter the new role name and a description.
You may also limit the number of rows members of this role can retrieve to prevent runaway queries (long-running queries that tax the database).
Click the Default Subfolders tab. Add any default subfolders you want to grant to all members of this role; this is what makes the contents of the subfolders display in NWQ (in the VTables folder).
On the Roles tab, you can specify any roles that should be a subset of this role. For instance, if creating an “Administrators” role, you may want to include many of the N$ system roles. For more information about system roles, see Manage Roles.
The Members tab is where you will grant the role to organizations and/or users. Click the Add button to add members. Browse to and select the groups or individuals who should be granted this role, then click OK.
(Optional) Use the Notes tab to add notes about this role, if required. (You will need to click Save before adding a note.)
The Permissions tab is where you will specify the permission this role should have to specific objects. For more information about efficiently granting these permissions, see Manage Permissions. Click Save when you are finished.
To grant a role, you need to make the user or organization a member of the role. You can do this on the Members tab of a role, or on the Roles tab for a user or organization.
Creating Role Types
You may want to organize your roles for easier maintenance. You can create as many role types (collections of roles) as you’d like, although each role can belong to only one role type.
You can move existing roles into your new role type or create new roles within the role type. For more information, see Creating Roles.
Create a role type to
Organize your roles into a logical, hierarchical structure.
Group similar roles to reduce the administrative tasks involved in managing them.
To create a role type
In NQS Administrator, right-click the Roles root item in the left-hand list (or the role type under which you want to create the role) and click New > Role Type.
The role type’sproperty sheet will display.
On the General tab, type a name for the new role type and a description, if required. Click Save.
The new role type will now appear under the Roles node.
Granting Permission to a Role
Grant a permission to
Allow Select permission to a specific VTable, or other object.
Allow a user to access, change, delete, and perform other administrative functions on an object.
Expressly revoke permission to access an object.
To grant permission to a role
From the left-hand menu and the detail view, select the role to which you want to grant permissions. The property sheets for that role will display.
Click the Permissions tab.
At the top of this tab is the Security Tree, displaying all of the NQS objects that you can grant this role permissions to. This tree displays the users, roles, servers, and VTables roots; you can expand these to see the hierarchy of objects below each one. When you select a node in the Security Tree, all of the objects that belong to this node appear in the permissions list below.
The permissions list contains the objects that belong to the node selected in the Security Tree. The permissions that have already been granted this role appear to the right under the Explicit column. A plus sign ( + ) in front of one of the letters signifies the permission has been granted. A minus sign ( - ) in front of a letter signifies the permission has been revoked.
Click the Show Effective button to add a column displaying the effective (implicit) permissions as well.
To change this permission, double-click the entry. A Permissions dialog box will display.
Clear the box next to the permission you are interested in if you want the grantee not to have explicit permission to the object. Click the box again to set the Granted check, which will explicitly grant the permission to the grantee. Click the box again to set the Revoked check. Click OK.
Click Save to save the changes.
You can use the drop-down box on the lower left-hand corner of the Permissions tab to quickly grant a typical set of permissions:
Admin will grant all five permissions (+SDACP).
Creator will grant the Select and Create permissions (+SC).
User will grant the Select permission (+S).
Determining Role Assignments
A user can be a member of a role if:
A role is explicitly granted to the user.
A role is explicitly granted to one of the user's parent organizations (membership is thus inherited).
Another role is granted to one of the roles above.
The many ways in which a user can be a member of a role can lead to a complex web of membership grants. A carefully planned out security model will make things easy to manage but things can get complicated when system administrators leave the company, new ones are hired, multiple projects are going on, and so on. NQS Administrator allows you to quickly and efficiently determine the effective members of a role and the effective role memberships of a user. It helps you troubleshoot and unravel any complexities that might arise in your organization.
Example 1: There is a VTable in the system that maps to sensitive financial data. An auditor wants to know who has access to the data. Using NQS Administrator, the system administrator can determine all the users that can query the VTable.
Example 2: Bob calls the help desk to complain that he cannot access a VTable, but his coworker can. The system administrator looks up the roles that has access to the VTable. The system administrator then views the list of users that have been granted this role, and interestingly finds that the role is granted to Bob. The system administrator then looks at the role memberships for Bob and finds that another role is granted to Bob that revokes his access to the VTable. The system administrator removes the role that revokes the permission, and Bob is now able to access the VTable.
To view the effective members of a role
In NQS Administrator, navigate to and select the required role under the Roles tree. The property sheet for the selected role is displayed in the lower-right pane of the NQS Administrator window.
Click the Members tab in the property sheet. The property sheet displays the organizations, users, and roles explicitly granted to the selected role.
Click Effective in the property sheet. The Effective Security Viewer dialog box is displayed.
The Effective Security Viewer dialog box displays three sections:
The Current Object field displays the currently selected role. You can click to quickly change the role without closing the Effective Security Viewer dialog box.
The Status area displays a log that details the processing done by the system to gather the user list.
The Effective Security area displays the IDs and full names of the users who are the effective members of the currently selected role. To view a user’s property page, either double-click on the user or select it and click Edit.
To view the effective role memberships of a role, organization or user
In NQS Administrator, navigate to and select either of the following:
A role under the Roles tree
An organization or user under the Users tree
The property sheet for the selected role, organization or user is displayed in the lower-right pane of the NQS Administrator window.
Click the Roles tab in the property sheet. The property sheet displays the roles granted to the selected role, organization or user.
Click Effective in the property sheet. The Effective Security Viewer dialog box is displayed.
The Effective Security Viewer dialog box displays three sections:
The Current Object field displays the currently selected role, organization or user. You can click to quickly change the user without closing the Effective Security Viewer dialog box.
The Status area displays a log that details the processing done by the system to gather the role list.
The Effective Security area displays the effective role grants of the role, organization or user. To view a role’s property page, either double-click on the role or select it and click Edit.
Granting Permission to an NWQ Folder
Folder permissions allow you to determine who can access NWQ Public folder or a subfolder within it. To grant folder permissions, you will grant folder permission to a role. Then any user that is assigned that role will be able to access that folder and the contents within it.
Folder permissions do not grant users the permissions to run queries—folder permissions only grant permission to view, publish, or delete queries. For more information about permissions to run a query, see Granting Permissions to a VTable in “VTables and Mappings.”
To grant a folder to a role
In NWQ, confirm you are in Manage mode. (If you are not, click the switch to manage link.)
Navigate into the folder itself; you should see the name of the folder at the top of the page and all its contents below.
Click the Permission link.
On the Folder Permissions page, select a role type (group of roles) from the drop-down list at the top of the page. The roles available under this role type will display below.
Click the required roles to select them. To select more than one role, hold down the Ctrl key as you click each role.
Click the Grant button. This will add the roles to the Granted Role list.
Click a single role from the Granted Roles list. The permissions assigned to this role display in the Permission area.
For each granted role, grant, inherit, or revoke each permission level as required.
Click Apply.
You can change or remove the permissions assigned to a role using the Folder Permissions page as well. Select the required role from the Granted Roles list, and then make the required changes to the permissions or click Remove.
Manage Profiles
An NWQ profile is a set of permissions that determine the NWQ features a user can access. Profiles allow administrators greater flexibility in controlling which NWQ features are available to users. When certain NWQ features are not needed or recommended within your enterprise, you can revoke permission to those features.
NWQ profiles do not control users’ access to corporate data itself; profiles determine what users can do with the data once they log on to NWQ. Profiles are used in NWQ only and are not applied to third-party reporting tools that may be used to retrieve data from NQS.
THIS IS CONFUSINGProfiles are optional; you can allow all users to access the default NWQ features without any additional setup steps. If you choose to create custom profiles, you can either modify and grant a single profile to all users in your enterprise or create multiple custom profiles with different sets of permissions.
The NWQ Administrator allows you to create, copy, and delete profiles, and determine which features should be granted and revoked for each profile. For each profile in NWQ Administrator, there is a corresponding role or “profile role” in NQS Administrator. You grant the NWQ profiles to users, organizations, and/or roles by granting the corresponding profile role using NQS Administrator.
To create and grant profiles, you must be granted the N$WebQueryProfileAdmin role. For more information about roles, see Manage Roles.
Types of Profiles
There are three types of profiles:
Default profile: The default profile, which is applied to any user not granted any other profile. In NWQ Administrator on the Profiles tab, click Edit to view or edit the default profile. You may also copy this profile by clicking the Copy button. The copy you create will be listed under Custom Profiles.
Standard profiles: The standard profiles are profiles that are installed during NWQ setup. These profilescan be used as-is, or can be customized further to meet your needs.
Custom profiles: All NWQ profiles that have been created for your enterprise are listed under Custom Profiles. Any profile created during installation as examples or starting points will be listed as well. To view or modify a custom profile, click the name of the profile. To create a custom profile, click the New button from the starting Profile List page.
Steps for Setting Up Profiles
When initially setting up the Noetix Platform for your enterprise, you will perform the following tasks to review and customize, if required, the NWQ features that end users in your enterprise will be able to access:
Review and edit (if required) the default profile using the NWQ Administrator.
Create custom profiles using the NWQ Administrator.
Grant the profiles to users, organizations, or roles using NQS Administrator.
Reviewing the Default Profile
Users who do not have an NWQ profile explicitly granted to them will automatically be granted the default profile. The default profile grants permission to the most common set of NWQ features. However, you can review these settings and modify them to meet the needs of your enterprise.
If you want to grant a single profile to all users in your enterprise, modify the default profile as required; this profile will be applied to all users (as long as no other profiles are granted).
If you modify the default profile and want to return to the original settings at any time, click Restore Defaults.
Any changes you make to the default profile will take effect the next time each user logs on to NWQ.
Important: After you grant any profile role to a user, the default profile will no longer be granted.
Creating Custom Profiles
With custom profiles you can create multiple profiles depending on the specific needs of your enterprise.
The easiest way to create and maintain custom profiles is to use the following steps:
Create a Grant All profile that grants access to all NWQ features. (A standard profile has been created that will work for this purpose.)
Using NQS Administrator, grant the corresponding profile role to the Users root organization. All users under this organization will inherit the permissions in this profile role.
Create additional custom profiles to revoke permission to specific NWQ features as required. These profiles should have all features marked as “Inherited” except those that you explicitly want to Revoke. (A number of standard profiles have been created for this purpose; you may use these or create your own.)
Grant these profile roles to users or organizations that should not have access to these features.
If your profiles also correspond directly to structures set up in NQS, such as roles or organizations, granting profiles will be easier to manage.
To create a profile
On the Profile List tab, click the New button. This will display the Profile Properties page.
On the Profile Properties page, provide a unique name for this profile and a description if required. A profile is usually named for the set of features being granted (e.g., “Revoke Exporting to Excel”) or the group or job duties the profile is created for (e.g., “Sales Managers”). Adding a description of the profile will make it easier to manage your custom profiles as more and more are created.
Select whether each feature should be granted, inherited, or revoked. For more information about these settings, see Granting or Revoking Features.
To quickly mark all features as grant, revoke, or inherit, use the Select All buttons at the top of each column.
Click the Save button.
After creating a profile in the NWQ Administrator, a new profile role (with the same name and description) will be created in NQS Administrator under Roles > NWQ Profiles.
When upgrading from one version of NWQ to another, new features may be added. These new features will by default be marked as “Inherited” in any of your custom profiles. You may need to review and modify your custom profiles after upgrading to ensure users have access to any new features.
Granting or Revoking Features
The Profile Properties page allows you to determine which NWQ features are granted or revoked in a profile. Each NWQ feature that can have permissions granted or revoked are listed on this page along with a description of the feature and any dependencies. You can grant, inherit, or revoke each feature.
When you grant permission to a feature, you are explicitly giving permission to view and use that feature.
When you revoke permission to a feature, you are explicitly disallowing access to a feature. At the top of the page, you can specify whether these revoked features should be hidden (invisible) or disabled (grayed-out).
When you inherit permission to a feature, you are not explicitly granting or revoking permission. Whether a user can use that feature will be determined by other profiles he or she has been granted. For example, if a user is granted permission to the “Query: Customize” feature in one profile and the feature is marked as “inherit” in another, the user will be able to use that feature.
Some NWQ features are dependent on other features being granted. For example, to be granted the “Query: Customize” feature, the “General: Personal Folder” feature must not be revoked (since without a Personal folder, a user would have nowhere to save a custom query). These dependencies are shown when checking or un-checking certain options. Error messages will tell you when you have chosen combinations of features that will not work.
When editing the default profile, only the “Grant” and “Revoke” options are available, since the default profile is only applied when a user is not granted any other profiles (and thus has no other profiles from which to inherit a feature's settings).
Granting a user a profile with features like “Query: Execute” or “Query: Customize” does not give them permissions to the underlying data itself. Permission to the data must be granted/revoked separately, using NQS Administrator.
Likewise, granting a user a profile with features like “Public Folder” does not automatically give them permissions to subfolders within the Public folder. Permissions to Public folders must be set in NWQ using the Folder Permissions page.
Any changes you make to the default profile will take effect the next time each user logs on to NWQ.
Copying Profiles
To create a new profile based on an existing one, on the Profile List tab, check the box in front of the existing profile and click the Copy button.
When copying a profile, you may choose whether to copy over all assignments (members of the original profile role) as well.
Copying assignments means that all users granted the original profile will also be granted to the new profile you are creating. This is an easy way to create a new profile without having to manually grant it to the same users.
For example, say you have a profile named “Customer Support” that you not only granted to the Support organization but to all individuals who work directly with customers as well. You would like to revoke a feature from those individuals not in the Support organization. You could do this in the following way:
In NWQ Administrator, copy the existing profile with assignments.
Name the new copy “Work with Customers.”
Revoke those few features.
In NQS Administrator, remove the Support organization from the profile role's assignments.WHAT DOES THIS MEAN?? REMOVE THE ‘Support Organization’ FROM THE Members TAB FOR THIS NEW PROFILE ROLE??
Not copying assignments means that your new profile will have no users assigned to it (until you set them up in NQS Administrator). This is an easy way to copy only the feature settings of an existing profile.
For example, say you have a “Sales” profile and need to create a new profile for Sales Managers, who should have all the features granted to Sales plus a few more. You could do this in the following way:
In NWQ Administrator, copy the existing profile without assignments.
Name the new profile copy “Sales Managers.”
Grant any additional features you want the managers to have.
Using NQS Administrator, grant the new profile role to the sales managers.
Granting Profiles
After creating your custom profiles, you can grant the corresponding profile role to users using NQS Administrator.
NWQ profiles can be granted to:
An individual user
An organization (grouping of users)
A role, which is then granted to the appropriate users or organizations
This flexibility allows you to grant profiles in various configurations to complement your security and setup in NQS. An understanding of how NQS was set up within your enterprise may help you grant and maintain these profiles more efficiently.
To avoid profile conflicts, you may want to grant your profiles to organizations. If you grant profiles to roles instead, conflicts will be more likely, since each user can be granted many different roles.
Granting a user a profile role with features like “Query: Execute” or “Query: Customize” does not give them permissions to the underlying data itself. Permission to the data must be granted/revoked separately, using NQS Administrator.
Granting a user a profile role with features like “Public Folder” does not automatically give them permissions to subfolders within the Public folder. Permissions to Public folders must be set in NWQ using the Folder Permissions page.
If while creating and granting profiles and profile roles, you have both NWQ Administrator and NQS Administrator open at the same time, you will need to “refresh” NQS Administrator to see recent changes made in NWQ Administrator. For example, if you create a new profile in NWQ Administrator, you will not see the corresponding profile role in NQS Administrator until you refresh the application.
To refresh NQS Administrator, on the View menu, click Refresh or press F5 on your keyboard.
To grant a profile
Navigate to Roles > NWQ Profiles, in NQS Administrator.
Select the profile role corresponding to the required NWQ profile. This profile role will have the same name and description as in NWQ Administrator.
Click the Members tab, and then click the Add button.
The Locate User, Role or Organization dialog appears. Select the user or organization that you want to grant this profile role, and then click OK.
The user or organization will now be listed on the Members tab. Click Save.
Resolving Profile Conflicts
An NWQ user may end up being granted more than one profile role, either explicitly or implicitly. When that happens, the granted and revoked features of each profile are “totaled up” to determine the user's effective permissions.
The default profile is not part of this “totaling” unless a user has been granted no custom profiles. When a user has been granted one or more custom profiles, only those custom profiles are used to determine the user’s allowed feature set.
To total up these permissions, NWQ first checks which features have been revoked. If a feature is revoked in any profile, the user will not have access to it, even if another profile grants that feature. Thus “revoke” always “wins” against the other settings.
A feature will be granted if at least one of the profiles grants that feature and none of the profiles revoke it. Remember that “inherit” always defers to the features explicitly granted or revoked in other profiles.
In other words, when the feature permissions conflict with each other:
Revoked beats Granted and Inherited.
Granted beats only Inherited.
Inherited always loses.
When revoking a feature in a profile, you can choose for the feature to be hidden (invisible) or disabled (grayed-out). These settings can also conflict when a user is granted multiple profiles. The Global Settings page lets you choose which option “wins” when more than one profile revokes a feature but in a different manner.
In NWQ Administrator, click the Global Settings link on the upper right-hand corner of the page.
Select either the Hidden or Disabled option.
Using Standard Profiles
In addition to the default profile, a number of standard profiles are created when NWQ is installed. These profiles can be granted to users as they are or used as starting points to create your own custom profiles.
MAKE INTO A PROCEDURE, THE SAME AS THE NWQ ADMIN HELPTo use these standard profiles, first, grant users the “Grant All” profile, then, if you need to revoke certain features, assign the profiles that revoke these features, such as “Revoke Customizations.” These profiles are meant to be used in conjunction with the “Grant All” profile, not on their own.
To use a standard profile as a starting point, copy the profile, make any required changes, and save it with a new name.
Important: Once you grant a standard profile or custom profile to a user, the user is no longer a member of the default profile role. What this means is the user cannot inherit any permissions from the default profile; only permissions from explicitly granted profile roles will be applicable.REWRITE SO THIS IS CLEARER; HAVE JohnH REVIEW
Deleting Profiles
When deleting a profile, the corresponding profile role in NQS is deleted as well. Consequently, any member of this role will no longer be granted permissions to these features. After a profile is deleted, if a user has no other profile roles granted, the user will be granted the default profile.
If a user is logged on to NWQ when a granted profile is deleted, the change will take effect the next time the user logs on to NWQ.
Always delete a profile using the NWQ Administrator; do not delete the corresponding role from NQS Administrator. Deleting the role directly will “orphan” the NWQ profile and cause issues.
Manage Security Configuration Settings
This section provides information about how to configure security settings for the Noetix Platform web applications, NWQ, NWQ Administrator, and Noetix Generator Manager. As an administrative user, you can use the web.config file of these applications to configure the security settings. The web.config files are available at the following locations:
NWQ: <installation_location>\Noetix\NWQ\nwq\
NWQ Administrator: <installation_location>\Noetix\NWQ\AdminTool\
Noetix Gateway (gateway): <installation_location>\Noetix\NWQ\NoetixGateway\Interop\
Noetix Generator for Noetix Platform: <installation_location>\Noetix\Noetix Generator for Noetix Platform\Manager\
Magnitude recommends that you back up the web.config file before making the changes.
Configure Error Pages
By default, the Noetix Platform web applications provide detailed error messages with information, such as physical paths, versions, and stack traces, that may compromise the security of the applications. You can configure the web applications to display a generic error message instead of detailed error messages.
To enable security settings on error pages
Open the web.config file of gateway, and perform the following tasks under <system.web>:
Delete the following code, if present: <customErrors mode="off"/>
Add the following code:
<customErrors mode="RemoteOnly"
defaultRedirect="GenericErrorPage.htm" />
Repeat step 1 if you want to update the web.config files for NWQ, NWQ Administrator, and Noetix Generator for Noetix Platform.
Save the web.config files, and then restart Internet Information Services (IIS).
Secure Cookies with SSL
You can configure cookies to use the Secure Sockets Layer (SSL) connection for the Noetix Platform web applications.
Open the web.config file of NWQ, and perform the following task under <system.web>:
Modify the value of requireSSL to "true" as follows:
<httpCookies httpOnlyCookies="true" requireSSL="true" />
Repeat step 1 if you want to update the web.config files for NWQ Administrator, gateway, and Noetix Generator for Noetix Platform. Additionally, for Noetix Generator for Noetix Platform, add requireSSL="true" under authentication section. An example code is as follows:
<authentication mode="Forms">
<forms loginUrl="member_login.aspx"
cookieless="UseCookies"
requireSSL="true"
path="/MyApplication" />
</authentication>
Save the web.config files, and then restart IIS.
Secure HTTP Response Header Details
By default, the Noetix Platform web applications reveal the server information in the HTTP response header that may cause the applications to become vulnerable to security attacks. You can configure the web applications to remove this information from the response header.
To secure the HTTP response header
Install the IIS URLRewrite extension.
Open the web.config file of gateway, and perform the following:
Uncomment the following code snippet under <system.webserver>:
<!--
<rewrite>
<outboundRules>
<rule name="rewrite response server" stopProcessing="true">
<match serverVariable="RESPONSE_SERVER" pattern=".*" />
<action type="Rewrite" value="Unknown" />
</rule>
</outboundRules>
</rewrite>
-->
Repeat step 2if you want to update the web.config files pertaining to NWQ, NWQ Administrator, and Noetix Generator for Noetix Platform.
Save the web.config files, and then restart IIS.
Tip: After updating the web.config file, you can verify that the HTTP response header “Server” is set to “Unknown” by using the developer tools of the web browser.
Enable Generation of WSDL Files
By default, Noetix Platform protects the web applications from crafted requests by preventing the generation of Web Services Description Language (WSDL) files. However, you may require these WSDL files to get information about the Noetix Platform web applications.
To enable the generation of WSDL files of gateway, in the gateway web.config file, delete the code <remove name="Documentation"/> under <webServices>. Then, restart IIS.
Configure Session Timeout
You can use the default session timeout feature of Noetix Platform to reduce vulnerabilities, such as session hijacking or fixation attacks, associated with the lengthy sessions of the web applications.
The feature enables you to specify the session timeout and warning period values for the web applications:
Session timeout: Indicates the number of minutes a session can be idle.
Warning period: Indicates the number of seconds the warning is displayed to the user stating that the session will expire.
The default session timeout and warning period values and the pages that appear when you log on to the application after the session expiry are as follows:
Component |
Session timeout (in minutes) |
Warning period (in seconds) |
Displayed page |
NWQ |
60 |
60 |
The Public folder appears if your NWQ instance contains the generated metadata; otherwise, the Personal folder is displayed. |
NWQ Administrator |
20 |
60 |
The Queries page is displayed. |
Noetix Generator for Noetix Platform |
15 |
60 |
The status of the generation in progress is displayed. |
Gateway |
60 |
- |
- |
To configure the session timeout and warning period values
Open the web.config file of NWQ, and perform the following:
To change the timeout value, modify the timeout value in the sessionState section under system.web of the code:
<sessionState timeout="60"></sessionState>
To change the warning period, modify the WarningPeriodInSeconds value under appSettings section of the code.
<add key="WarningPeriodInSeconds" value="60" />
Repeat step 1 if you want to update the web.config files pertaining to NWQ Administrator, gateway, and Noetix Generator for Noetix Platform.
Save the web.config files, and then restart IIS.
You can configure only the session timeout value for gateway.
When your session is about to timeout, a warning message is displayed for the specified number of seconds indicating that your session will expire. You can choose to continue with the session; otherwise, after your session expires, you can either provide the password to continue with the session or refresh the page to return to the logon page.