Dwayne Hoffpauir’s 2008 GBN User Conference presentation.
A look at the XI security model, focusing on new features in XI 3.0:
Custom access levels
Ability to assign more than one access level
Ability to selectively choose whether a given right “cascades” or not
More granularity by specific document types
The new features enable a robust “building blocks” approach to security that makes security managable by “mere mortals.” The download includes an Excel spreadsheet that lists every possible individual right (nearly 1,300 of them), categorized by the object to which they apply. Very useful in drafting / maintaining your own security matrix.
For those attending my presentation, I left out one “cool” use of the cascading / non-cascading feature that can now be applied to individual rights. In previous releases, when a developer was given broad rights over a folder, the could not only add / change / delete objects within the folder, but they could also DELETE THE FOLDER ITSELF!
With XI 3.0, you can set the delete right to apply ONLY to sub-objects. That way they can delete objects, sub-folders, etc., but NOT the object (folder) itself!
Is this only true when a user is always a “kind” of user? For instance, in a scenario with three kinds of users: Advanced, Medium, General and Two Groups: HR and Sales.
In your scenario there would be 5 groups. Let’s say User: Bob is an Advanced User for the HR Group.
He would be placed in the “Advanced” group and the “HR” group. Later on, Bob also needs view only access to the “Sales” group. Due to security requirements, he is not allowed to be an advanced user of the Sales group.
Adding BOB to the “Sales” group while he is already in the “Advanced” group and the “HR” group would give him too much access.
In this particular type of scenario, would I need to create the 50x3 groups?
edit: without using overrides or individual user level security for Bob.
I just don’t understand something :
In the 3.1 matrix I understood that, we should better “play” with the different customised access level, and then apply those levels for a group in order them to have rights on folder or applications.
so a user belongs to a group
instead of :
creating groups with their rights on folders
creating groups with their rights on application
so a user belongs to 2 groups.
And following the questions upper, the solution proposed by Dwayne is the second one : a user belongs to 2 groups
So what is the best solution if ever ?
thanks for your answer
That is correct for content folders. However, what about Universe folders? Setting “Not Specified” for the edit/delete permissions seem to effectively limit what these “mixed” users could do with the universes contained in the folders. I will try to post a real example tomorrow.
Let’s see. I took your requirement against “give him too much access” rather literally I guess. I should ask, which application rights are the concern? Report authoring rights (DeskI, WebI), Designer rights, other? There is an individual right that can be applied to universes to allow data provider create / edit against that universe. It is the ONLY exception that I know of where what is essentially an application right is applied to content (documents, universes, etc.).
Hi ! must we always create rights for application AND rights for content.
Or is it possible to imagine that the ones who will refresh have all the same rights and can only access their folder and then refresh a webi document and so, we create a right “refresh”, then
we create “accounting group” and apply the “refresh” right on the universe, connection, folder in relation with accounting, and the apply the same right “refresh” on application WebIntelligence
Then if there is the same behaviour on “sales group”, we apply the same “refresh” right for the sales group, on sales folder, etc.
I tried, but never found a reliable way to do so. It took a few hours of copy / paste from CMC. Tedious and possibly error prone, but in the end quicker than fiddling with code. The SDK just isn’t very good at this “master data” kind of thing.
I’m playing around with Xi3 security for the first time, having not done any security modelling since the days of v5 / v6. I’m trying to reproduce the blocks in your presentation, but am confused by what I see as duplicate permissions.
What is the difference between ‘View SQL’ within the Content\Desk Intelligence Report group, and ‘View SQL’ within the Application\Desktop Intelligence group? What happens if one is granted and the other isn’t?
There are other similar duplicates for both Deski and Webi.
Let’s start with the easy part. The application one will drive what you do … well, within the application. Same for content … it would apply to individual DeskI documents.
Now as to the interaction between them, I haven’t tested it, but this would be my “hypothesis.” You’d have to have the application right, or you wouldn’t even be able to choose that option in the DeskI client. That would enable you to create new documents, see the SQL, etc. The content right would then be a matter of granularity. You could prevent viewing of SQL for some documents, and not others. Again, my hypothesis, but should be easily verified.
I understand how the new XIR3 security model works, but am awaiting a password before I can get into my CMC to fiddle with it… I’ve been spending the past week preparing scope documents and such…
On Column “D” of the spreadsheet above, it is labeled “Applicability”, is this something new in XIR3? I don’t quite understand what that column is used for when planning your security model…
At first I thought “General” and “Override General” were indications that this model is overriding the default settings… but then I see “Specific” and it kind of throws that idea away…
What is that column telling me to consider that I’m missing?
I missed this post originally, so my apologies there. You are on the right track. This is something new in XI 3.x. The “General / General” rights are still there … basic add, edit, delete, view, etc. In XI 3.x, you can get more granular, based on the content type … hence the “override general” terminology used by XI 3.x. As an example, it is possible to allow someone to “add” Excel documents to a folder, but not a WebI document, using this “override general” granularity.
My advice is to NOT use the “General / General” rights in custom access levels at all. Unless of course that is exactly what you intend … that the rights apply universally, regardless of content type. Otherwise, it’s just too easy to grant unintended access.
(BOB member since 2005-04-23)
(BOB member since 2002-09-19)
(BOB member since 2005-09-26)
(BOB member since 2006-07-06)
next time!
(BOB member since 2007-06-06)