Oracle BI Publisher Blog

In 10.1.3.3 there is a feature that Im embarrassed to say I did not know about until I got an email today asking about it - I checked the docs and it appears our resident 'word wrangler' (read 'doc writer') Leslie was in the dark too. Im referring to the wonderful subject of user security - we boast a growing list of supported security configurations - our own native flavor, LDAP, BI Server, E Business Suite. Well, there's now another 'Oracle Database' - how many of you spotted it?

It essentially lets you set up all of your users in the database - which you will have done anyways - not sure how many of your business users have a username in your db but the option is there for you. Once you have your users you, can then hook the publisher server up to the db for user management. There is some set up to do but its pretty quick.

Quick recap on the report security model we support:

Reports sit in Folders, Folders are assigned to Roles, Roles can be assigned to other Roles and Roles are assigned to User. When a user logs in, we look at their roles and then work out what folders and therefore reports they have access to.

Getting the house in order

We have two sides of this security model to sort out before we can use it ...

Database side of the House

Assuming we have set up the users already we need to create some roles that BIP recognizes. Im not going to get into how to create and assign roles to users - get googling if you're unsure. BIP needs these roles created in the database:

• XMLP_ADMIN ? this is the administrator role for the BI Publisher server.
  
• XMLP_DEVELOPER ? allows users to build reports in the system.
  
• XMLP_SCHEDULER ? allows users to schedule reports.
  
• XMLP_ANALYZER_EXCEL ? allows users to use the Excel analysis feature.
  
• XMLP_ANALYZER_ONLINE ? allows users to use the online analysis feature.
  
• XMLP_TEMPLATE_DESIGNER - allows users to connect to the BI Publisher server from the Template Builder and to upload and download templates.

Create these roles and assign them as you wish to db users depending on what you want the user to be able to do. Thats not the end of it - you can create as many roles as you wish you'll use them on the publisher side and attach folders to them, for instance, you might create an HR_MANAGER role and assign an HR folder to it ... duh!

Lastly, assign the XMLP_ADMIN role to someone like SYSTEM or a user with admin privileges - this is important.

Once you have created the roles you can move on to the publisher side ...

Publisher Side of the House

With the database security option we manage the users and their roles in the database and then map folders to those roles in the BIP UI. To set it up:

1. Login into BIP with an Administrator responsibility
   
2. Navigate to the Admin tab then to the Security Configuration
   
3. In the Security Model section pick 'Oracle Database' from the drop down
   
   
   
   
4. Fill in the fields required to connect the database - check out the graphic for hints.
   
5. The user you enter has to be able to access data from dba_users/_roles/_role_privs tables - so user in the appropriate user
   
6. Save your work - you're going to need to bounce the server to get the changes to take effect.

Once the server is bounced you can now log in with your db user that has the XMLP_ADMIN role assigned. You can now start assigning folders to db roles so that users can access reports.

Navigate to the Admin tab then to the Roles and Permissions page. You'll now see all the db roles along with any of the new ones you may have created.

Notice the HR_MANAGER role, this is effectively a dummy role in the db but we can attach folders to it to make a more 'logical' role structure that is easily understood. You will of course not find the XMLP_XXXX roles in the list as you would when using BIP Security. Check the user guide on how to add folders to roles.

Once you have assigned the folders to the roles you want, save your work and your done. Users can now log in with their database username/password combos to get into BIP and access the reports they are permitted to access.

Have you ever set up the Enterprise release with OBIEE or another security model only to find something got screwed up and we have locked you out of Publisher? If so, read on ...

I have to thank Mike for digging up the solution. We use a configuration file to store security information including whether you want a local superuser or not. Its always a good idea to set this up no matter what the security model you want to use - company security policy not withstanding of course.

   <property name="SUPERUSER_PASSWORD" value="admin"/>
   <property name="SUPERUSER_USERNAME" value="admin"/>
   <property name="GUEST_FOLDER" value="false"/>
   <property name="ENABLE_SUPERUSER" value="true"/>
   <property name="SECURITY_MODEL" value="XDO"/>

I'm still head down. nose to the grindstone, working on various projects that take me away from the blog or at least away from the big articles. If I were away, you would not be reading this today. When I do raise my head and get outside Im beginning to think that Spring might actually be on the way. Im only having to wear two layers of clothing now and hardly need my wooly hat to keep the balding bonce warm. The snow is slowly receding from our yard and the male deer appear to be sharpening their antlers on our trees in anticipation ... at last.

Today, another nugget and a plea - let's start with the plea. Please please please take a look at the documentation first if you get stuck - not so easy for non-English speakers/readers I know but the rest of you have no excuse. It is good stuff in my opinion, yes there are bits missing and yes its a little scattered but there are answers in dem der pages. Check out the documentation library pages here,

http://www.oracle.com/technology/documentation/bi_pub.html

We do put a lot of effort into the doc, Leslie, our writer is snowed under trying to provide a core guide for the other BIP flavors to pick up plus the EBS and Standalone/BIEE BIP user guides - we need writers! Sorry, thats not a job offer.

OK, rant over! There was a question on the forum asking how to control all the buttons and tools in the standalone release, allowing or preventing users from having access. Such as, Excel Analyzer, Scheduling, etc. We secure all of that by using BIP roles that you assign to your users.

Not an exhaustive list of all the functions but you ought to be able to find a combination that will satisfy your need to control what users can and can not do in the system. These are seeded roles in the system and you can assign them to your users quite easily - just read the manual to find out how ;0)

A long while back I posted an entry on linking to a report via a URL. All was good but it only worked if you either:

1. Were hooking BIP up to SSO with your calling application or
2. You placed the report in the Guest folder which was unsecured.

Now, back in an earlier release the dev guys sneaked a feature out that I was vaguely aware of and thought I knew but it took the almighty Bryan Wise to remind me. You can now pass the username and password on the URL to avoid the two cases above and open up other possibilities.

You can just add the following parameters to your URL

&id=XXXXXX&passwd=YYYYYY

For example:

http://127.0.0.1:9704/xmlpserver/HR Manager/W2/W2.xdo?id=Administrator&passwd=Administrator

What about security? Well 'developer beware'!, I wanted some cool Latin phrase that no one would understand but the translators are a little funky in my opinion. Never the less, its a feature, its up to you if you want to use it, or maybe your security folks. So, now you know and I now have somewhere to point folks who ask me about it :)