I am thinking if the following BO reports security is possible or not…
We are thinking of avoiding roles, groups, and folder concept in BO XI R3 for reports access.
A db function will be created which will figure out if a user has access to a reports or not.
I have follwoing questions:
Can we create a prompt which contains function with report access/no access logic ?
I dont want this function to run before rest of the report queries run when report is refreshed.
Prompt will have a function with access/no access logic
Is it possible when a report is refreshed a prompt will run in the background without asking user to enter some values.
When I refresh report…if I have access…prompt which is in th e background will run successfully and I will data for the report.
If I dont have access to report I will get an error message saying “I dont have access” based on function logic.
I think we should be able to include a variable in a prompt created in universe level…this variable will represent various users who run the report.
Depending in user access…when user refresh report…first prompt will run in background to check user access.
If user has access… report will run and get data …if has no access… error message will pop up saying “no access to report”.
This was we want to avoid group,roles,access concept in CMC.
So user access will be determined when a user refreshes/opens a report.
I think row level security (with a user security table in the database) suits your requirement rather than creating UDFs to define report access to users
.
So, where are you going to store all the info that the function is going to read?
What you are asking is not simple and may not be possible. BO assumes the reports are stored in the repository. Users have to log in to see a list of reports. They only see the ones they are allowed to see. You have to implement this stuff somewhere. Why not just use the CMC?
Haider, row level security has nothing to do with this. bikram_10 doesn’t want to implement anything.
Reason we ( a dept within a company) wanted to avoid CMC is …everytime there is a need to change user security for access to a report/folder we need to ask centralized BO admin team to make changes. To avoid asking them for security change all the time we were thinking if we can implement user security in report level.
So…with this concept all user will have access to all reports…no folder restrictions to any user.
But when a user tries to refresh a report…a prompt will run before report starts refreshing…promt will have avariable to represent all users…prompt will have a logic to give access/no access to user.
User access rights will be defined in database level…may be we need tables with user ids and report CU ids…and make logic based on these tables.
Just a thought guys…Like steve said…may be its not possible.
This is exactly the reason that it doesn’t/shouldn’t work. BO is avery secure tool. You are tryinto bypass that security by makeing a call.
While it may be possible with some sort of SDK wrapper around InfoView, Why not work wiht the central team and have them give you delegated access to the CMC. it can be set up so that you can administer only the areas that make sense for you.
@bikram:
Can you give some details about those reports which you want to assign & revoke access to users
Does the reports have data based on depts or divisions which can be given access to a particular user/group?
.
As others mentioned, what you’re trying to achieve is a bit difficult and defeats much of the purpose of enterprise BI platforms such as BO.
Having said that, I must ask: Are you able to deploy your own java/.NET applications within your infrastructure?
If the answer is “yes”, then you could always create a JSP page and manage user authentication against your LDAP/WinAD directory yourself, and with the now-verified userID, pass this via POST (might not be secure enough for some situations) as a prompt to your infrastructure team’s BO server using their “openDocument.jsp” convention and render your report. Of course, if a user has access to this report via standard BO they could always refresh it for any user via interactive prompt - but this of course you could lock down.