BOE XI 3.x Security Made Easy

Over the years, the security model in BusinessObjects Enterprise has evolved from user oriented security to object oriented security.  Those of you lived through the transition from 6.5 to XI, if you’re still sane, have seen some dramatic changes to the security model. The challenge of migrating from 6.5 to XI was that we had to permanently delete all knowledge of 6.5 security in order to fully understand the security model in XI.

And if that wasn’t enough, we also had to face some drastic changes between XIR2 and XI 3.x. Now, in XI 3.x, we have a true object oriented security model. What does that mean? It simply means that everything in XI 3.x is an object to which security can be applied. And when I say everything, I mean everything, from servers, to users, to universes, to documents, etc. Everything stored in the system is an object. Of course, this is a secret that we admins must keep. We can’t let the users in on the truth that each of them is nothing more than an object in the system. 🙂

So, the purpose of this post is to look at the security model in 3.x and look at some tips to make the whole thing as simple as possible.

Starting at the Root

In XIR2 we had something called Global Settings. In Global Settings we could set the Everyone group to No Access. This meant that no one would have access to anything unless we added them to a group that had access to a given object. This is quite different in XI 3.x. We no longer have Global Settings. We have a root folder called Public Folders. However, if we set the Everyone group to No Access at the root, then no one can see any other folder in the Document List, even if View rights are granted, as they can’t see the root folder. This is true no matter what group they belong to.

However, if we grant the Everyone group View rights to the root folder, then we have to go into each sub folder, under the root, and grant the Everyone group No Access. This is very time consuming, and terribly confusing. Is there a better way to accomplish this? I’m glad you asked. The answer, of course, is Yes!

So here’s the trick. Log into the Central Management Console (CMC), and go to Folders. Click on All Folders, on the left. Then click on the Manage button, and choose Top-Level Security – All Folders. Click OK at the pop-up box. Select the Everyone Group, and go to Assign Security. If there are any Access Levels listed under Assigned Access Levels, click the Remove Access button. At this point, it’s best to start with No Access.

Next, click the Advanced tab. Then, click Add/Remove Rights. This will take you to the General section of the Advanced rights window. Scroll down the list on the right, and find the setting for View Objects. Choose the following settings:

• Granted
• Apply to Object (Checked)
• Apply to Sub Objects (Unchecked)

Allow me to explain.  By granting the right to View Objects, we are allowing the Everyone group to see the root folder. In InfoView, this folder is called Public Folders. However, by unchecking “View Sub Objects”, we are granting the View right to the root folder, but not allowing that right to be inherited to the rest of the Public Folders. At this point, you can grant the appropriate rights to each folder for each group. No one will have access to any folder unless they are a member of a group that has rights to that folder.

Beware of Everyone

Is that the equivalent to “Trust No One”? In any case, we want to be aware of, and beware of, any settings we apply to the Everyone group. Why? Because everyone, including you, is a member of the Everyone group. Therefore, anything you set for the Everyone group applies to you, as an administrator. This is true provided you are logging in with your own UserName, as a member of the Administrators group. This does not apply to the Administrator account, as you cannot remove rights from the Administrator.

So, with this in mind, never, ever, use the ‘Explicitly Denied” setting on the Everyone group. Rather, set the Everyone group to No Access for all objects, except as noted above. No Access uses the “Not Specified” setting, rather than the “Explicitly Denied” setting. Not Specified is far more flexible. It means that a user will not receive a given right as a member of that group, but may receive the right as a member of another group. It’s a very powerful setting.

The only time you should ever grant rights, other than No Access, to the Everyone group, is when you want to grant access to an object for everyone in the organization. For example, you may have a folder in InfoView that holds HR forms. This is obviously a folder that all employees need to access. In this case, it would be appropriate to grant View rights for the Everyone group to that folder.

Dual-ing with Security

You’ve probably heard this before, but it’s well worth repeating, as it is one of the best methods for simplifying your security model. Set up a dual security model. Here’s how it works. You create two types of groups: Content and Application.

Content Groups: These groups tend to mirror your folder structure. For example, if you have a Sales folder, you will have a Sales group. The Sales group will have rights to the Sales folder. The content groups are used to grant rights to the folders and, therefore, the content of the folders.

Application Groups: These groups are used to grant rights to various applications. For example, you might have a group called Web Intelligence Developers. Members of this group will have the rights to create documents in Web Intelligence.

With this model, every user is a member of at least one content group, and one application group. Of course, they may be members of multiple content and application groups, based on their needs.

Back Away From The Users

I can’t say this enough: do not set security for individual users. Ever. If you do, you are setting yourself up for a huge security nightmare. Rather, set security for groups, and add members to the appropriate groups. Even if you have one user who has special security needs, create a group for that user, and set the security for the group. That way, if the user ever leaves that position, you can simply remove them from that group, and replace them with the user who has taken their place.

And the Documents, too!

The same rule that goes for users, goes for documents, too. Don’t ever set security on individual documents. Create folders, add the documents to the appropriate folders, and set the security on the folders. Don’t make this more complicated than it needs to be. You have enough work to do without making security more complicated.

Use the Best Tools

Unless you have a fairly simple deployment, setting up and maintaining security in the CMC can be time consuming and frustrating. There are tools available that make it much easier. My favorite is 360View from GB and Smith. This tool can reduce your setup time by as much as 90%. I’ve used it, and have been very impressed with it. Of course, there are many similar tools available. So find one that meets your needs and use it.

Do you have additional security tips and tricks that you have used to make life easier? Share them in the comments below.