Oracle Analytics Cloud and Server

Welcome to the Oracle Analytics Community: Please complete your User Profile and upload your Profile Picture

Change OBIEE user authentication

Received Response
145
Views
12
Comments
3597535
3597535 Rank 1 - Community Starter

I have a couple of questions about OBIEE user authentication.

  1. 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.
  2. 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)?
«1

Answers

  • handat
    handat Rank 5 - Community Champion

    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
    Robert Angel Rank 8 - Analytics Strategist

    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
    3597535 Rank 1 - Community Starter

    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
    3597535 Rank 1 - Community Starter
    1. 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?
    2. We are using OBIEE v. 11.1.1.7.170418.
  • Robert Angel
    Robert Angel Rank 8 - Analytics Strategist

    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
    mac2 Rank 4 - Community Specialist

    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
    Robert Angel Rank 8 - Analytics Strategist

    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
    mac2 Rank 4 - Community Specialist
    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
    Robert Angel Rank 8 - Analytics Strategist

    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
    mac2 Rank 4 - Community Specialist

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

    1. 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.
    2. 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.
    3. 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")