I’ve read numerous threads here in the forum and of course the IS admin guide, but my problem isn’t treated anywhere, it seems.
One of our clients urges us to instruct them how to create a user account that has read-only-access to the Integration Server’s administration page. I. e., they want to assign certain users to be able to look into the administration console to check logs, configurations, package status etc. without the ability to change something by accident.
So I followed the steps in Chapter 12 “Controlling Access to Resources” of the Administrator’s Guide:
Created a new ACL named “ReadOnlyAdmins”
Created a new group named “ReadOnlyAdmins”
Created a new user named “ReadOnlyAdmin”
Then tried to add the new group to the ACL’s allow-list
The group is listed in the popup and I can select to add it
When it is added to the allow list, the name is “20ReadOnlyAdmins”. This also happens when I select one of the built-in groups that came with webMethods.
Now, when I click on “Save Changes” the page says “Access Control Lists Updated” and jumps back to the first ACL “Administrators”.
The group association, however, has not been saved.
I assume that it must have something to do with the weird name “20ReadOnlyAdmins” as this is not the real name of the group. I would have expected “local/ReadOnlyAdmins” instead.
Question 1: Am I on the right track? Even if adding the group to the ACL had succeeded, how would that restrict write access to everything?
Question 2: How can I get the admin page to store the group association and not display a wrong group name?
The AdminPageManager package did bring me a step further but still not past the finish line as it allows me to set rights only to “Hide” or “Full”. The middle column “View”, which is what I need, is not selectable. Also, the .cfg-Files it creates for my designated Read-Only-ACLs only list the sections of the administration console that I selected as “Full”, but nothing beyond that would allow restriction to read-only access. Besides, it had no effect. I set a few sections and menu items to “Hide” for a new ACL, logged on with that user but still could see everything that “Administrator” could see.
Now, I’ve read in this thread that there is another “secret” package, which would help me achieve my goal. Thanks to a member of this forum I could download it and installed it in my test environment.
It seems to work exactly the way I need, except for a few questions left unanswered
How can I configure which menu links are displayed in the main menu? E.g., currently it does not list MQ adapters, which we have, but instead lists PeopleSoft adapters (which we don’t have).
Given that I can deliver this package to our client, how can I set it up that the package’s home page is associated to a certain group or ACL so that the designated read-only-administrators get straight to this page upon login?
I find it somewhat strange that this -in my opinion- absolutely common requirement is so difficult to realise. How come that webMethods does not supply an easier solution to manage read/write/execute permissions?
