An OBIEE 11g Security Primer : Introduction

For anyone who's been waiting for the Oracle Press "OBIEE 11g Developers Guide" that I've seemingly been working on ever since Oracle acquired Siebel, you'll be pleased to know that I'm working on the final chapter now. The only issue (for me) though with this is that I've saved the best (ahem) to last … Security. I guess I've been putting the security chapter on the back-burner for a while now because (a) it's probably the most complicated, tricky area to cover in OBIEE 11g, and (b) the initial implementation was a bit ropey, so I've been waiting for the feature to mature over the various releases. Well, we're at OBIEE 11.1.1.6 now and there's no more chapters to write, so I guess it's time to tackle this topic.

I tend to try and plan out chapters, and in particular the examples, in advance of actually writing something, and as security is such as complicated, and misunderstood area of OBIEE I thought it'd be worth covering the topic in a series of blog posts before writing the chapter; firstly as a way of gathering my own thoughts, and also as a way of peer reviewing what I'm putting together. So hopefully, if you're new to OBIEE 11g security, the five blog posts I'm going to run next week will be of use to you; if you're experienced with OBIEE 11g and you've done a lot to do with security, I'd also appreciate your comments and also any suggestions on how to do things better, or differently. I'll start off though with an overview of OBIEE 11g security, and put some pointers down towards the postings I'll be doing next week on this topic.

So, let's start with an overview of OBIEE 11g security. Security in Oracle Business Intelligence to my mind takes several forms:

• Row-level filters that are applied to data, either automatically by settings in the repository, or by developers by adding filters to reports
• Subject-area permissions and restrictions giving you access (or not) to whole sets of data
• Restrictions and controls on what parts of the application you can access; for example, whether you have access to the analysis editor

When you're logged into OBIEE as "weblogic" after doing an install on your laptop, none of this really comes into play as you can access everything with no restrictions. But OBIEE systems deployed on customer sites typically want to restrict this type of access to administrators, with end-users only able to author and view reports and dashboards, not make system-level administration changes. Then, as the system gets deployed across the enterprise, you'll want to restrict what sets of data are available to different groups in the organisation, partly to stop data falling into the wrong hands, but also partly to reduce the amount of data users have to navigate through. Determining and setting what data sets are available to groups of users is usually referred to as "authorisation".

As well as authorisation, you typically need to verify that someone logging into a system is really who they say they are. This is referred to as "authentication", and can be as simple as checking a username and password that's stored in the built-in WebLogic LDAP server, through to connecting through to external directories such as Microsoft Active Directory, and usage of access tokens such as smart cards and the like. These two things, authorisation and authentication, is where a lot of the work goes in setting up security for OBIEE, and we'll cover these in the first two postings of the series next week.

As well as authentication and authorisation, there are a number of topics and tasks that people associate with OBIEE 11g security. These include:

• Administering users and groups in the WebLogic Server LDAP Server, and mapping these through to Fusion Middleware application roles
• The mysteries of application policies, plus all the associated Oracle Platform Security Services stuff (policy stores, providers and so on)
• Connecting OBIEE to external directories such as Microsoft Active Directory, as well as setting up mix-and-match authorization/authentication setups involving providers, initialisation blocks, web groups and so on
• Setting up things such as SSL (Secure Socket Layers), SSO (Single Sign-On) and security hand-offs between  OBIEE and the Hyperion product stack
• As well as the process around on-boarding, managing and then existing staff and the impact this has on security

So it's a pretty big topic, and one that realistically it's tricky to cover in just one chapter in a book. But it's still a very important topic, and so over five days next week I'm going to take a look into a number of OBIEE 11g security topics, with the outline of the week looking like this (I'll update the links as I post the articles):

• OBIEE 11g Security Week : Row-Level Security
• OBIEE 11g Security Week : Subject Area, Catalog and Functional Area Security
• OBIEE 11g Security Week : Understanding OBIEE 11g Security, Application Roles and Application Policies
• OBIEE 11g Security Week : Managing Application Roles and Policies, and Managing Security Migrations and Deployments
• OBIEE 11g Security Week : Connecting to Active Directory, and Obtaining Group Membership from Database Tables

Which looks like a fun set of topics by anyone's standards ;-)

So, keep an eye on the blog next week, and add any comments or feedback as each post goes up. See you all next week.