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.

2 comments
Michael Halbrook
Michael Halbrook

Thanks, Rory. Glad the detailed post could help. Eager for any more feedback from you or anyone else on this topic in the future.

Rory Flanagan
Rory Flanagan

Thank you Michael! This is exactly what I needed. The [Exclusive] switch has enabled the precise functionality we wanted to use for our role based access control. That was our missing key!