Identity Cloud Services and Weblogic Federation with Virtual Users and Groups

Introduction Federation is a well-known pattern and has been discussed at length on this blog. Almost every vendor or cloud provider out there supports Federation and it’s been around for quite some time now. In this blog post, I will talk about Federation again, but this time in combination with Weblogic’s Virtual Users and Groups. […]

SOA Cloud Service – Quick and Simple Setup of an SSH Tunnel for On-Premises Database Connectivity

Executive Overview With the current release of SOA Cloud Service (SOACS) a common requirement often requested is to connect to an on-premise  database from the cloud SOACS instance. This article outlines a quick and simple method to establish the connectivity between the single-node SOACS instance and the on-premise database server using an SSH tunnel. Solution […]

Addition by Subtraction – A Quick Win in Performance

Recently, I worked with a customer where we would notice severe performance degradation over time within JCS (Java Cloud Service). The product used was Oracle Service Bus (OSB) where it would take around 2 seconds to process a request and send a response.  Over time, we would see the same request/response take over 1 minute!  If we […]

JCS (Java Cloud Service) – An Alternative to the SSH Tunnel

The recommended way to use WLST with JCS is to use an SSH Tunnel. While this isn’t that difficult to setup and use, it is an extra step that some may feel as unnecessary.  It also changes the way you have been accustomed to using WLST against your on-premise WebLogic instances. This blog will attempt to provide a […]

Understanding the use of “WebLogic Plugin Enabled”

Introduction: Requests to a WebLogic Server (WLS) usually go through a web server or a load balancer which serve as a proxy for the client requests. When the WLS requests are “front-ended” by either a web server or a load-balancer, the requests are handled via a plugin. It is important for WLS to be aware of the […]

Where did my MDB concurrency go?

Problem Description Recently, there have been numerous customers reporting a similar symptom with regards to MDB (Message Driven Bean) concurrency within WebLogic Server.  The complaint is that not all JMS messages are being consumed in a timely manner and in fact some messages look to be consumed in a serial fashion instead of concurrently. Here is […]

Diagnosing High CPU problems with Java Mission Control

How to diagnose high CPU problems with Java Mission Control? Recently we worked on couple of customer escalations where we have extensively used Java Mission Control to resolve high CPU problems. That prompted me to write an article on Java Flight Recording analysis using Java Mission Control (JMC) In this posting, I’m going to teach you […]

Oracle GoldenGate: Transactional Data Capture from WebLogic Java Messaging Service

Introduction Oracle GoldenGate (OGG) includes an optional set of adapters that adds functionality to capture transactional data from a JMS Queue or Topic and format this data for apply to a relational database. This article presents basic configuration options and discusses best practices as they relate to Oracle GoldenGate for Java version 11.2.1.0 and the […]

Starting and stopping WebLogic automatically using Upstart

I’ve been using Unix and Linux a while. Like a while while. So long ago that the first time I installed Linux it was by floppy disk. I’m not telling you that to brag, or imply that I’m old. I say that to give you a sense of how exciting this change is …

OIM 11g R2 & X.509 authentication

OIM 11g R2 is out! This release brings a lot of new features and also improvements to existing features.OIM authentication providers are among the ones that were improved. The improvements make easier to integrate OIM with SSO solutions (for both SSO p…

Achieve Faster WebLogic Authentications with Faster Group Membership Lookups

In my last post  I wrote about the complicated and timely process of determining all of a user’s group memberships when an LDAP namespace includes nested and dynamic group memberships. I wrote about how you can simplify and speed up getting a user’s group memberships through the use of a dynamic “member of” attribute and specifically the orclMemberOf attribute in OID.

Today I’d like to extend this discussion to WebLogic server authentications.

A Review of LDAP Authenticators and Groups

As I’ve written about in the past, as part of the authentication process, LDAP authenticators do a search to determine what groups the user is a member of which in turn get used in determining the group memberships and roles for the JAAS subject and principals.

By default the WebLogic LDAP authenticators follow the long time consuming process I laid out in my last post for determining group memberships with nested groups. First, it searches all your groups to figure out which groups your user is directly a member of. Then for each of those groups, it searches all your groups again to see which of those groups your user is a member of.

It will continue to search your groups with the results of each subsequent search until you reach the configured maximum level of nested memberships that you want to pursue or all the searches come back empty.

Only it is actually quite a bit “worse” than that because for some reason when the authenticator finds a group within a group it doesn’t just use the DN of that group in the next search, it takes the name of that group based on the “group name attribute” setting in the authenticator and then does a search to find the group’s DN all over again. So, for every group found in a search of memberships for the user there will be 2 new LDAP searches performed. One to get the user’s DN again and one to get the groups that group is a member of.

In my post on tuning LDAP authenticators, I wrote about the importance of tuning the settings governing group membership searches in the authenticator and specifically about limiting the depth of the searches for nested group membership.

Speeding Things Up

Today, I’d like to cover how-to dramatically speed up this process by letting the directory do all the work for you. This is achieved by configuring the authenticator to take advantage of the dynamic ‘member of’ (orclMemberOf in the case of OID) attribute that I wrote about in my last post.

The setting that enables this behavior is in the Dynamic Groups section of the provider specific configuration for LDAP authenticators and is called User Dynamic Group DN Attribute. When configured the LDAP authenticator will skip all searches (for both direct and nested memberships) of dynamic groups. Instead it will add roles (group principals) to the user for every group returned by the LDAP directory (OID) in the value of the specified attribute.

Here is what you need to know about this setting:

1) When configured the authenticator will add roles (group principals) to the user for every group returned by the LDAP directory (OID) in the value of the specified attribute.
 
2) Despite the fact that the setting is part of the Dynamic Group section of the authenticator configuration, the authenticator will add roles for every group returned as part of the value of the attribute, regardless of whether that group is a static group or dynamic group.

3) That being said, the authenticator will still perform a search of memberships for all static groups even when the User Dynamic Group DN Attribute is defined. It will not however perform a membership search of dynamic groups; instead it assumes all dynamic group memberships are captured by the attribute value.

Note especially that the authenticator will still perform a full search of nested static groups even when User Dynamic Group DN Attribute is defined; even though the orclMemberOf attribute in OID includes static group memberships.
Putting It All Together
So, to dramatically improve your WebLogic authentication performance with nested groups I recommend that you configure your authenticators as follows:

1) Enter the appropriate LDAP attribute name for the value of User Dynamic Group DN Attribute based on the type of directory you are authenticating against.. Appropriate values include orclMemberOf for OID, memberof for DSEE, and ismemberof for AD.

2) Set the value of GroupMembershipSearching to limited. The default value is unlimited.

3) Set the value of Max Group Membership Search Level to 0. This will make the authenticator not perform searches for nested group memberships and limit it to performing a single search to find the users direct group memberships. Again, we will be relying on the value of the attribute specified in User Dynamic Group DN Attribute to give us the nested searches.

4) If you want to even eliminate the direct group membership search you can specify an empty Group Base DN. Note here that the Group Base DN must exist or you’ll get an error and a failed authentication. However, it can be empty. So, you can create cn=fakegroupbase as a sibling of cn=Groups,dc=example,dc=com.

5) If you recall in my previous post I mentioned that using the orclMemberOf attribute can result in duplicate listing when nested memberships are returned multiple times, once for each group that the user belongs to that is a member of another given group. Because of this, you’ll probably want to check the Ignore Duplicate Membership option in the authenticator.

Below is a screen shot of an OID authenticator configured with these options:

Before I forget it: HowTo SAML 2.0 IdP-initiated flow in Weblogic

I’d better do it now, otherwise I will forget the details.

Quite some people think that all an IdP-initiated flow requires is the target application URL in the consumer side. This is actually nothing more than a SP-initiated flow. In this way, you’ll hit the Service Provider with no SAML Assertion, will be redirected back to the IdP for the SAML assertion and then sent back to the Service Provider.

An IdP-initiated flow actually first needs to get a hold of a SAML assertion for the authenticated user. The assertion is then submitted along with the request to the target application URL. If the Service Provider decides to accept the assertion, the user is granted access. There’s no need to come back to the IdP for the assertion.

This short post is about how to configure Weblogic SAML 2.0 for an IdP-initiated flow.

The URL to be given to the end user for an IdP initiated flow in Weblogic is:
http://<idp-server>:<port>/saml2/idp/sso/initiator?SPName=<SP-Partner-Name>&RequestURL=<target-application-url>

where:

  • saml2/idp/sso/initiator is the IdP service responsible for processing IdP-initiated request flows.
  • <SP-Partner-Name> is the Service Provider partner name you have configured for the Identity Provider.
  • <target-application-url> is the application you want to access in SSO mode on the Service Provider side.

Here’s an example of a real URL:

http://idp.us.oracle.com:7003/saml2/idp/sso/initiator?SPName=WebSSO-SP-Partner-0&RequestURLhttp://sp.us.oracle.com:9704/analytics

The SPName parameter value actually refers to a partner you’ve configured in Weblogic for your Identity Provider. A Weblogic Identity Provider for SAML 2 requires a SAML2CredentialMapper. And the partner we’re talking about is configured (usually given as a metadata file) in SAML2CredentialMapper’s Management tab, as shown:

SP-Partner

Notice the Name “WebSSO-SP-Partner-0”. It’s the one you need to use as the SPName value in the URL.

Ok, once given the right params, saml2/idp/sso/initiator service will do some magic for us. But we still need to give it a hand. The SP Partner configuration has a parameter called “POST Binding POST Form”. It is the URL containing an HTML form that will post the SAML Response to the SAML Assertion Consumer Service on the Service Provider Side.

post-form

Here’s the post_form.jsp code. Build it into an application and deploy it to the Weblogic server running the Identity Provider.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%@ page contentType="text/html;charset=windows-1252"%>
<html>
<head>
</head>
<%
String samlResponse = (String) request.getAttribute("com.bea.security.saml2.samlContent");
String relayState = (String) request.getAttribute("com.bea.security.saml2.relayState");
%>
<body onLoad="document.forms[0].submit();">
<FORM METHOD="POST" ACTION="http://sp.us.oracle.com:9704/saml2/sp/acs/post">
<INPUT TYPE="HIDDEN" NAME="RelayState" VALUE="<%=relayState%>"/>
<INPUT TYPE="HIDDEN" NAME="SAMLResponse" VALUE="<%=samlResponse%>">
</FORM>
</body>
</html>

 

3 things to notice:

  1. the form action: refers to the Service Provider Assertion Consumer Service for POST binding.
  2. SAMLResponse: the SAML Response generated by the IdP containing the SAML assertion.
  3. RelayState: a reference to state information maintained at the Service Provider.

That’s it.

Summarizing, the user logs in to the Identity Provider, click on a link like http://<idp-server>:<port>/saml2/idp/sso/initiator?SPName=<SP-Partner-Name>&RequestURL=<target-application-url>. The saml2/idp/sso/initiator service looks into <SP-Partner-Name> for the “POST Binding POST Form” and executes it. The form retrieves SAMLResponse and RelayState from Weblogic and auto-submits itself to saml2/sp/acs/post on the Service Provider. If the SAML assertion is accepted, the user’s browser is redirected to the <target-application-url>.

Enjoy your IdP-initiated flows.

Integrating OBIEE 11g into Weblogic’s SAML SSO

SAML is a way to convey identity information across systems. It is an industry-accepted standard and especially interesting when you need to propagate user information between different security domains, because it can overcome the HTTP cookie limitations in cross-domain scenarios (although there are ways to solve that with OAM today) and implement the concept of  transient federation (also known as virtual users), where the user base is not shared between partners.

I’ve recently came across a scenario requiring OBIEE 11g integration into SAML 2.0 SSO. The requirement was that OBIEE 11g should be able to drive its authorization decisions based on the SAML Subject as well as SAML Attribute Statements from the SAML Assertion generated by a home-built Identity Provider (IdP). This post examine what can be done (and how) in this scenario.

The exact products versions used in this demo are as follows:

  • Platform: Windows XP Server
  • Oracle Weblogic Server 10.3.5
  • Oracle Business Intelligence Enterprise Edition 11.1.1.5

OBIEE 11g (since 11.1.1.3) delegates authentication, authorization and credential management to OPSS, which means users, groups, policies and credentials are all externalized. One typical OPSS deployment mode is using an LDAP server as the general security store for all artifacts. Remember though, at the time of this writing, OID is the only one supported LDAP server for policies.

A quick look at OBIEE 11g overall architecture is necessary to understand what comes up right next. I wouldn’t dare going into the details of OBIEE architecture on this post, so I recommend you take a look at the product official documentation. A good starting point is here.

For our purposes here, the important aspect to notice is that OBIEE has some components that run on Weblogic and some components that do NOT run on Weblogic. The core BI services are provided by the BI Server and BI Presentation Services. These are C-based standalone applications indeed.
Within Weblogic, the BI Presentation Services Plugin interfaces with the standalone BI Presentation Services system component, providing the web experience for end users.

The picture below (borrowed from the product documentation) describes the OBIEE architecture.

OBIEE_Architecture

Of particular interest for our topic is the Security Services component.

In SSO mode, the BI Server components gets the authenticated userid from Weblogic and calls back the Security Services to construct an object (containing user principals, like userid and groups) that is returned back to BI server, who in turn uses it to drive authorization decisions on its internal objects. This alone allows OBIEE to consume a SAML Subject for the purpose of authorization decisions. So far, so good.

But what about using SAML Attribute Statements to drive authorization decisions within BI server? That would require SAML Attribute Statements to be persisted into OBIEE identity store once the SAML authentication request hits the server, so that Security Services could construct the necessary object when called back by BI Server. But SAML Attribute Statements are not persisted in the identity store.

Such characteristic essentially moots SAML Attribute Statements in this type of scenario. And that makes the usage of virtual users along with attribute processing irrelevant in a SAML Identity Asserter which also dismisses the need of a SAML Authenticator.

I am not saying this is something impossible to be done. It would require some custom work.

Long story short, in 11.1.1.5, out-of-the-box, OBIEE can consume the Subject out of a SAML Assertion, and that userid has to exist in the configured identity store for OBIEE.


When a SAML assertion is received by the Weblogic server hosting the target application, Weblogic’s SAML Identity Asserter parses the assertion and interacts with the ACS (Assertion Consumer Service) to validate it. If everything is ok, the identified user in the SAML assertion is passed down to the next authentication provider, who effectively authenticates the user and instantiates a Java Subject in the container. Make sure one of your authentication providers following SAML2IdentityAsserter is able to authenticate the user.

AuthenticationProviders

In my demo, the SAML assertion is produced by another Weblogic server working as the IdP (Identity Provider), via a SAML 2 Credential Mapper. A credential mapper essentially maps an existing java Subject to some credential.

From a configuration perspective, there are three main things do be done on OBIEE Weblogic server side: i) configuration of a SAML 2.0 Identity Asserter along with enabling SAML 2.0 Service Provider, ii) change of Analytics’ web.xml and weblogic.xml deployment descriptors and subsequent redeployment and iii) configuration of OBIEE for SSO in Enterprise Manager. For completion purposes, I also show how to configure a Weblogic server to be the Identity Provider.

If you already know how to configure Weblogic Federation Services and what to expect when OBIEE managed servers are in a cluster, you can safely skip the next section as well as Configuring the Identity Provider section. There’s really nothing special particular do OBIEE in them.

If you’re configuring both the SP and IdP in a single host (for testing purposes), make sure to refer to each of them using different names. For example, in my setup, the SP is sp.us.oracle.com and the idp is idp.us.oracle.com.

1. Configuring the Service Provider

Reference documentation is here. Here’s a tour and some notes over my configuration:

1) Add a SAML 2 Identity Asserter to the set of authentication providers and restart the Admin server. This is necessary for enabling configuring the server as a Service Provider (SAML 2.0 Service Provider tab in Federation Services)

2) Configure Weblogic Federation Services by filling in SAML 2.0 General tab for the Service Provider server. In the case of OBIEE, this is bi_server1. The information entered here is given to partners through a metadata file and is used as a means to establish trust across servers.

ServiceProviderGeneralInfo


Couple of important notes here:

  • The Entity ID field value determines the name of this SAML server to its partners. If you have a cluster, make sure every member of the cluster is assigned the same value. An IdP will use this value to identify the Audience to which the SAML message is addressed. As any server in the cluster should be able to process the message. By the way, when configuring a cluster of SAML servers, make sure their configuration is exactly the same. Notice you can use Weblogic’s recording capabilities to save your actions into a script and replay that in the other servers using wlst.
  • The Published Site URL field value is the base URL for federation services on the server. For SAML2, make sure the webcontext path is saml2. This is going to be used in the metadata file as the prefix to build the ACS (Assertion Consumer Service) endpoint necessary for allowing an Identity Provider to properly communicate with this Service Provider. For example, an Identity Provider would be provided the following ACS endpoint is the above Published Site URL is specified:

IdP_ACS_Configuration

  • When OBIEE managed servers are in a cluster, there’s typically an HTTP load balancer in front of the servers. In such case, make sure the Published Site URL refers to the name and port of the load balancer, because they are the ones the IdP needs to know. And also, make sure the load balancer is configured for session affinity. Reason being the SP ACS is a stateless application, that upon creating a session, redirects the browser to the requested URL (/analytics). If that redirection hits a different server in the cluster, there’ll be no session there and the user will be sent back to the IdP who will ask for credentials again.
  • Also, when Weblogic SAML services are in a cluster, you must use RDBMS as Weblogic server security store to avoid synchronization issues of SAML data across servers. Such requirement is for SAML data only, it has nothing to do with application session management, which is configured on a per application basis. And RDBMS should be set as the security store from the ground up, when the domain is first created. Trying to change the security store from embedded LDAP to RDBMS is not recommended.

3) Enable BI managed server as a  SAML2.0 Service Provider.

EnablingServiceProvider


Important Note:

  • Default URL is invoked whenever a requester hit this Service Provider without an specific target service URL.

4) Export the SP configuration to a metadata file. Notice that any subsequent changes to your SP configuration will require a new export. Click Publish Metadata button in SAML 2.0 General tab and save it to a file. Examine the file contents. Notice the presence of an X509 certificate, to be used by the partner to encrypt data targeted to this Service Provider. Yes, the certificate is obtained from the Identity keystore configured for the server.

5) Get the IdP metadata file and import it as a Web SSO partner in the Management tab of SAML 2
Identity Asserter configuration. You should end up with something like this:

IdPmetadataImport

Click the partner name and edit the configuration:

IdPmetadataConfiguration


Important Notes:

  • Notice that Virtual User and Process Attributes are not checked. They only make sense if you can use a SAML Authenticator.
  • Redirect URIs are the set of URIs that when called trigger the SAML SSO mechanism. It is a must that they are also secured by the container, otherwise Weblogic won’t trigger the authentication process. Specifically, you must make sure that those mentioned applications use CLIENT-CERT as the auth-method in theirs web.xml.

2. Changing Analytics’ web.xml for security constraint and adding weblogic.xml for role assignments

As previously mentioned, Weblogic server must be able to trigger container authentication upon an unauthenticated request for a URI specified in the set of Redirect URIs defined in the Service Provider partner configuration. Analytics application already ships with CLIENT-CERT auth-method, which is what we want. However, it does not define any security constraints about which users should be allowed access to the application.

OOTB, OBIEE defines three groups: BIAdministrators, BIAuthors and BIConsumers, who are respectively assigned to three application roles in OPSS policy store: BiAdministrator, BIAuthor and BIConsumer. Each of these roles are obviously assigned distinct permissions across the system. Look at ${BI_DOMAIN}/config/fmwconfig/system-jazn-data.xml file in a default OBIEE installation for such definitions.

We need to grant those 3 groups access to the Analytics application in the standard JavaEE way, i.e., by adding a security-constraint to any resource under the analytics web context in web.xml. Additionally, we must map the role name in the security-constraint to those 3 groups in weblogic.xml.

You’ll need to “unjar” the analytics application, make the changes, “rejar” it and redeploy the application. You find the original ear file at ${BI_HOME}/bifoundation/jee/analytics.ear

In web.xml (add <security-constraints> and <security-role> elements):

<security-constraint>
  <web-resource-collection>

    <web-resource-name>BI Analytics</web-resource-name>
    <url-pattern>/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <role-name>allowedGroups</role-name>
  </auth-constraint>
</security-constraint>
<login-config>
  <auth-method>CLIENT-CERT</auth-method>
</login-config>
<security-role>
  <role-name>allowedGroups</role-name>
</security-role>

weblogic.xml (it has to be created in the same folder as web.xml):

<?xml version = ‘1.0’ encoding = ‘windows-1252’?>
<weblogic-web-app xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
         xsi:schemaLocation=“http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd”
         xmlns=“http://www.bea.com/ns/weblogic/weblogic-web-app”>
  <context-root>analytics</context-root>
  <security-role-assignment>
    <role-name>allowedGroups</role-name>
    <principal-name>BIAdministrators</principal-name>
    <principal-name>BIAuthors</principal-name>
    <principal-name>BIConsumers</principal-name>
  </security-role-assignment>
</weblogic-web-app>

Notice the <principal-name>s. They refer to the groups that OBIEE expect to find in the configured identity store. They are groups, not application roles. If you decide to change those names, make sure they match the application role assignments in the policy store.

If you want any existing user accessing the analytics application,  you can map allowedGroups role-name (defined in web.xml) to the users group (instead of BIAdministrators, BIAuthors and BIConsumers) in weblogic.xml. In Weblogic, any authenticated user is automatically assigned to the users group.

3. Configuring OBIEE for SSO in Enterprise Manager

There’s still one more configuration for SSO in OBIEE. In Enterprise Manager, enable SSO and set the provider to “Generic SSO” for OBIEE’s coreapplication, as shown:

SSOEnabling_EM

The screen is reachable via clicking the “coreapplication” link on the left and then selecting “Security” from the “Business Intelligence Instance” drop down menu on the right.

4. Configuring the Identity Provider

Configuration of the IdP is straightforward, very similar to SP’s. Here, we create a SAML2CredentialMapper, enable the server as an IdP and import the SP metadata to the credential mapper configuration.

1) Add a SAML2CredentialMapper to the list of Credential Providers and restart the Admin server.

IdPCredentialProviders

2) Fill in IdP’s General Info tab.

IdP_GeneralInfo

3) Enable the server as an IdP.

IdP_Enabling

4) Get the metadata file exported from the SP and import it as an IdP partner in the SAML2CredentialMapper configuration.

IdP_Partner

Hope this can be useful to someone out there. Lots to digest, I agree. 🙂

Configuring the iPlanet as web tier for Oracle WebCenter Content (UCM)

If you are looking for configure the iPlanet as Web server/proxy to use with
the Oracle WebCenter Content, you probably won’t found an specific documentation
for that or will found some old complex notes related to the old 10gR3.

This post will help you out with few simple steps.

That’s the diagram of the test scenario, considering that you will deploy in
production in an cluster environment.

Sample-iPlanet-wcC-topology

 

Cloning a WebCenter Portal Managed Server

Sometimes you need to create a new WebCenter Portal managed server, be it to have another development or test instance, or to add a new node to a cluster; Often times you do this manually, but there’s a hidden gem in the WebCenter WLST commands: you can actually clone an existing instance and have it up and running in a couple of minutes! Hit the jump if you want to know more.

Where and How to Set JVM Parameters in Oracle SOA 11G

Let’s say you experience some performance issues of your Oracle SOA 11G servers, and after some research you know that you need to tune your JVM heap size, and turn on some JVM debugging to monitor such as Garbage Collection behaviour. After some due d…

Domain Architecture and Middleware Homes Revisited

Over a year ago I wrote a couple important posts about the domain architectures used in Oracle Identity Management deployments.  You can find these posts here and here.
These posts have been very popular.  I’ve received lots of positive feedback on them but also a fair number of questions.  So, I thought that it would be worth revisiting the topic now.

 Let’s Review My First Post

So, the central premise of my first post was that it is a good idea to install products from different distribution packages into different WebLogic domains.  Specifically, I am recommending that customers install the IAM package (OAM,OIM,OAAM) into a separate domain from the IDM package (OID,OVD,OIF).   Same thing goes with products from either package and WebCenter or SOA suite. 
The reason is that it introduces the risk that different components (libraries, jars, utilities), including custom plug-ins, from the different packages that you are installing in the domain might be incompatible and cause problems across your entire domain.
Beyond the risk of such an incompatibility, you also must consider how installing multiple packages into one domain reduces your flexibility to apply patches and upgrades.
The exception to this warning is SOA Suite for OIM. SOA Suite is a prerequisite for OIM and as part of the stack that supports OIM should be installed in the same domain as OIM. However, if you use SOA suite for other purposes, you should consider setting up a separate install for running your own services, composites, BPEL processes etc.
Let’s Review My Second Post
In my second post I discussed whether or not to split up products from the same package into multiple domains.  I argued that while the incompatibility issue isn’t such a big deal but that the additional flexibility of deploying in different domains could still be beneficial.  I did warn though that OIM/OAM/OAAM integration is only supported with all the software running in the same domain.
Advice Revisited
A year and a half later, I still strongly stand by the advice in my posts.  I’ll put it this way, I’ve worked with people who regret deploying multiple packages into one domain for all the reasons I mentioned but all the people I’ve worked with who have gone with a split domain model across packages have been happy and glad they’ve gone that route.
That being said, there are a few clarifications and updates to my advice that I’d like to now make.
It’s About Middleware Homes (Install Locations) Not Just Domains
One thing that I want to make clear is that my advice about separating the products from different packages extends beyond domains to Middleware Homes which are the root directories for the Middleware products that you are installing together.  To avoid the conflicts and restrictions that you can run into by installing multiple packages together you need to install them in separate Middleware Homes, just separate domains is not enough.  It is true that most people just create one domain per Middleware Home but I’ve seen some examples of multiple domains in a Middleware Home recently so I thought this was definitely worth mentioning.
Domain Architecture for OAM/OIM Integration
The limitation that you have to put OAM and OIM in the same domain if you want the integration to work has, shall we say softened.  I would still say putting them in the same domain is the easiest and most tried and true path (the yellow brick road if you will).  However, if you utilize a real OHS based OAM agent rather than the domain agent; you can make the integration work with OAM and OIM in separate domains.  In fact, the most recent IDM EDG for FA includes this option.
Fusion Applications
Speaking of Fusion Apps, I do want to discuss this advice in the context of Fusion Apps.  As I describe here, the IDM build out for Fusion Apps is prescribed very specific process with a specific architecture.  It is very likely you will run into issues deploying Fusion Apps on top of an IDM environment that deviates from this architecture as FA has made certain assumptions about how the IDM environment will be set up.
In the context of the domain discussion, the IDM EDG for FA does steer you down the path of creating one big IDM domain that contains OID, OVD, OAM, OIM, ODSM, and potentially OIF.  This is of course contrary to the advice I’ve been giving.  In the context of FA though I think this is OK.
When using the IDM products with FA you are restricted to very specific versions of the IDM products in the stack, so upgrade flexibility and incompatibility concerns isn’t really an issue.  Also, as I said, the FA provisioning process may be expecting the Oracle IDM/IAM products to be deployed in a single domain.  So, for FA I advice people to follow the EDG and stick with the single domain model or moving forward whatever models are documented in the IDM EDG for FA.

SSL offloading and WebLogic server redux – client x.509 certificates

I recently had to revisit the subject of SSL offloading and WebLogic server to include the ability to do client certificate authentication. I was specifically doing this for use with Oracle Access Manager 11g, but the configuration steps are identical …

WebLogic 12c Released

Just a quick post the let you all know that WebLogic Server 12c is now generally available and can be downloaded from OTN.
 

Change WebLogic Server Mode from Development to Production and JDK Mode from Client to Server

What does it take to change WebLogic 10.3.x server mode from development to production?

You quickly search on the Internet and quickly land to documentation such as here: http://docs.oracle.com/cd/E21764_01/apirefs.1111/e13952/taskhelp/domainconfig/ChangeRuntimeModes.html . The doc says you just need to go to the WebLogic Console to do it. That is easy, right?

But then the next link or so you may found a blog like http://blogs.oracle.com/learnwithpavan/entry/run_weblogic_in_production_mod , which says you need to set some Java parameter to make that happen.

So, which one is right?

Well, the truth of the matter is, to completely change a server from Development to Production Mode, two things need to happen:

  1. From Console -> Domain -> Production mode, check the Production Mode check box. This change will go into config.xml
  2. In setDomainEnv.sh, set PRODUCTION_MODE=true.

You will notice that if you only do #1, the Java will still start with “-client” option. Only when both of these settings are done, the server will start with ‘-server’ in its Java command line.

For differences between Development mode and Production mode, please refer to http://docs.oracle.com/cd/E21764_01/web.1111/e13814/wls_tuning.htm#i1111053 for details.