While access to the App functionality, like access to the
Authentication menu, can be granted by configuring the menu for the user, access to specific parts of the navigation tree in the Explorer itself is not possible in the menu. A user always sees all routers and the whole tree.
To tailor access to specific routers and the navigation tree, views can be defined and assigned to users.
With a view, administrators can:
Grant access to specific routers of a router network.
Grant access to specific CLI contexts only.
Define predefined filters on the entity names of entity lists.
Grant access to specific commands of a CLI context.
Create a View and assign it to Users
Views are located under the
VIEWS tab in the
To create a new view, chose
NEW ITEM and give it a name:
CREATE which will lead to the view editor:
The view presented is the default view with access to all available routers and the whole tree. To change it to access only the router with the name
router, change the first line from
Now switch to the
ACCOUNTS tab and either create a new user or use an existing one and assign the view:
The user can now log in but only sees router
router with the full navigation tree.
Content of a View
A view is created per router by specifying the router name. If
* is specified, it matches all routers. In that case, no further routers can be added.
Each router contains one or more lines with a CLI context. If
* is specified, it matches all CLI contexts. In that case, no further context can be added. A CLI context must start with
/xt$. The names of the CLI contexts can be gathered from the configuration section of each Swiftlet in the SwiftMQ documentation.
A CLI context filters the Management Tree. The user will only see those parts that start with the value given in the CLI context. So he will see that CLI context and all sub-contexts.
/sys$authenticationshows the Authentication Swiftlet including users, groups, etc.
/sys$authentication/groupsshows the groups and all entries, including queue and topic grants. But it does not show users.
Entity Name Filter
A CLI context can have a predefined filter that MUST point to an entity list such as
/sys$queuemanager/usage. This filter contains strings, separated by spaces. The user will only see those entities whose names contain one of the strings in the filter. If the user creates new entities, the name must match the filter, too.
The filter is applied to the exact CLI context. It is not applied to sub-contexts.
app01 app02will only show those queues that contain the strings
app02. New queues must match the filter, too.
klxwill only show groups with string
klxin their name. New groups must match the filter, too. The filter is applied to
/sys$authentication/groupsonly. It is not applied to sub-contexts such as
A CLI context has a command field that is used to grant CLI commands, available in this context. If
* is specified, it matches all commands of this context. To grant specific commands, enter them separated by spaces such as
view import export. If no commands should be granted, leave the field empty.
Commands are granted to the specified CLI context and all sub-contexts.
Default View (all Access)
* for the router field (all routers), a single view with
* for the CLI context (all contexts), an empty filter field (no filter), and
* for the command field (all commands).
Specific Routers, all CLI Contexts, no Filters, all Commands
It grants access to routers
mqprod on all CLI contexts, with no filters, and all commands.
Specific Routers, specific CLI Contexts, Filters, specific Commands
It grants access to routers
mqdev the user can create and delete queues. It only sees queues where the queue names contain the string
def. For the usage part of the queue manager, the filter is extended with
rt$ to be able to see routing queues. The commands granted in this context are
mqprod the user can view the memory, and perform the
gc command. The usage section of the queue manager contains the same grants as