We have one custom role that was created during implementation. I looked in FMW and saw that there is only one group associated with the custom role - which is the custom group we created for it. By the way, we are using only the standard Weblogic LDAP, no external authentication. When I log into the application (front-end), with a user created with only the custom group in Weblogic, I see that it also has the standard BIConsumers role and the Authenticated role. In FMW, I see the Authenticated role as well as the BI Author role, have membership for the custom role, but not the BI Consumer role. I believe the custom role was created with a 'create like' on the original BIConsumer role.

Here's the part I really don't understand ... the BIConsumer role also has the authenticated role and BI Author role as members (same as the custom role ). So, it doesn't seem like there is any inheritance involved here, right? The only other thing I cam see are a bunch of roles (may be specific to OBIA), like: OBIA_INVENTORY_MANAGER, OBIA_AGENT_ANALYSIS_DUTY, etc.

Does anyone understand why this is happening? Everything I see would suggest that the user with the custom group should only have the 1 custom role and the authenticated role?

Honestly it's always a good idea to remove the authenticated role from anything else, because that one match way more than expected often (as long as username/password match you are part of authenticated).

So if your BI Consumer has authenticated inside every single user in your user will always have BI Consumer at least. That's why I always suggest to break this inheritance and take out the authenticated from any other role.

And also never set security based on authenticated role as that's too large, so if you don't use it for security and you break your inheritance between BI Consumer and authenticated your user will have only your newly created role and authenticated (which will not have any privilege / permission set, so doesn't impact).

Thanks Gianni. I did read through your slides. They are very informative. I'm still not 100% clear on everything, but that is to be expected as I am still learning in this area.

So, let's start with the 'authenticated role'. Are you saying to remove it from each of the roles? For example ... in our case, we have 4 roles: the 3 default ones, "admin", "author", & "consumer"; plus, the custom role (by the way, there is no Bi Analyst role in our version).

In theory authenticated is only part of consumer, it's not supposed to be anywhere else or everybody would be admin or author.

And yes, I would remove it as using it is, in a way, a lack of security.

It represent too many people, everybody with a valid username/password. Let's imagine your LDAP/AD admin add random people in the part of hierarchy which is configured as the one where OBIEE looks for the users, these users will by default have the authenticated one, even if you maybe don't want them in your system and so they don't explicitly have consumer, author or admin or any other app role. So authenticated is actually a possible security risk.

If you managed security by granting app roles to your users to make them consumer/author/admin you can safely remove the authenticated from the members of consumer. Nothing will change for your users but your system will be safer as the security will work only based on what you explicitly grant and not with some random default inheritance.

Ok, thanks Gianni. That makes sense (it's also a good point for overall security). So, I think most of this mystery is solved now. Because each the bi consumer and custom role both had the authenticated-role, it was giving the multiple roles after a successful login. I understand what is happening now.

In fact, there was another custom role in a separate instance (for a grand total of 2 custom roles) along with the others that had the authenticated-role. So, in that case, the user was getting both custom roles and the bi consumer roles, and the authenticated role . So, this is explained too.

I'll go back and give the points, as I think we've answered the main question here.

But ... I know I did not ask this specifically in the beginning, but I do still not totally understand the difference between the "double-tree" & "cartesian product" security models. If you have it in you to provide a brief explanation, I'd appreciate it; no worries otherwise. I am experimenting in the Dev instance, and with each iteration I am understanding more.

[...]I do still not totally understand the difference between the "double-tree" & "cartesian product" security models. If you have it in you to provide a brief explanation, I'd appreciate it; no worries otherwise.[...]

This thread is about to a popcorn-cinema party with Gianni trying to type out a novel ;-)

One model fully works on inheritance, the cartesian one (the name is made-up). Your users will never get assigned to the "placeholders" roles (author, consumer etc.) but only get assigned to the other roles you create (by department or topic etc.). The issue with this one is that you will have tons of application roles as you always need to have all of them, and it also give you a bit of a wrong impression. If you are admin for Finance you still have admin privileges for other content/area of the system because the OBIEE privileges aren't linked to the content but are valid globally on your system.

The other model, the double tree, work with a double tree of security. One tree manage the privileges aspect of the security and works on just the very few app roles like consumer, author and admin.

The second tree is content-based: you have application roles based on the content or organization of your company and cover security for the catalog and subject areas (so 100% content based) while ignoring OBIEE privileges as it's managed by the first tree.

Your users always need to be assigned to 2 application roles at least: one for the privileges, one (or more) for the content. So you can say that user Tom is a consumer (for privileges) and he can consume content from Finance, HR and Sales (from the content based tree of application roles).

The double-tree model requires less application roles as you don't need to inherit the privileges all the time and clearly split the management of the system wide privileges and the purely content related aspects of the security.

I would suggest you adopt the "double-tree" one as it will never give you the wrong impression that somebody is author for HR and consumer for Finance. You will clearly see that a user is an author from a privilege point of view, and then he will be allowed to save content only in the HR branch of the catalog while he will only have read-only permission in the Finance branch of the catalog for example.

Thanks a lot Gianni. Really. That was a very good clarification. I understand what you mean clearly. As I mentioned ... the slides a very well done, I just was not completely sure I was interpreting everything correctly. And, you did a good job filling in the blanks for me.