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. […]

Configuring Oracle Public Cloud to Federate with Microsoft Azure Active Directory

Introduction Companies usually have some Identity and Access Management solution deployed on premises to manage users and roles to secure access to their corporate applications. As business move to the cloud, companies will, most likely, want to leverage the investment already made into such IAM solutions and integrate them with the new SaaS or PaaS applications that […]

Adding Oracle Identity Federation to an Existing Fusion Applications Deployment Part 1

Introduction This guide is meant for existing FA customers who have deployed FA without OIF and who now wish to add this security component to the deployment to provide federated SSO to FA. Customers who have not yet begun their deployment can and should follow the Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Identity […]

Adding Oracle Identity Federation to an Existing Fusion Applications Deployment Part 2

Introduction This is the second part of a two-part article. Click here to view Part 1. This guide is meant for existing FA customers who have deployed FA without OIF and who now wish to add this security component to the deployment to provide federated SSO to FA. Customers who have not yet begun their deployment […]

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. 🙂

Unsolicited login with OAM 11g

In a previous post I talked a little about protecting only a part of an application with OAM. I included this bit of text describing the use case: But what if you want to let users access part of the app anonymously, but require them to log in to acce…

OAM 11g Single Sign-On and OAM 10g Cookies

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

In an earlier post I talked about how cookies work when you’re using OAM 11g server with OAM 11g WebGates. But the OAM 11g server also works with OAM 10g WebGates and there are reasons you’d deploy 10g WebGates today. But OAM 11g and 10g have fundamentally different behavior when it comes to the cookies.

So how do cookies work when you’re using 10g WebGates with the 11g server?

In short they work pretty much the same way. Or at least they can work nearly the same way with 10g WebGates as they do with 11g WebGates.

I setup an environment with two servers – alpha and linux.ktest.oracleateam.com. Alpha is an IIS server with an OAM 10g WebGate and one protected directory which I cleverly named /protected/. The other machine (linux.ktest.oracleateam.com) is, as you’ve guessed, a Linux box with the OAM server installed. I’d include a diagram, but it looks exactly the same as the diagram in the older post.

Here’s what the HTTP traffic looks like when I try to access http://alpha/protected/:



GET /protected/ HTTP/1.1
Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Accept-Encoding: gzip, deflate
Host: alpha
Connection: Keep-Alive

HTTP/1.1 302 Redirect
Content-Length: 0
Location: http://linux.ktest.oracleateam.com:14100/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Server: Microsoft-IIS/7.5
Set-Cookie: ObSSOCookie=loggedoutcontinue; httponly; path=/
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2012 16:14:16 GMT

GET /oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F HTTP/1.1
Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Accept-Encoding: gzip, deflate
Host: linux.ktest.oracleateam.com:14100
Connection: Keep-Alive

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Date: Fri, 09 Mar 2012 16:16:55 GMT
Pragma: no-cache
Content-Length: 3326
Content-Type: text/html; charset=UTF-8
Expires: 0
Set-Cookie: OAM_REQ=VERSION_4~KJTasxCSm1Z1LVGtpMwu5nJ3cwSYLNx1TGFLYN7tRq3Jr1Pin693MMCJJHQ6bPQL1vSxK3En%2bFaQPCNevV3Idi1o07xN9LjfFWubXf4B98yXOGRH6fT7RaZjp2dfPyqCADEG022AZg7xWsrCjff848vcqwAzLXs2schaae8z7YLXxCNVoMUGMsHFahTPkuq31ZIaqK8lZq7glReQuZyiBGXWPr5EptvGcbWEe0X9iOoeiUGFoJt6LpOCz79%2fJPpURizXOCQej3M3eCpGw8QmzUGa5ajAsPu5M0KZPViBubQwM9dsePRYNYaFizHYla8%2ftYr%2fHpgxkNLmuZ3crkzSZES45dnWdaqZBPbAcZb9S8pdGsjxMiB18bcudXC5A4DXnPwYLu92RQKrtHHgiq1JYIfMz4ZsCK5Fks%2bH3waTnw4Ec9V6EFvWF2rHXeGjqsHNN3jdZDtUlRkYcgBffUpBVkd%2fppwds%2fRcS4RVie39kRqduhbS1qphdGdy6pH8cX%2f8LEn3QoR2GXcn8cxgDEtfTR4q2JvrhbSnSChrqX967ogq8b%2bi0HEzDwFkYbhuZudsCXRHPVeOjGe78SY5IumWqCBIxW0z9LiSOhmcBDbagRFByhcTMpHZPU%2fxJxL7vdqllS8BwRPeVZuI0yuGstbBxVgWMzPJD%2bahnJXwlNODHEBCuMtYyO7gTol9VqpJo2l40PUgQUkmtw3cNf%2btazp5uTY%2fy8MG9AAyTNMTlgvaSnNTe0fwxiVMVcjuIqYUl%2fhSy%2fh1Z0lodn0w6HZQoiIyYMiEA%2felDR38iBKP4%2b14IvKroONAhuX0Ly4XSNRqGbzKyt%2fmqkc%2bguL2OPAIFjeBGMuses6r5Ml%2fepyF%2f%2bqnXTBB%2bFweBmaxHdv1uU58kWwtTfkWJwEuALDJhAXG7ixRnkHISfizpkPKGTs5jAGDj8Lhcndl1IAKbekDS5d6g2zxSpl4RDGmZuWcVG2G8XSyBs5D317CWvx1Mq3SDZhcvGy7RscDcqy7ra66j1uS49QaKvAgdGA03RzwAfCLMD4wNnj06aAkh9BXTDv%2bgHYzCaWpXm8yjMAVPr9fhXzn3Nro3ffM8I%2bEdFq2lRLdFIo04Gc4o%2f7lS0dGZKS6%2fyB5UKCtmD%2fihmsHdCVFUcRCMdff21HGT%2f8y0j6yQHNf4X1RefEdYcjbYOEv%2bbm1Jq5zcat60maesmmiBl5n6LJFYSfG6QLs4wLqZjqEXPWU96JBQuFwDjf7ux4RTcmnLG3LbU3M6lUPqfB0k8TGee7XbtaW0Z%2b69CIsYElY1ftvszOT2uMw2yAjy8nvs7iIJVvXGb0yX57h77WiySby6ISqvIH1maMdzr6jIAL76ImMc%2bCVJzJvt4WgobY6nc4OH4MSPMg%3d; path=/; HttpOnly
X-ORACLE-DMS-ECID: bc0b467a62ba363a:-50e866c2:135cc4d3539:-8000-0000000000000ab5
X-Powered-By: Servlet/2.5 JSP/2.1

As is the case with 11g WebGates the WebGate redirects me over to the OAM server to see if I have an existing session. And since I haven’t logged on yet I don’t have a session or associated cookie. So OAM sends me off to the login page.

So far this looks remarkably like the 11g WebGate. And by “remarkably like” I mean exactly the same as!

At this point I’m staring at the login page so let me enter the username and password and POST them to the credential collector:


POST /oam/server/auth_cred_submit HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://linux.ktest.oracleateam.com:14100/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: linux.ktest.oracleateam.com:14100
Content-Length: 67
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: OAM_REQ=VERSION_4~KJTasxCSm1Z1LVGtpMwu5nJ3cwSYLNx1TGFLYN7tRq3Jr1Pin693MMCJJHQ6bPQL1vSxK3En%2bFaQPCNevV3Idi1o07xN9LjfFWubXf4B98yXOGRH6fT7RaZjp2dfPyqCADEG022AZg7xWsrCjff848vcqwAzLXs2schaae8z7YLXxCNVoMUGMsHFahTPkuq31ZIaqK8lZq7glReQuZyiBGXWPr5EptvGcbWEe0X9iOoeiUGFoJt6LpOCz79%2fJPpURizXOCQej3M3eCpGw8QmzUGa5ajAsPu5M0KZPViBubQwM9dsePRYNYaFizHYla8%2ftYr%2fHpgxkNLmuZ3crkzSZES45dnWdaqZBPbAcZb9S8pdGsjxMiB18bcudXC5A4DXnPwYLu92RQKrtHHgiq1JYIfMz4ZsCK5Fks%2bH3waTnw4Ec9V6EFvWF2rHXeGjqsHNN3jdZDtUlRkYcgBffUpBVkd%2fppwds%2fRcS4RVie39kRqduhbS1qphdGdy6pH8cX%2f8LEn3QoR2GXcn8cxgDEtfTR4q2JvrhbSnSChrqX967ogq8b%2bi0HEzDwFkYbhuZudsCXRHPVeOjGe78SY5IumWqCBIxW0z9LiSOhmcBDbagRFByhcTMpHZPU%2fxJxL7vdqllS8BwRPeVZuI0yuGstbBxVgWMzPJD%2bahnJXwlNODHEBCuMtYyO7gTol9VqpJo2l40PUgQUkmtw3cNf%2btazp5uTY%2fy8MG9AAyTNMTlgvaSnNTe0fwxiVMVcjuIqYUl%2fhSy%2fh1Z0lodn0w6HZQoiIyYMiEA%2felDR38iBKP4%2b14IvKroONAhuX0Ly4XSNRqGbzKyt%2fmqkc%2bguL2OPAIFjeBGMuses6r5Ml%2fepyF%2f%2bqnXTBB%2bFweBmaxHdv1uU58kWwtTfkWJwEuALDJhAXG7ixRnkHISfizpkPKGTs5jAGDj8Lhcndl1IAKbekDS5d6g2zxSpl4RDGmZuWcVG2G8XSyBs5D317CWvx1Mq3SDZhcvGy7RscDcqy7ra66j1uS49QaKvAgdGA03RzwAfCLMD4wNnj06aAkh9BXTDv%2bgHYzCaWpXm8yjMAVPr9fhXzn3Nro3ffM8I%2bEdFq2lRLdFIo04Gc4o%2f7lS0dGZKS6%2fyB5UKCtmD%2fihmsHdCVFUcRCMdff21HGT%2f8y0j6yQHNf4X1RefEdYcjbYOEv%2bbm1Jq5zcat60maesmmiBl5n6LJFYSfG6QLs4wLqZjqEXPWU96JBQuFwDjf7ux4RTcmnLG3LbU3M6lUPqfB0k8TGee7XbtaW0Z%2b69CIsYElY1ftvszOT2uMw2yAjy8nvs7iIJVvXGb0yX57h77WiySby6ISqvIH1maMdzr6jIAL76ImMc%2bCVJzJvt4WgobY6nc4OH4MSPMg%3d

username=weblogic&password=ABcd1234&request_id=-8330979068306697433

HTTP/1.1 302 Moved Temporarily
Connection: close
Date: Fri, 09 Mar 2012 16:17:01 GMT
Transfer-Encoding: chunked
Location: http://alpha/obrar.cgi?cookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D%20redirectto=%252Fprotected%252F%20ssoCookie=httponly
Set-Cookie: OAM_ID=VERSION_4~C7Iz5I0rodPWWPLR82CoQg==~bP8dGW/YVqe1NaHiCaZ3z6p2dbxVbpJpcSYMU6LVzUSBHp0C9OtSKbtvUlHHDsGImCi8KtAh3CLHXN+paF2+ZyxNOZOge2Mg2aH6vF8Wy2fUgIEYAVYjtVrP4bVTC0GpM7S6dt3XpjR/AHScYUdQNp5Olr5D3gSlBAnXWcyYxY9u/x620d5LHIYvBdZvqZzVsfAAV/5KovBKD/5wvhPWI/JDkYoUdT37VoaDp7BS1lOumUtTqzXkQTzMzAkLCzhS0M1NyCYTiT9904bIxfzhJw==; path=/; HttpOnly
Set-Cookie: OAM_REQ=invalid; path=/; HttpOnly
X-ORACLE-DMS-ECID: bc0b467a62ba363a:-50e866c2:135cc4d3539:-8000-0000000000000ab7
X-Powered-By: Servlet/2.5 JSP/2.1

Not terribly surprisingly I get an OAM_ID cookie and a redirect back to the protected resource, again just like with the 11g WebGate.

So we’re on our way back to the WebGate to a fake resource called obrar.cgi with some encrypted data in the query string (yes, oddly familiar!).

The browser does the HTTP GET there…


GET /obrar.cgi?cookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D%20redirectto=%252Fprotected%252F%20ssoCookie=httponly HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://linux.ktest.oracleateam.com:14100/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Cookie: ObSSOCookie=loggedoutcontinue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cache-Control: no-cache
Host: alpha

HTTP/1.1 302 Redirect
Content-Length: 0
Location: /protected/
Server: Microsoft-IIS/7.5
Set-Cookie: ObSSOCookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D;httponly; path=/
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2012 16:14:22 GMT

Ah! There it is – the first real difference between OAM 11g and OAM 10g WebGates behavior. With the 10g WebGate I get a good old ObSSOCookie instead of a 11g’s uniquely named cookie.

I also got and a redirect back to the original resource, which I then retrieve:


GET /protected/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://linux.ktest.oracleateam.com:14100/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Cookie: ObSSOCookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cache-Control: no-cache
Host: alpha

HTTP/1.1 200 OK
Cache-Control: no-cache,private
Pragma: no-cache
Content-Type: text/html
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2012 16:14:22 GMT
Content-Length: 2495

As with the 11g WebGate you probably noticed that there’s no domain= parameter on the cookie. Which means that this ObSSOCookie is specific to the one WebGate. But wait, didn’t OAM 10g WebGates use a domain-wide cookie?

Yes they did. And 10g WebGates still do if (and only if) that’s what you want.

Here’s my configuration settings for my 10g WebGate:

In my case I left out the cookie domain setting for the WebGate. And by doing that I told the WebGate to act like the 11g WebGate and use “host only” cookies.

Filling in that setting changes the behavior. For new deployments of OAM 11g with 10g WebGates I generally would recommend leaving the setting blank because it solves a number of problems with cookies in larger deployments of OAM. But I’m going to put off discussing those problems until a later post.

5 Minutes or Less: WLS SAML2 SSO and your cookies

This is somewhat related to what Brian describes in WLS Session Cookie Overriding in an OAM/SSO Enabled Environment. Here, I want to quickly point one potential issue if you plan to implement Web SSO using Weblogic server as a SAML2.0 Service Provider (SP).

When configuring a Weblogic server instance for SAML2.0 services, you have to fill in a property called “Published Site URL”.

ServiceProviderGeneralInfo

When this instance is an SP, this property tell the partner IdP (Identity Provider) where to post SAML Responses to. In the case of SAML2.0, that URL must be http://<server>:<port>/saml2, where <server> and <port> must refer to how the IdP recognizes the SP. In other words, if you have something like a load balancer in front of Weblogic server (which is the case if you’re running a cluster), <server> and <port> would be the load balancer’s. “saml2” is the web context of Weblogic’s internal SAML2.0 servlet, whose fully qualified name is com.bea.security.saml2.servlet.SAML2Servlet.

Very well, this servlet, when called as a Service Provider, has the ability to consume a SAML assertion created by the partner IdP and instantiate an HTTP session for the browser session in the server. And it will tie it to the browser session by issuing a cookie named JSESSIONID whose cookie-path is set to “/”.  So what?

It turns out that many applications specify their own cookie-path to avoid the problem of JSESSIONID clashing, where last accessed applications by the browser override the JSESSIONID cookie value during the same browser session, thus leaving orphaned HTTP sessions in the server.

It also turns out that other applications use a different cookie name to avoid the same problem.

In both cases, the JSESSIONID cookie issued by saml2 servlet won’t be accepted by the application. You may be prompted for authentication again (this time by the application), get an HTTP 401-Unauthorized error or get into an infinite loop of redirects between SP and IdP.

The most obvious solutions to these problems is removing the cookie-path constraint from the application (in which case it defaults to “/”) and having the application using the JSESSIONID name. You may need to get the blessings of your application provider for supportability purposes before proceeding to the changes.

That said, get to know your applications’ cookies (cookie-name and cookie-path) before integrating them into WLS SAML2 SSO.

OBIEE 10g SSO Integration with OAM 11g

In this post I share the necessary steps in order to integrate OBIEE 10g into OAM 11g Single Sign On with the little caveat that OBIEE Analytics application is deployed in Weblogic server.

OBIEE 10g has two installation modes: basic and advanced. For SSO integration, you must pick adavanced mode. And Oracle Application Server version 10.1.3.1.0 or later is required.

OBIEE 10g deployment guide states that it can be implemented with any SSO solution that uses cookies, http header variables or JavaEE container server variables. That’s true indeed, and most of the configuration is actually performed on the OBIEE side.

OBIEE 10g implements SSO through the concept of impersonation. It retrieves the end user identity through one of the mechanisms mentioned above and uses an impersonator user to establish a session to the OBIEE server on behalf of the end user.

This post by no means intends to discuss OBIEE architecture or go into the details of OAM 11g. As a matter of fact, the latter is extensively discussed in this blog by my colleagues in the Oracle Access Manager Academy series. Reading strongly recommended. Fantastic material.

And what you’re about to follow has been implemented in a Windows XP box for demonstration purposes.

The exact product versions used were:

Oracle Business Intelligence Enterprise Edition 10.1.3.4.1
Oracle Identity and Access Management 11.1.1.3.0
Oracle Access Manager WebGates 11.1.1.3.0
Oracle Identity Management 11.1.1.3.0
Oracle WebTier Utilities 11.1.1.2.0
Oracle Weblogic Server 10.3.4
Oracle Containers For Java (OC4J) 10.1.3.5.0

Fasten your seat belts! Here we go.

1 – Install OBIEE 10g

When you install OBIEE 10g, you get a set of standalone component processes, some admin UIs and a front-end web application running on top of OC4J.

For the purposes of this post, we’re interested in the BI Server, BI Presentation Services and the BI Presentation Services Plug-in components. The BI Server is a standalone process that maintains the BI data model and connects to data stores. BI Presentation Services is another standalone process that present information worked by BI Server to clients via ODBC. BI Presentation Services Plug-in allows web clients to interact with BI Presentation Services. In JavaEE application servers, it is a servlet component delivered via the analytics.war web application.

Once OBIEE is installed, find the analytics.war file under $BI_HOME/web folder.

Shut down OC4J in case it’s running. We don’t need it.

2 – Deploy the analytics.war application in WebLogic

Simply use Weblogic console to deploy the analytics.war application. There really is nothing special here. Click click click and you should get the analytics application up and running in Weblogic.

3 – Install Oracle HTTP Server (OHS)

OHS front-ends Weblogic server. A mod weblogic routing rule will forward requests to the analytics application running in Weblogic.

4 – Create routing rule in OHS mod weblogic for /analytics URL

This step can also be accomplished via Enterprise Manager.
Open mod_wl_ohs.conf located under your OHS instance home config folder and type in the following:

   1: <IfModule weblogic_module>
   2:  WebLogicHost <!--weblogic-server-running-analytics-application-->
   3:  WebLogicPort <!--weblogic-port-->
   4:  Debug ON
   5:  WLLogFile /tmp/weblogic.log
   6: </IfModule>
   7:  
   8: <Location /analytics>
   9:  SetHandler weblogic-handler
  10: </Location>

 

Make sure to replace the values in between <!– –>

The OHS instance home config folder is typically located at $ORACLE_HOME/instances/<instance-name>/config/OHS/ohs1

Restart OHS.

Checkpoint 1: at this point we should be able to submit requests to OHS and have them directed to Weblogic.

5 – Install OAM 11g

Nothing special here. Just follow OAM 11g install guide. It is a good idea to create one Weblogic domain along with one managed server for the OAM server.

6 – Install OAM 11g WebGate in OHS

The WebGate checks whether the executing user is authenticated before letting it access the analytics application.

7 – Register the WebGate in OAM Console

Simply follow OAM Administration Guide Instructions.

Here’s my WebGate definition:

WebGate

On registration, by default, you get an application domain and Authentication and Authorization policies automatically configured for the patterns / and /…/*. You don’t need those policies. Remove them and add the /analytics/…/* as a protected resource to the set of Authentication and Authorization policies.

AuthenticationPolicy

And make sure you copy the generated ObAccessConfig.xml and cwallet.sso from the OAM’s $DOMAIN_HOME/output/<agent-name> to the WebGate’s instance config folder, which is typically located at OHS’ $ORACLE_HOME/instances/<instance-name>/config/OHS/ohs1/webgate/config.

<agent-name> is the name you gave to your WebGate when you registered it in the OAM Console.

Restart both OAM access server and the WebGate.

Checkpoint 2: At this point we should be able to have the WebGate intercepting calls to /analytics URL running in WebLogic and asking for credentials. Upon entering them, the user would be re-challenged by BI login screen.

8 – Create Impersonator user for the BI Server

Connect to the BI Administrator tool and select Manage –> Security.

Select User, right click on the panel’s right side, select New User… and type in the user name. For this exercise, I am calling it Impersonator. Make sure it is a member of the Administrators group.

9 – Add Impersonator user to BI Presentation Services credential store (credentialstore.xml)

Navigate to BI’s home web/bin folder and type:

> cryptotools credstore–add–infile <OracleBIData>/web/config/credentialstore.xml

 

You are prompted for some information. Make sure the Credential Alias is impersonation (literally). Username and password should obviously match those you just provided in the previous step. Encrypt the password and give it a passphrase.

10 – Configure instanceconfig.xml

instanceconfig.xml is also located at <OracleBIData>/web/config.

In my case, <OracleBIData> is C:\OracleBIData.

In order to allow BI Presentation Services connecting to BI Server using the Impersonator user, add the following snippet as a child of <ServerInstance> element:

<CredentialStore>
<CredentialStorage 
type="file" 
path="C:\OracleBIData\web\config\credentialstore.xml" 
passphrase="welcome1"/>
</CredentialStore>

 

Make sure to enter the passphrase you chose previously.

In order to allow BI Presentation Services consuming the end user identity authenticated by OAM, add the following as a child of <ServerInstance> element as well:

<Auth>
<SSO enabled="true">
<ParamList>
<Param 
name="IMPERSONATE" 
source="httpHeader" 
nameInSource="OAM_REMOTE_USER"/>
</ParamList>
</SSO>
</Auth>

Here we’re instructing BI Presentation Services to use the OAM_REMOTE_USER http header value as the “impersonatee” user. OMA_REMOTE_USER is always put in the HTTP header by OAM upon successful authentication. BI will simply trust that. Dangerous? Oh yes.

Don NOT go to production without implementing a trusting mechanism between Weblogic and OHS. Weblogic should only accept requests from OHS. And the solutions to the rescue are 2-way SSL or some firewalling protecting Weblogic. Don’t let anyone sending requests directly to Weblogic!

Restart BI Server and BI Presentation Services processes.

Checkpoint 3: At this point SSO should work for /analytics. After getting challenged by OAM on accessing /analytics/saw.dll?Dashboard, you should be let in without any further authentication challenge by BI.

Notice that we still have two user repositories. OAM is looking at the Weblogic embedded LDAP server while BI is looking at its internal repository. That assumes the user is defined in both identity stores.

OBIEE 10g has the option of importing users and groups to its internal repository from external systems. That’s certainly an option, but it involves synchronization, which I am not a great fan of. Import and synchronization are available in the BI Administration tool.

If you seek a single identity store, keep reading.

11 – Define a new OID identity store in OAM

This step assumes OID has been previously installed. In this exercise, OID version is the one packaged in Oracle Identity Management 11.1.1.3.0.
The application policy domain created when we registered our WebGate uses Weblogic embedded LDAP server as the identity store by default.

We need to change it, by pointing it to an external LDAP server. OID being the choice here.

This is done in OAM console. On the System Configuration tab, expand the Data Sources node and select User Identity Stores. Click the New button on the tool bar. Here’s my definition:

identityStore

Then associate this identity store to the authentication scheme that is associated with the authentication policy protecting the /analytics/…/* pattern. This is done under Authentication Modules node on the System Configuration tab:

authenticationModule

LDAP is the authentication module defined for the authentication scheme protecting our /analytics/…/* pattern.

Restart OAM server.

12 – Create an LDAP server in BI Server (the same OID identity store above)

Using BI Administration tool, define the LDAP server. Go to Manage –> Security –> New… –> LDAP Server

BI_LDAP_Server

Click the Advanced tab and inform uid as the User name attribute type. uid is the attribute that univocally identifies the user in OID.

BI_LDAP_Server_Advanced

13 – Create a USER session variable in BI Server.

* Defining a USER session variable tells BI Server to authenticate users in an external repository. But in case of conflicting usernames, users defined in the BI repository takes precedence.

Using the BI Administration tool, go to Manage –> Variables. On the left side panel, under Session, select System. Right click on the right side and pick New USER…

14 – Create an LDAP Initialization Block for authenticating users in OID.

Initialization blocks are the means by which external repository data is communicated to BI server.

Again, using BI Administration tool, go to Manage –> Variables. Click Session. Right click on the right side and pick New Initialization Block… Give it a name, like Authentication Block.

Under Data Source, click Edit Data Source… button, pick LDAP as the type, click Browse button and pick the LDAP server you’ve defined previously.

Under Variable Target, pick the USER variable you’ve created. Inform uid as the LDAP Variable value.

You should end up with something like this:

BI_InitBlock

Restart BI Server.

Checkpoint 4: at this point, you should be able to login with a user defined in OID and access the BI analytics application in SSO mode, but you’ll notice that the privileges within BI analytics look wrong.

15 – Implementing authorizations for BI using groups defined in an external LDAP server.

Unfortunately, OBIEE 10g does not retrieve group memberships directly from LDAP. But it is possible to implement it indirectly, by creating a virtual table in the Oracle database populated with LDAP user/group information (that can be done with DBMS_LDAP package).

Another option would be writing a SQL query directly against OID tables, but that’s too invasive and could break at any time due to changes in the OID schema, which is private.

Once you populate a table using DBMS_LDAP package, you can query it via a second Initialization Block and retrieve the group names for a given user, populating the GROUP session variable. This block should refer the Authentication initialization block we’ve defined earlier as a predecessor so that the USER variable is properly initialized with the authenticated user.

I am not done with this part yet. As time permits, I will come back with the virtual table definition as well as the initialization block.
But I guess there’s already plenty to do in case you want to try this out. Let me know about your experiences.

For more details…

Refer to product documentation.

OBIEE 10g Documentation Library (Deployment Guide has most of the information presented here).

OAM 11g Administration Guide

WLS Session Cookie Overriding in an OAM/SSO Enabled Environment

First I’d like to remind everybody about the Identity Management 11g launch that is coming up. You can register for it here.

 

With that out of the way, today I’d like to conclude my series of posts on user session management in OAM/SSO enabled environments by talking in detail about the issue of WLS session cookie overriding.

The Problem

To review, if OAM is protecting multiple containers or applications that by default issue session cookies with the same name then it is important to realize that as a user moves from one container/application to another that the session cookie of the 2nd container/application will blow away the session cookie from the first container/application.

An example of this is OAM protecting multiple WebLogic applications that are not sharing a session. The JSESSIONID cookie issued when a user accesses a second application will blow away the JSESSIONID from the first application.

Now, what you usually see in such a setup is that the user can go back and access the first application without having to login again. However, underneath the covers they will be issued a new session. So, upon returning to the first application, any data associated with their original session will be lost and the application flow may be disrupted or different from the expected behavior.

Solutions

As far as I know there are 3 possible solutions to this issue:

  1. Enable session sharing between your WLS applications.
  2. Configure distinct WLS session cookie names (instead of JSESSIONID) for each application so that they won’t override each other.
  3. Configure distinct cookie paths for each application (by default the JSESSIONID created by WLS has a path of “/”) so that they won’t override each other.

None of these solutions is perfect, so we’ll now go through and discuss the advantages, disadvantages, and limitations of all 3.

Session Sharing

By default, applications do not share the same WLS session. However, for applications deployed in the same EAR, it is pretty easy to set it up so that they do share the user session. The main limitation here is that the applications have to be deployed in the same EAR.

To enable session sharing between applications in an EAR, set the sharing-enabled attribute in the session descriptor to true in the weblogic-application.xml.

Changing the Session Cookie Name

Going the route of giving unique names to the session cookie for each application is a solid solution and realistic solution to the session cookie overriding problem. However, there are a few draw backs that I’ll get to.

First, let’s talk about how to change the WLS session cookie names. On the application side, you set the cookie-name deployment descriptor variable in the weblogic.xml. If you are fronting WebLogic with a real web server, you’ll need to configure the mod_wl connector “routing rules” with the appropriate cookie name to be used for each application. Specifically with regard to OHS/Apache and mod_wl_ohs, the appropriate directive is WLCookieName. The following is an example mod_wl_ohs configuration using this directive:

Sample mod_wl (httpd.conf/mod_wl.conf) configuration

#### /AppA

SetHandler weblogic-handler
WebLogicHost test_server1
WebLogicPort 7001
WLCookieName cookie1
DynamicServerList OFF
Debug ALL
WLLogFile logs/httpd_proxy1.log

#### /AppB

SetHandler weblogic-handler
WebLogicHost test_server2
WebLogicPort 7001
WLCookieName cookie2
DynamicServerList OFF
Debug ALL
WLLogFile logs/httpd_proxy1.log

#### /AppC

SetHandler weblogic-handler
WebLogicCluster machine_1:7001,machine_2:7001
WLCookieName cookie3
Debug ALL
WLLogFile logs/httpd_proxy1.log

As you can see this does complicate your mod_wl configuration some in that you have to isolate the context-root of every application that is to have a unique cookie. You’ll also have to then distribute updates to every http server in your deployment. One other issue you might encounter with this solution is that you might have infrastructure software like monitoring software that is hard coded or pre-configured to look specifically for JSESSIONID. If you change the name of the session cookie your monitoring may break. Finally, some black box commercial applications that run on WebLogic cannot be changed to use alternative cookie names.

Changing Session Cookie Paths

Setting the “cookie path” of the session cookie for each application to the context root of the application allows you to maintain separate WLS session cookies for each application without having the cookies for different applications overwriting each other.
To implement this you simply need to set the cookie-path deployment descriptor variable in the weblogic.xml. One advantage to this approach is there are no required configuration changes on the web server / mod_wl side of things.

On the downside, the problem of black box applications running on WLS is arguably worse with the unique path solution than with the unique name solution. Just like with the cookie name, some black box commercial application that run on WebLogic cannot be changed to use different cookie paths and most of these have hard coded cookie paths set to “/”. In such situations these black box applications will not only interfere with each other, but you also will get conflicts between the black box applications and your custom applications for which you are properly setting the paths to the context root. From my little bit of testing of browser behavior it seems that the more specific path always wins so it seems it is mainly an issue of the session cookies for the black box apps being overwritten by your applications session cookies. In any case, it is definitely something to be aware of.

Conclusion

WLS Session Cookie Overriding is a common problem in an OAM/SSO enabled environment. There are 3 possible solutions to the problem: session sharing, application unique session cookie names, and application unique cookie paths.

However, all 3 solutions have their limitations.

Oracle Access Manager (OAM) and the SSO Synchronization Filter

A while back I wrote about some challenges concerning session management in an OAM/SSO enabled environment. I briefly mentioned that the WebLogic SSO Synchronization Filter can help address some of these challenges.

Today I’d like to explore the SSO Sync Filter in a little more detail. The filter is implemented as a system filter for WebLogic 11g. It works in conjunction with the OAM Identity Asserter for WebLogic. The filter is only active when the OAM Identity Asserter is configured in a security realm.

It works by comparing the value of the OAM_REMOTE_USER header set by the OAM webgate to the value of the user principal name. If they are consistent then the filter lets the request through, but if they are inconsistent then the filter invalidates the WLS/JSESSION session and redirects the user back to the same URL which should either result in a user challenge or the establishment of a new WLS session with the same identity contained in the OAM session.

Note, that the SSO Sync Filter has no knowledge of OAM policies. Its view of what is or isn’t protected is based only on the headers it sees in the request. If no OAM_REMOTE_USER header is found, then the filter assumes that the request is for an unprotected resource and just passes it through. On the other hand, resources protected by the OAM anonymous authentication scheme will be considered protected by the filter since an OAM_REMOTE_USER header should always be present for such resources and set to the value of a real authenticated user or the configured anonymous user identity.

Given the functionality described above, it should be apparent that the filter is a great aid in helping to address session synchronization issues that can occur in an OAM/SSO enabled environment including issues around single logouts and session timeouts.

The documentation for this valuable Fusion Middleware component can be found here: http://download.oracle.com/docs/cd/E15523_01/core.1111/e10043/osso.htm#CHDHDBED

In my next post, I’ll discuss how to address the issue of JSESSIONID Cookie Overriding in SSO enabled environments.

Oracle Access Manager (OAM), SSO and Session Management

The subject for today is understanding user session management in an OAM/SSO enabled web application environment.

Some people think that once OAM is deployed, that the OAM session which is represented by the OBSSO Cookie replaces application or container (app server, .net, PHP etc) specific sessions. This is not the case. Application and container specific sessions still exist. It is just that rather than logging into a specific application to initiate the application or container session, the session will be initiated automatically if the user has an existing OBSSO cookie. Thus, as the user moves from one container or application to another, they initiate new user sessions without having to re-authenticate.

For all its glory, the introduction of OAM creates a few nuanced issues for architects of web applications to navigate:

Session Timeouts
It is important to be aware of the relationship between the session timeout values in OAM and session timeouts for container/application sessions.

OAM sessions have both idle and maximum session timeout controls. Most container/application sessions control only the maximum length of the session.

Ideally, your OAM and container/application sessions will timeout at the same time but it is important to understand what happens if they don’t. Even if your session timeouts are set to the same value, the OAM session can timeout before an application session if a user moves from one container to another in the same OAM session. This is because the 2nd container/application session will have started well after the OAM session.

So, if a user’s OAM session expires before their container/application session, they will be blocked at the web server (or proxy server) by the OAM webgate and asked to re-authenticate. Upon re-authenticating, they will be let through to the application. What happens next depends on the details of the integration between OAM and the container or application.

If a new login to OAM always results in a fresh application/container session then everything will work as you expect.

If however, the existing application session from before the OAM session timeout is still in place then the user of the browser will continue with that session. This is fine as long as the user re-authenticating is the same as the original user. In the case of extranet applications, applications used from shared systems or even just applications that are accessible from the public it is important to put measures in place to ensure that the user associated with the OAM session is the same as the user associated with the application session. See session synchronization below for more on this.

Logouts
If your pre-OAM enabled application has logout capabilities, you will want to synchronize this capability with an OAM logout. OAM logs a user out when they access a logout URI. Logout URIs are configurable in OAM and can be set to pretty much anything. By default, OAM will log a user out when they access any URI ending in logout.* where * is anything other than gif or jpg.

Session Synchronization
For applications that can be accessed from external/uncontrolled networks, especially public extranet applications, it is a good idea to put measures in place to make sure that the user associated with an active OAM session is the same as the user associated with an active container/application session being protected by OAM.

What you are trying to avoid is a situation where users either intentionally or accidentally log in to OAM as themselves but access the application as someone else.
The basic idea is to have a filter in place that compares the user in the OAM session to the user in the application/container session. Fusion Middleware 11g contains such a filter called the SSO Synchronization Filter. You can read more about it here: http://download.oracle.com/docs/cd/E15523_01/core.1111/e10043/osso.htm#CHDHDBED

Session Cookie Overriding
Finally, if OAM is protecting multiple containers or applications that by default issue session cookies with the same name then it is important to realize that as a user moves from one container/application to another that the session cookie of the 2nd container/application will blow away the session cookie from the first container/application.

An example of this is OAM protecting multiple WebLogic applications that are not sharing a session. The JSESSIONID cookie issued when a user accesses a second application will blow away the JSESSIONID from the first application.

Now, what you usually see in such a setup is that the user can go back and access the first application without having to login again. However, underneath the covers they will be issued a new session. So, upon returning to the first application, any data associated with their original session will be lost and the application flow may be disrupted or different from the expected behavior.

Single Sign On for WebCenter Interaction

I have spent a little time recently setting up single sign on for WebCenter Interaction. My environment is WebCenter Interaction 10.3 running on Oracle WebLogic Server 10.3 on Windows 2003 Server, with an Oracle HTTP Server (Apache 1.3) HTTP Proxy, … Continue reading