I have a couple of questions about OBIEE user authentication. * We are currently authenticating most OBIEE users through an LDAP server located on the same physical server as the OBIEE app server. I want to change the users to the use the default Weblogic authentication. Do they each have to be dropped and recreated with the default authentication? I don't see a way to just switch them over in the Weblogic administration console. * What is the method to get OBIEE to connect to a database table to validate the user (instead of manually creating them in Weblogic admin console)?

Do you expect user creation in WLS to write into your LDAP?! That's not how security works. Creating user in the WLS interface creates then in the WLS-embedded security store.

I changed the authentication provider order to rank OpenLDAP as the first provider, but when I create a new user it automatically assigns them to the DefaultAuthenicator (native authentication).

No Worries. Quick overview on how it works in our 11g environment: * Authentication Block. Query to populate these session variables: USER, DISPLAYNAME, and EMAIL for the :USER and :PASSWORD provided. Without getting into excessive detail, we actually do a pl/sql call to a web service that authenticates the user. We don't actually store our passwords in this schema. If you were going to store your passwords in the schema, you'll likely want to use something like dbms_crypto.hash. * Authorization GROUP Block. Query to populate the GROUP session variable (row-wise). For the :USER logged in, this query returns a row per "Application Role" the user is mapped to in the database. * Authorization WEBGROUPS Block: Query to populate the WEBGROUPS session variable (row-wise). For the :USER logged in, this query returns a row per "Catalog Group" the user is mapped to in the database. You wouldn't need this block if you don't use Catalog Groups. When moving this to 12c, we are using the ReadOnlySQLAuthenticator provider instead of Init Blocks, but the concept of using a database schema to authenticate/authorize users is still very similar. It's just the implementation method is quite a bit different (and more in line with what would typically be considered "best practice")

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Oracle Communities

Oracle Analytics and AI

Child Item

Change OBIEE user authentication

3597535

I have a couple of questions about OBIEE user authentication.

We are currently authenticating most OBIEE users through an LDAP server located on the same physical server as the OBIEE app server. I want to change the users to the use the default Weblogic authentication. Do they each have to be dropped and recreated with the default authentication? I don't see a way to just switch them over in the Weblogic administration console.
What is the method to get OBIEE to connect to a database table to validate the user (instead of manually creating them in Weblogic admin console)?

Find more posts tagged with

Accepted answers

All comments

handat

The default authenticator in weblogic is an embedded ldap server. You are probably better off using your current ldap server rather than the embedded weblogic ldap server, but that really depends on how many users you really have. Migrating ldap users from your ldap server to the embedded ldap isn't that difficult. You just need to export your user from your current ldap server into an LDIF file, and then import that into the embedded ldap server. You might need to filter the LDIF file a bit to remove unneeded attributes and objectclasses prior to importing.

Robert Angel

On 1 you just have to change the order such that the default weblogic takes first precedence.

On 2 what version of OBIEE are you on?

3597535

We want to stop using LDAP authentication altogether, because we have a single OBIEE server, rather than a server "farm" and the LDAP port results in some possible security problems the way it's set up. We could fix the port problem but since we don't need LDAP, going to WebLogic Authentication for all users is preferable.

I don't want to drop and recreate the users that currently have LDAP authentication if there's an easy alternative. If I delete the LDAP authentication provider in the Weblogic console, will it automatically switch everyone to the WebLogic Authentication Provider - which is the first authentication method listed?

3597535

Do I just have to delete the LDAP authentication provider in the Weblogic console in order to automatically switch everyone to the default WebLogic Authentication Provider?
We are using OBIEE v. 11.1.1.7.170418.

Robert Angel

On 1 - that is a 'no', you do not have to delete anything, just change the order of precedence as previously described, BUT, there is no 'magic' switch that will lift everyone in your LDAP and convert them all into native users, you would have to configure them yourself to achieve this.

On 2- there is no external database option for this, only what you have seen - I too dream of the day you can mass populate users using sql code.... something that was relatively easy via a file for v. 10g - that is progress for you...

mac2

It is indeed possible in your 11g version to store users, groups, and user_group assignments in a database schema and authenticate/authorize based on that schema. You can use Initialization Blocks (defined in the RPD) to handle this. You'll need to read up on the :USER and :PASSWORD system session variables to understand how they work.

Or you could use a ReadOnlySQLAuthenticator provider instead of init blocks. If (when) you move to OBIEE 12c, you'll want to use a ReadOnlySQLAuthenticator instead of init blocks, but your database schema shouldn't need much (if any) changes when you move to 12c.

Robert Angel

Initialization blocks is only partial security, typically used for row level filters specific to end users, it does not handle initial user login and general OBIEE function based security.

On the rest see =>

https://docs.oracle.com/cd/E28280_01/bi.1111/e10543/legacy.htm#BIESC307

mac2

Robert Angel wrote:Initialization blocks is only partial security, typically used for row level filters specific to end users, it does not handle initial user login and general OBIEE function based security.On the rest see =>https://docs.oracle.com/cd/E28280_01/bi.1111/e10543/legacy.htm#BIESC307

I disagree. You can read section A.1.2. of the document you linked for more information. I also run a mature 11g environment where we do authentication and authorization using RPD init blocks + an external database schema. This has been running for several years.

Robert Angel

Mea maxima culpa!

I stand corrected.

The document is a little sparse on the detail, do you have to populate every role for this, or is it group level security in terms of OBIEE function based security?

mac2

No Worries. Quick overview on how it works in our 11g environment:

Authentication Block. Query to populate these session variables: USER, DISPLAYNAME, and EMAIL for the :USER and :PASSWORD provided. Without getting into excessive detail, we actually do a pl/sql call to a web service that authenticates the user. We don't actually store our passwords in this schema. If you were going to store your passwords in the schema, you'll likely want to use something like dbms_crypto.hash.
Authorization GROUP Block. Query to populate the GROUP session variable (row-wise). For the :USER logged in, this query returns a row per "Application Role" the user is mapped to in the database.
Authorization WEBGROUPS Block: Query to populate the WEBGROUPS session variable (row-wise). For the :USER logged in, this query returns a row per "Catalog Group" the user is mapped to in the database. You wouldn't need this block if you don't use Catalog Groups.

When moving this to 12c, we are using the ReadOnlySQLAuthenticator provider instead of Init Blocks, but the concept of using a database schema to authenticate/authorize users is still very similar. It's just the implementation method is quite a bit different (and more in line with what would typically be considered "best practice")