Sunday, February 27, 2011

How to create Users and Groups in OBIEE11g


How to create Users and Groups in OBIEE11g


Steps to Create a User and Group:

If you want to create a new User and assign that User to a new Group that you have created, do the following:

1.Launch Weblogic Administration Console eg: http::/console
2.Create a new User in security Realm.
3.Create a new Group in security Realm.
4.Add User to new Group.
5.Launch Fusion Middleware EM console (http::/em)and create a new Application Role and assign it to the new Group.
6.Edit the repository (RPD file) and set up the privileges for the new Application.
2. Create a new User in security Realm:

Login Weblogic admin console and on Left side panel click on Security Realm1 . And click on myrealm2 in Right side panel.







Click on Users and Groups Tab and below select Users tab again and then click New as shown in below screen shot.



Create user by providing all details and click ok.




3. Create a new Group in security Realm:

Login Weblogic admin console and on Left side panel click on Security Realm1 . And click on myrealm2 in Right side panel.





Click on Users and Groups Tab and below select Groups tab again and then click New as shown in below screen shot.






Create a Group by providing all details and click ok.



4. Add User to new Group.

Click on Security ream->myrealm.

And then click on Users and Groups and Users tab. In that click on new user (here User1 )



In Next window click on Groups. In Available Groups select created group and Move to chosen window as shown below.








5. Launch Fusion Middleware EM console (http::/em)and create a new Application Role and assign it to the new Group:



Assign Group to Application Role:




Important: Stop OPMN and Start again


6. Edit the online repository (RPD file) and set up the privileges for the new Application:

Click on Manage->Identity





Click on BI Repository and on Right window clicking on Application Roles - Now you can see roles created in EM Console.



Security in OBIEE 11g, Part 1

Continuing the series on OBIEE 11g, our guest blogger this week is Pravin Janardanam. Pravin has been working with OBIEE since his days with Siebel and is one of our top architects. In this two part series, he will be tackling the differences in security between OBIEE 11g and 10g, and providing some hints on migration of security from a 10g environment.

OBIEE 11g Security Overview, Part 1


by Pravin Janardanam

One of the key enhancements in OBIEE 11g are the changes in Security Architecture. OBIEE 11g implements the common security architecture as the rest of the Fusion Middleware stack. While this approach has many advantages , it does represent a significant shift in both the approach and architecture of OBIEE for authorization and authentication of users.


Oracle Platform Security Services

The architectural components of Fusion Middleware that OBIEE 11g leverages are the Oracle Platform Security services (OPSS) and WebLogic authenticators. These are the components that FMW usees to provide a common security framework across the many Oracle applications that run on FMW, including OBIEE 11g and Fusion Applications.

OPSS is standards based, portable, integrated enterprise grade security framework for Java applications. OPSS provides an abstraction layer in the form of standards-based application programming interfaces (APIs) that insulate developers from security and identity management implementation details.

OPSS is used as security platform by Fusion Apps & Fusion Middleware including WLS, OES, SOA & WC. More information on OPSS can be found at: http://www.oracle.com/technetwork/middleware/id-mgmt/index-100381.html


Key Security Changes for Release 11g:

Some of the key changes in OBIEE security in 11g are

1. User and Groups are no longer defined in RPD

2. User Profile is derived from LDAP server

3. RPD is protected by RPD Password

4. RPD is encrypted

5. Introduction of Applications Roles

6. User Administrator and Group Administrators not hard-coded in RPD

7. Administrator user not used for Inter-Process Communication (component to component)

8. Credential Store storage mechanism

OBIEE 11g provides a scalable default security mechanism available for immediate implementation after installation. The default security mechanism provides controls to manage users and groups, permission grants and credential store. Following are the security controls that are available after the installation.

1. An embedded LDAP server in WebLogic available to store users and groups known as “Identity Store”

2. A file to store the permission grants information known as the “Policy Store”

3. A file to store user and system credentials for inter process communication known as the “Credential Store”.




Let’s look at the differences based on some of the common security concepts, Authentication and Authorization.

Authentication:

In 10g default Authentication is RPD based. In 11g, the user and group definitions are moved to a LDAP server embedded with WebLogic server known as the “Identity Store”. Users and Groups can no longer be created in the RPD. Creation of Users and Groups and the association of members to groups are managed in the WebLogic administration console. WebLogic provides the default authentication provider for OBIEE 11g. Users are authenticated by the WebLogic server based on the credentials in the embedded WebLogic LDAP server. The embedded LDAP server is default Authentication provider for WebLogic and hence OBIEE.

OBIEE 11g gets user, groups and other user attributes from the WebLogic LDAP server. This also eliminates the limitation we had with previous versions of OBIEE where only one Group for a user can be read directly from an LDAP server.

The following screenshot shows the default Authentication provider.



WebLogic supports integration with commercial identity management products (also known as Authentication providers). The screenshot below lists some of the Authentication Providers. OBIEE 11g certification matrix provides a list of all supported Authentication Providers.





At this time, the following Authentication providers are supported by OBIEE 11g.

· Active Directory 2003, 2008

· SiteMinder 6

· OpenLDAP 2.2.x

· Sun Java System Directory Server version 6.3

· eDirectory 8.8

The following screenshot shows the users created in the WebLogic administration console. By default users and groups are created using Oracle WebLogic Server Administration Console. The following screenshot shows the groups created using WebLogic administration console



The following screenshot shows the groups created using WebLogic administration console.





The following screenshot shows the members associated to the groups in the WebLogic administration console.



The users and groups created in the WebLogic administration console can be viewed in the OBIEE administration console. Before looking at the users in the RPD, since we are discussing about the changes in Authentication, I would like to cover the RPD password. In OBIEE 11g, every RPD is protected by an RPD password. Remember, there are no “Administrator” user and “Administrators” group in OBIEE 11g. Look at the RPD creation screenshot below. The RPD creation utility, requests a password to protect the RPD. The same password is also used to encrypt the password. In 10g only a few critical elements in the RPD were encrypted. In 11g, the entire RPD is encrypted.




Let’s take a look at the users that were created in the WebLogic admin console in OBIEE administration console. Note that the menu item “Security” in 10g got changed to “Identity” in 11g.






In the screenshot below, we see that the users created using the WebLogic administration console and stored in the WebLogic embedded LDAP server is being displayed by the OBIEE administration console.




Note that there is no option to create a user or a group in the menu from the screenshot below. The OBIEE administration tool only displays users defined in the WebLogic embedded LDAP server. There is a new menu item “Application Roles”. I will cover this when discussing the changes in Authorization.









Even though the underlying embedded WebLogic identity store is a LDAP server, OBIEE server does not use the “Authentication” initialization block for the default LDAP server embedded within the WebLogic server. The default WebLogic authenticator is a replacement for the OBIEE authentication for users defined in the RPD in 10g. This gives us two options to integrate an external LDAP server with OBIEE for authentication. The external LDAP server can be integrated with WebLogic server as an additional authentication provider or by integrating the LDAP server with OBIEE like in 10g by registering the LDAP server in the RPD and creating an “Authentication” initialization block based on the registered LDAP server. The recommended approach going forward is to integrate all authentication providers at the WebLogic level.

In my next blog entry I will discuss about the changes to “Authorization” in OBIEE 11g, the applications roles, policy store and the credential store.




Saturday, February 26, 2011

Load balancing with Apache: a tutorial on mod_proxy_balancer

Load balancing is a technique aiming at distributing workload in a computer network, in order to optimally utilize resources, avoid overload and maximize throughput.
Computer clusters rely on load balancing to distribute workload across network links, CPUs, web servers, etc.
A server farm is a common application of load balancing, where multiple servers seamlessly provide a single Internet service. In this case the load balancer accepts requests from external clients and forwards them to one of the available backend servers according to a scheduling algorithm (e.g. round robin, random choice, on a reported load basis, etc.)
Load balancers can be implmented using dedicated hardware or ad-hoc software.
In the remainder of this tutorial we deal with configuration and features of the Apache web server’s mod_proxy_balancer, the Apache module developed to provide load balancing over a set of web servers.
The tutorial covers basic installation and configuration under any Linux distribution.
What is mod_proxy_balancer?
mod_proxy_balancer is an Apache module available since Apache 2.1. It allows turning an Apache installation into a load balancer retrieving requested pages from two or more backend web servers and delivering them to the user’s computer.
One important feature of mod_proxy_balancer is that it can keep track of sessions which means that a single user always deals with the same backend webserver (sticky sessions).
Requirements and installation
The module requires:
• an Apache HTTP Server installation version 2.1 or later (at the time of writing, 2.2.15 is the latest version available);
• mod_proxy extension.
In order to install Apache and the required extensions, download the sources from the Apache HTTP Server website, untar the archive and run the following commands from the main directory:
• ./configure --enable-proxy --enable-proxy-balancer [run ./configure -h to list all the available options]
• make
• make install
Basic configuration
We need three servers to run an example: a load balancer (lb.seco.com) and two worker nodes (wn1.seco.com and wn2.seco.com).
From now on we refer to the Apache HTTP Server installation folder on the load balancer host as $APACHE2_HOME (the default position is /usr/local/apache2).
Find the Apache HTTP Server configuration file ($APACHE2_HOME/conf/httpd.conf) and edit it adding the following instruction:
Include conf/extra/httpd-proxy-balancer.conf
The instruction points at an external configuration file to be included (relative path wrt to the Apache installation) where balancer configuration will be provided.
Now create the httpd-proxy-balancer.conf file in the $APACHE2_HOME/conf/extra folder and add the following lines:

BalancerMember http://wn1.seco.com
BalancerMember http://wn2.seco.com

ProxyPass /test balancer://mycluster
An instance of cluster is created (mycluster) with two members.
The /test URL of the load balancer (i.e. http://lb.seco.com/test) is mapped to the two members.
Requests to the load balancer will be alternatively forwarded to the workers.
Load balancer methods
Three load balance methods are currently available:
• byrequests: weighted request count balancing;
• bytraffic: weighted traffic byte count balancing;
• bybusyness: pending request balancing.
In order to choose the desired method, the following line can be added in the balancer definition (i.e. the Proxy tag):

...
lbmethod=method

where method is one of the three listed before. Deafult is byrequests.
A load factor could be applied to members of the cluster, in order to define the weighted load of each member.
In the following example 30% of the requests will be forwarded to the first member, whereas 70% will be forwarded to the second one. The load factor is an integer number ranging from 1 to 100.

BalancerMember http://wn1.seco.com loadfactor=3
BalancerMember http://wn2.seco.com loadfactor=7
lbmethod=byrequests

Session management
While balancing the load of a web application, it is always possible to implement sticky sessions: requests of the same user will be forwarded to the same member of the cluster.
Balance members will be tagged with a route value as follows:

BalancerMember http://wn1.seco.com loadfactor=3 route=seco1
BalancerMember http://wn2.seco.com loadfactor=7 route=seco2

Session identifiers will be then defined at the application level as the concatenation of a value (independent of the member the client has been assigned to) and the route value as follows:
SESSION_ID=.
Finally, the cluster URL mapping must be declared as follows:
ProxyPass /test balancer://mycluster stickysession=SESSION_ID
where SESSION_ID is the name of the variable at the application level storing the session identifier.
Balancer manager
The balancer manager enables dynamic update of balancer members and their load factor. The mod_status extension is required.
To enable the manager, the following lines of code are required in the httpd-proxy-balancer.conf file:

SetHandler balancer-manager
Order Deny,Allow
Allow from all

The instructions will enable the manager, accessible via browser at http://lb.seco.com/balancer-manager.
Statistics and configuration details will be displayed and settings could be edited.