Hi,
I’ve read the ‘mere mortals’ guid to BOXI security - some of it I agree with some, some I don’t. I’ve been involved in a few security model designs and it seems there really is no one size fits all model.
I’m currently tidying up a security model for a client who are moving from r2 to r3. I’m introducing custom access levels to replace the ‘advanced’ rights that had been applied to objects throught their old r2 model.
I’m just wondering how other people have implemented access levels in their security model - in the past I have defined an acces level for each role - for example a power user access level which contained all apps rights (logon to infoview, deski) as well as content rights.
I’ve been playing around with breaking these access levels down further - for example - a $APP_InfoView access level which just sets the application rights for InfoView and removes them from the role access levels. I like using this method as it neatly compartmentalize’s functionality. Downside is I end up with a lot more access levels. What has experience taught you about the application of custom access levels - any pitfalls to avoid or lessons learnt?
Everything depends on customer needs, how complex is the security model. But the main point as usual is think about the future and how easy is it to maintain …
I am in the process of re-designing our security in preparation for upgrading to 3.1 and have taken the approach of granular access levels. For instance, I have an access level for Webi Content Consumer, Webi Content Developer, Deski Content Consumer, InfoView - Basic/Advanced, etc. While I will have more access levels I like the idea of knowing exactly what each level grants to a user/group. It also gives me flexibility down the road without having to break up the levels when that ‘odd’ requirement comes from the business.
I like this approach - I think it provides more flexibility when you take a ‘building block’ approach. You end up with more access levels with low complexity which are easier to maintain and support.
I’ve also taken this approach. The thing I like about it is, if you are smart about the way you name the access levels, you can tell at a glance from the User Security window exactly what access the users have without having to go in and look at the individual settings.
I too am using this route for Custom Access levels. For me, its far better than the advanced rights option.
The only issue I’ve found is the amount of elements you can potentially grant access to. I know it depends on the user community, but what approach do you all take for things like Hyperlinks, Publications, Voyager, BI Widgets, Content Search etc?
I’m trying to implement access as simple as possible (i.e. Access to Infoview and Web Intelligence and to create reports etc) There’s a multitude of things I don’t know what to do with, certainly in the Application and System options.
You are safe just leaving these as unspecified if you are not using them. By default, that does not grant access. If you decide to start using them later, you can then grant access. If you deny access to those, it can cause problems later if you decide to start using them.
Only deny access to things that you for sure don’t want them to be able to do anything with. For example, we deny our users all of the security related permissions because we don’t want them changing any security permissions. We also deny our users the ability to delete objects in our upper environments. This protects the folders and reports from accidental deletion. Be sure you don’t deny things to the Everyone group or it will apply to all logins except the Administrator login.
I took the approach of creating two access levels to prevent objects from being deleted.
Prevent Object from Being Deleted - Denied the delete object right on the object only
Protect Folder Structure - Deny delete object right on folders, objects and sub-objects.
The first allows me to protect a single object such as a top-level folder and the second allows me to protect a whole folder structure. Where the second comes in handy is for report developers that also have the ability to schedule. Because they can schedule to any format you can’t use the Webi specific rights, you have to grant the general rights. If you grant the general delete object right a user could delete a folder when you really only want them to be able to delete an object or instance.
(BOB member since 2006-07-28)
(BOB member since 2006-07-28)