Access to Profile Objects for Users/Groups [Analysis with Insight]

This breaks “out of the box” of what I typ­i­cally choose to write about (analysis-related items related to Adobe Insight), but a good ques­tion came up on Twit­ter today from one of our clients (you fol­low the #AdobeIn­sight hash tag, right?) Although the ques­tion leans more technical/architectural, it’s an area where power ana­lysts / power users fre­quently dab­ble 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 ques­tion at hand:

How do I limit the access of some users to cer­tain pro­file objects (in this case, a folder of work­spaces) in Adobe Insight?

I have a few clients who have tack­led this same ques­tion in vary­ing ways, so I’ll cover a few options here, based upon those expe­ri­ences. Let’s talk about 3 approaches:

1. Restrict­ing Access via Access Control
2. Restrict­ing Vis­i­bil­ity via a Profile
3. Restrict­ing Vis­i­bil­ity via order.txt

Let’s explore each of these options:

Restrict­ing Access via Access Control

One fan­tas­tic built-in fea­ture of Insight is the tremen­dously gran­u­lar approach it enables to how an admin­is­tra­tor can allow/restrict access to var­i­ous resources on the server or clus­ter. This is done via the Access Control.cfg con­fig­u­ra­tion file.

Access Con­trol lets an admin declare users or groups of users (by license cer­tifi­cate value or other vari­ables) 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 ana­lyst users) to a spe­cific sub-directory within the profile’s “Work­spaces” direc­tory. Note how the high­lighted vec­tor below lim­its the Users group to Read “/Profiles/MyProfile/Workspaces/Users/”.

Note that to use this method, you’re more gran­u­larly defin­ing what aspects of the “Pro­files” direc­tory the Users group can access, so you’ll want to take care to explic­itly declare all of the aspects you want them to be able to access (includ­ing Con­text, Menu, Visu­al­iza­tion, and other sim­i­lar elements.)

Next, this client allowed their “Power Users” or “Admin­is­tra­tors” group (other, specif­i­cally declared Cer­tifi­cate Com­mon Names like mine) access to any­thing within the “Pro­files” direc­tory (and, inher­ently, any­thing in any “Work­spaces” direc­tory beneath it):

Note that the above list isn’t com­pre­hen­sive of resources to which an Admin might have Read/Write access. I’ve cut it down for dis­play pur­poses here.

Using this method, an admin can strictly define who can access which resources. It takes a bit more plan­ning and effort to get cor­rect (ensur­ing all needed ele­ments are included for the “Users” group, for exam­ple), but it has the advan­tage that it allows strict and pre­cise control.

Restrict­ing Vis­i­bil­ity via a Profile

Another method would entail uti­liz­ing a new analy­sis pro­file, with its own order.txt file, to define what work­spaces are present to the end user.

For exam­ple, if my dataset and pro­file were con­fig­ured as “SimpleWeb”:

I could cre­ate an entirely new pro­file (“Sim­pleWeb Admin”) that inher­ited “Base” and “Sim­pleWeb”, but also included the /Admin sub-directory of work­spaces. In fact, that could be the only thing dif­fer­ent about the “Sim­pleWeb Admin” pro­file — it would have a “/Profiles/SimpleWeb/Workspaces/Admin/” direc­tory, with work­spaces in it. The “Sim­pleWeb” pro­file — the Users’ pro­file — would not.

Restrict­ing Vis­i­bil­ity via order.txt

You could also just use the order.txt file, which defines the order in which users see pro­file ele­ments within a direc­tory, in your exist­ing pro­file (“Sim­pleWeb” above) to “hide” ele­ments. Just add a “-” before the line of the ele­ment you want to hide. The order.txt in my server-inherited pro­file, in the “Work­spaces” direc­tory, might hide the “Admin” folder of work­spaces 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 ele­ments that aren’t declared in the order.txt file will be excluded from the menu for users. For details on these set­tings, see the “Cus­tomiz­ing Menus Using Order.txt Files” sec­tion of the Insight Client User Guide.

But then a few admin­is­tra­tors could see it by mak­ing their own local ver­sion of order.txt and remov­ing the “-” that hides the element.

Wrap­ping Up

Again, what’s awe­some here is the strength and power that Adobe Insight puts into the hands of an archi­tect, admin, or even power user, to define and con­fig­ure access con­trol or resource vis­i­bil­ity on a very cus­tom basis, as orga­ni­za­tional needs dic­tate or change.

As always, Adobe Client­Care and your Adobe Con­sult­ing team stand ready to help you plan and imple­ment Access Con­trol or any other solu­tions related to Adobe Insight. I’d love feed­back below, or tweet it to me at @Halbrook. In fact, I’ll even take Adobe Insight ques­tions to answer in the future via Twitter.