Click here to load reader
View
223
Download
1
Embed Size (px)
2015 Oracle Corporation
2015 Oracle Corporation
Oracle BI 11g Security Configurations
Oracle BI 11.1.1.9.0 Adam Bloom
Oracle BI Product Manager
2015 Oracle Corporation
The following is intended to outline our general
product direction. It is intended for information
purposes only, and may not be incorporated into any
contract. It is not a commitment to deliver any
material, code, or functionality, and should not be
relied upon in making purchasing decisions.
The development, release, and timing of any
features or functionality described for Oracles
products remains at the sole discretion of Oracle.
2015 Oracle Corporation
Agenda
Authentication and Authorization for BI 11g
Architecture Overview
Supported Configurations
Authentication Mechanisms with and without
SSO
System Users and the Credential Store
Troubleshooting and Logging
Types of Security
2015 Oracle Corporation
Authentication and Authorization for BI EE 11g
For the purposes of comparing the approaches to authentication and authorization:
Think of Authentication as the process of validating the userID and password and consequently setting the USER session variable in the BI EE session.
Think of Authorization as the process of discovering the groups that the user is a member of, and then deriving which Application Roles (and associated permissions) the user should be granted. This results in setting the ROLES session variable in the BI EE Session. Refer to the slide GROUP and ROLES Session Variables
2015 Oracle Corporation
Authentication and Authorization for BI EE 11g
At a high level, there are two approaches to authentication and authorization into BI EE 11g.
Firstly, new in 11.1.1.3, we integrated BI into Fusion Middleware and now make use of the Fusion Middleware security mechanisms built on the FMW security infrastructure (OPSS).
Authentication is via OPSS which in turn uses the Weblogic authentication mechanism (Authenticators defined in the Weblogic Security Realm). The resulting authenticated userID is used to set the USER session variable.
Authorization is via OPSS to retrieve group membership via Weblogic Authenticators. This works together with the Policy Store to derive a list of Application Roles for the user and the groups assigned to that user. This list of Application Roles is used to set the ROLES session variable.
Secondly, the 10-g style Init Block mechanism for authentication and authorization is still available.
Authentication is via an Init Block that sets the USER session variable
Authorization is via an Init Block that sets the GROUP (or ROLES) session variable
2015 Oracle Corporation
Authentication and Authorization for BI EE 11g
Advice for customers on which Authentication and Authorization Mechanism to use
Customers should not mix the two approaches. i.e they should not attempt to authenticate users using FMW security and authorize users using Init Blocks.
Not all use cases are currently supported by FMW security. Until such time that FMW security is able to support a particular use case, customers should continue to use the 10g-style Init Block approach for authentication and authorization.
If you use FMW security in BI 11g then both users and group membership should be available via one or more BI EE certified Authenticators defined in WLS.
FMW security in BI 11g is limited to BI EE certified WLS authenticators that work with the User Role API.
2015 Oracle Corporation
Upgrading from 10g and Backwards
Compatibility About the introduction of FMW Security to BI and Backwards compatibility of other
authentication mechanisms:
When introducing FMW security into BI, the aim was to provide as smooth an upgrade path, and as seamless backward compatibility, as possible.
10g systems built on init blocks should continue to work in the same way when upgraded to 11g.
About upgrading from 10g to 11g:
If you upgrade 10g RPD users, they become Weblogic LDAP users in 11g (i.e. using FMW Security) so we no longer have RPD users. In this case, users and group membership for those users will be defined and maintained in the embedded Weblogic LDAP.
On upgrade, all RPD groups are migrated to LDAP groups in the native Weblogic LDAP
Additionally, on upgrade, all RPD groups used to secure elements of the RPD are migrated to Application Roles in the file-based Policy Store.
On upgrade, any element in the RPD that was secured by an RPD group will become secured by the Application Role with the same name (created during the upgrade process)
The upgrade process does not do anything with Web Groups. Web Groups continue to exist in 11g, but customers are encouraged to replace them with Application Roles.
2015 Oracle Corporation
Use Case Users in LDAP and Group Membership in
Database FMW Security or Init Block for
Authentication?
The most common use case for BI customers is to authenticate users in LDAP with group
membership coming from a database query. If you have users in LDAP and Group
Membership for those users defined in a database table, use the BI SQL Group provider as
described in the BI Security guide.
The documented approach for integration with E-Business Suite continues to be based on Init
Block authentication for BI EE 11.1.1.9.0.
Security integration for BI Applications should follow the approaches in the BI Applications
documentation.
2015 Oracle Corporation
Use Case Security Integration with
E-Business Suite 11g Customers can use one of the following approaches to secure their BI EE system when
sourcing data from E-Business Suite
Direct E-Business Suite to BI EE security integration using the ICX cookie method as described
in the BI EE Integrators Guide This is the only method able to secure data using the current responsibility of the user
This is the only method that allows Action Links back to E-Business Suite
This approach has known limitations with Delivers due to the integration with EBS Responsibilities
This approach has known issues with BI Publisher as this approach does not allow BI Publisher to impersonate a user
Please refer to Doc ID 1937856.1 for an updated method that lifts some of the limitations of the ICX cookie approach
This approach does not work with BI Office or BI Mobile or SmartView
Shared Identity Store with E-Business Suite If E-Business Suite is integrated with OID (and optionally OSSO), then BI EE can point to the same OID either via FMW
security or via Init Blocks.
Init Blocks should not rely on the availability of an ICX cookie for the user
Independent Identity Stores for BI and EBS Some customers have a separate login for BI and maintain the EBS and BI user populations independently.
Init Blocks should not rely on the availability of an ICX cookie for the user
Other approaches may be possible
2015 Oracle Corporation
Use Case Security Integration with
Siebel
11g Customers can use one of the following approaches to secure their BI EE system when
sourcing data from Siebel CRM
Direct Siebel to BI EE security integration using the embedded method as described in the BI
EE Integrators Guide This is the only method that allows Action Links back to Siebel
Behind the scenes this method is based on posting a UserID and Password to BI from Siebel
(&NQUSER/&NQPASSWORD method).
This method could potentially use either FMW security or Init Blocks depending on the individual implementation design
Shared Identity Store with Siebel If Siebel has been configured to authenticate against LDAP (and optionally SSO), then BI EE can point to the same LDAP
either via FMW security (assuming it is a BI EE certified LDAP) or via Init Blocks.
Independent Identity Stores for BI and Siebel
Other approaches may be possible
2015 Oracle Corporation
Use Case Security Integration with
PeopleSoft
11g Customers can use one of the following approaches to secure their BI EE system when
sourcing data from PeopleSoft
Direct PeopleSoft to BI EE security integration using the embedded method This method has not been updated for BI 11g and is based on a 10g Technote
Behind the scenes this method is based on posting a UserID and Password/SessionID to BI from PeopleSoft
(&NQUSER/&NQPASSWORD method).
This method could potentially use either FMW security or Init Blocks depending on the individual implementation design
Shared Identity Store with PeopleSoft If PeopleSoft has been configured to authenticate against LDAP (and optionally SSO), then BI EE can point to the same
LDAP either via FMW security (assuming it is a BI EE certified LDAP) or via Init Blocks.
Independent Identity Stores for BI and PeopleSoft
Other approaches may be possible including integration through the PeopleSoft portal
2015 Oracle Corporation
Use Case BI Mobile
Please refer to:
OBIEE 11g: BI Mobile Supported Security Configurations (Doc ID 1996632.1)
2015 Oracle Corporation
Use Case SmartView
SmartView can use certain forms of SSO. Please refer to the EPM documentation:
http://docs.oracle.com/cd/E17236_01/epm.1112/epm_se