Access to Profile Objects for Users/Groups [Analysis with Insight]
This breaks “out of the box” of what I typically choose to write about (analysis-related items related to Adobe Insight), but a good question came up on Twitter today from one of our clients (you follow the #AdobeInsight hash tag, right?) Although the question leans more technical/architectural, it’s an area where power analysts / power users frequently dabble in Adobe Insight, and it required more than a few 140-character tweets to explain, so I decided to give it a full and proper answer here on the blog.
The question at hand:
How do I limit the access of some users to certain profile objects (in this case, a folder of workspaces) in Adobe Insight?
I have a few clients who have tackled this same question in varying ways, so I’ll cover a few options here, based upon those experiences. Let’s talk about 3 approaches:
- Restricting Access via Access Control
- Restricting Visibility via a Profile
- Restricting Visibility via order.txt
Let’s explore each of these options:
Restricting Access via Access Control
One fantastic built-in feature of Insight is the tremendously granular approach it enables to how an administrator can allow/restrict access to various resources on the server or cluster. This is done via the Access Control.cfg configuration file.
Access Control lets an admin declare users or groups of users (by license certificate value or other variables) and declare which resources they can Read and/or Write on the server or cluster.
In one case, I’ve had a client Restrict the “Users” group (their group of all analyst users) to a specific sub-directory within the profile’s “Workspaces” directory. Note how the highlighted vector below limits the Users group to Read “/Profiles/MyProfile/Workspaces/Users/”.
Note that to use this method, you’re more granularly defining what aspects of the “Profiles” directory the Users group can access, so you’ll want to take care to explicitly declare all of the aspects you want them to be able to access (including Context, Menu, Visualization, and other similar elements.)
Next, this client allowed their “Power Users” or “Administrators” group (other, specifically declared Certificate Common Names like mine) access to anything within the “Profiles” directory (and, inherently, anything in any “Workspaces” directory beneath it):
Note that the above list isn’t comprehensive of resources to which an Admin might have Read/Write access. I’ve cut it down for display purposes here.
Using this method, an admin can strictly define who can access which resources. It takes a bit more planning and effort to get correct (ensuring all needed elements are included for the “Users” group, for example), but it has the advantage that it allows strict and precise control.
Restricting Visibility via a Profile
Another method would entail utilizing a new analysis profile, with its own order.txt file, to define what workspaces are present to the end user.
For example, if my dataset and profile were configured as “SimpleWeb”:
I could create an entirely new profile (“SimpleWeb Admin”) that inherited “Base” and “SimpleWeb”, but also included the /Admin sub-directory of workspaces. In fact, that could be the only thing different about the “SimpleWeb Admin” profile — it would have a “/Profiles/SimpleWeb/Workspaces/Admin/” directory, with workspaces in it. The “SimpleWeb” profile — the Users’ profile — would not.
Restricting Visibility via order.txt
You could also just use the order.txt file, which defines the order in which users see profile elements within a directory, in your existing profile (“SimpleWeb” above) to “hide” elements. Just add a “-” before the line of the element you want to hide. The order.txt in my server-inherited profile, in the “Workspaces” directory, might hide the “Admin” folder of workspaces with a “-” as in this example:
Note that you can also set the “[EXCLUSIVE]” switch at the top of the order.txt file. That will make it so that elements that aren’t declared in the order.txt file will be excluded from the menu for users. For details on these settings, see the “Customizing Menus Using Order.txt Files” section of the Insight Client User Guide.
But then a few administrators could see it by making their own local version of order.txt and removing the “-” that hides the element.
Again, what’s awesome here is the strength and power that Adobe Insight puts into the hands of an architect, admin, or even power user, to define and configure access control or resource visibility on a very custom basis, as organizational needs dictate or change.
As always, Adobe ClientCare and your Adobe Consulting team stand ready to help you plan and implement Access Control or any other solutions related to Adobe Insight. I’d love feedback below, or tweet it to me at @Halbrook. In fact, I’ll even take Adobe Insight questions to answer in the future via Twitter.