Hi,
Access rights to BO XI R2 objects created for reporting purpose. i.e A sample report is to be seen by different users in different countries. A user from country X should not be able to see the report data of Y country.
I think this access control should be done at the object level not at the User Creation level.
How can I make report that only User_California will see the data only for California state and user_Texas wil se the data only for Texas state adn so on.
How can I put row level security in CMS for particular user ?
Row level restrictions still exist in BO XI. They are now defined in the Designer at Universe level.
Tell us if you need more explanation about row level restrictions.
sorry, but I did’nt get your point.
Still I am not able to put row level restriction in Business objects XI R2.
It will be better if u tell me in detail.
You can’t administer row-level security in the CMS, it must be done in Designer, as Jerry mentioned. Although most people recommend that you handle row-level security in the database, as opposed to managing it through Business Objects.
As per your suggestion, I also don’t want to restrict security in designer, but I want to restrict it at Database level.
Can you please tell me how I can handle row-level security in the database?
This presentation was written from a v5 / v6 perspective, but the concepts still apply. It walks through the different row-level security options, so I think you will find it useful for both overview and specific solution purposes. Again, the Supervisor solutions discussed in the presentation have been moved into Designer in XI, but the concepts still apply.
I strongly recommend NOT to use Universe Designer to implement row level security. But instead, set up data security on the datamart or BOW.
First of all, this will save you a lot of headache on managing the user (and I am talking about the developers and not the business users) security on Designer.
Secondly, this will eliminate your dependency on the Designer tool. It is because nobody can be 100% sure the next time when they combine the Universe and the Business View, all features will be backward compatiable. Can anyone bet his/her farm on this? I can’t and I won’t. I don’t want to take any chance that I might have to re-do all the row-level security on the next release. It will be a nightmare, isn’t it? Of course, BOBJ will tell us everything will be compatiable…just like they told us XI can run on Itanium servers and we can import ALL contents in EPM using Import Wizard. Yeah right.
Last but not least, as I have said it many times before, data security belongs to the data layer (i.e. the database) and not the metadata layer. Besides, setting up data security on the datamart gives me more flexibility and control, and that is ALWAYS a good thing. As much as possible, you should always look for the solution that is TOOL-INDEPENDENT first.
I have to agree with “substring”, the only problem is that you will need separate database logins for each UserId in Business Objects, and if the users ever change their Business Objects passwords you will have to deal with how to synchronize their database passwords…
I want to be sure we are saying the same thing here.[list]1. In the XI world, Designer has replaced Supervisor as the method to define row-level security restrictions in the repository. These “overrides” are added to the SQL at execution. I agree with substring that this method is difficult to maintain and runs the risk of being deprecated (removed) in some future release.
Another option is to use the capabilities of the RDBMS itself. I think Oracle calls it “fine grained access” (something like that), but other databases have similar functionality. As has been pointed out, it does remove the dependence on Designer, and makes the solution more tool independent, but then password synchronization becomes an issue.
A “hybrid” solution is to include a security table in the database, and based on user id enforce security by means of joins to that database table. This solution is “sort of” dependent on Designer, but enforcing joins can be done by any tool (business views, etc.). It also avoids the password synchronization issue. The trick here is to make sure the security joins are ALWAYS enforced.[/list]Each solution has its pros and cons.
We also implement security at the database level, and had a big concern about how to handle database password changes if tell the universe connections to use the user’s database credential from the CMC. We finally got some SDK code from tech support, which we’ll be plugging into our cusotm database password change app. This will require that user passwords be consistent among all databases, but at least it’s better than it seemed originally!
Amy, on our universe connections, we do not want to use any actual user account. Basically, each universe accesses the data mart with a read-only account. What a user can see is determined by joining a security table and an org alignment table.
Yes, password maintenance is cumbersome. We are looking into some 3rd party software that might be able to manage the password change. But your set up sounds very interesting. Is it possible for you to send me the SDK code? I would like to take a look.
Sure - I’m attaching the code here in case others would like to see it too - hope it helps! It’s for JSP, but the way.
(Note that I’m not a programmer, so although I basically understand it, and it works for us, I can’t promise it will for anyone else!) DBPASS code.txt (2.0 KB)
All, need a bit of help here. From reading the posts above how would this scenario work?
Large worldwide organisation with 2000 odd cost centre users accessing the same set of reports. Currently each user has row level security set through supervisor.
If we were to go the RDMS way i.e. handle row level security there, can anybody give me the name of a friendly DBA who would be willing to create and manage the users? No SSO or anything of that ilk here.
To move the security to the table the easiest is to:
Have a table with 2 columns
– BO login (must be the same as the BO login
– Cost Center (same as in your table
in the universe add the table created above
–add a join from the Cost center to the cost center in the security table
–add a self join from security user to @variable(BOUSER)
–open the objects where you want the security to be applied and on edit panel hit de tables button and add the security table.
Export and all the users will only see their data.
Generating the table could be an issue find the source where it can be extracted from: some database tables or in the worst case an XLS spreadsheet
(BOB member since 2006-02-13)
(BOB member since 2002-11-22)
(BOB member since 2002-06-20)