Tuesday, June 5, 2012

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 verify signed requests sent by 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. :-)

27 comments:

  1. Very well composed, exactly I am looking for this. I am going to try out today.

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete
  3. I followed your steps. I changed analytics.Ear file and other steps, I did not enable SOS,
    I entered in the browser http://sp.server.net:12006/analytics/
    I got below error message in the browser as expected:
    From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
    10.4.2 401 Unauthorized
    The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.46) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable authorization header field (section 14.8). If the request included authorization credentials, next the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has attempted authentication at least once, the user SHOULD be presented the entity that was given to the response, since that entity MAY include relevant diagnostic information. HTTP access authentication is explained in section 11.

    afterwards I have enabled SOS, than tried http://sp.server.net:12006/analytics/saw.dll?bieehome&startPage=1,eehome&startPage=1,eehome&startPage=1,
    After authenticated with IDP, it came back to regular analytics login screen and ask to enter user name and password without going directly to dashboard.
    As per log user has been authenticated with the principal groups, but not directing to dashboard.
    Any suggestion, what I am missing here?

    ReplyDelete
  4. Komal, please review analytics web.xml and weblogic.xml. Also, check for any log messages in bi_server1 managed server. After enabling SSO in EM, make sure to restart bi_server1.
    Thanks,
    Andre.

    ReplyDelete
  5. Thank you, Andre for your reply. It's working fine now after
    starting biservice with below command:
    opmnctl startproc ias-component=coreapplication_obips1

    ReplyDelete
  6. Glad it worked, Komal. But I do not remember having to restart biservice.

    ReplyDelete
  7. hello andre

    i'm trying to get the same thing working with the SAMLAuthenticator & using a SAML Assertion from SiteMidner. Would i need to create a CustomMapper to populate Principals? I'd like to use the virtual users option since the identity store used will be the IdP (SiteMinder) store. Also, the assertion will contain groups that the user belongs to. How do i assign the virtual user these groups?

    Thanks

    Shiva

    ReplyDelete
  8. Shiva, you won't be able to consume groups or use virtual users from SiteMinder in OBIEE, unless you do some custom work, which may not be simple.

    As stated in the blog:

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

    ReplyDelete
  9. Thanks for sharing it! I followed the steps and configed everything. The slight difference is that it is OBIEE version 11.1.1.6. There is only one AdminServer(admin) and seems analytics also runs on this server.
    After changing the web xmls in the analytics war in the ear, when I hit the host:7001/analytics, I get a ERROR 400 Bad Request. before changing the web xmls it works and show a login screen. It seems it has not triggered the SP SAML request to the IDP.

    Can you help and tell me what could be wrong?
    Also to understand better, what component configed in the article triggers the SAML AuthRequest?

    ReplyDelete
    Replies
    1. Tony,
      Make sure you have /analytics/* as one of the Redirect URIs values in the IdP partner configured for the SP. This should trigger the redirection to the IdP.
      Thanks,
      Andre.

      Delete
  10. Andre, I have all three in the redirect URL for the WebSSO-IdP-Partner-0
    /analytics/*
    /userinfo/*
    /sampleadfapp/adfAuthentication

    ReplyDelete
    Replies
    1. Only /analytics/* applies to this use case. The others were part of other use cases I had.

      Delete
  11. I had the /analytics/* configed as Redirect URI. No luck..


    Error 400--Bad Request

    From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

    10.4.1 400 Bad Request

    The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

    ReplyDelete
    Replies
    1. Tony, I haven't seen this before. Please use something like Fiddler to see the redirects. This error suggests there's something wrong with some URL, maybe.
      Andre.

      Delete
  12. looked at the fiddler http traffic and there is no redirects. I was hoping some redirect would be triggered. I don't quite understand the CLIENT-CERT part. Does it require the request to have something? does it require some client certificate?

    ReplyDelete
    Replies
    1. CLIENT-CERT will trigger container-based authentication. It is a must for this use case.
      Andre.

      Delete
  13. Nice Article. Thanks Andre.

    I have a question for SP meta-data. In a cluster, though all servers have identical SAML configuration, certificates would be different, hence the meta-data are not exactly identical. Since entityID would be same, only one meta-data could be imported into IDP. So which SP meta-data should be imported into IDP as they are not exactly identical coz of different certificates. Please advise. Thanks.

    ReplyDelete
    Replies
    1. YogsBang,
      in this case, have the same certificate for all servers that are members of the cluster.
      Thanks,
      Andre.

      Delete
  14. I am experiencing the same issue as Tony. Has anyone identified the cause of this issue, and what can be done to resolve it? If so, I would greatly appreciate it if you could share your insight.

    ReplyDelete
    Replies
    1. Hello Geoff,

      make sure of the following:
      1) you have changed web.xml and weblogic.xml as per instructions;
      2) you have enabled SSO in Enteprise Manager. Make sure to pick Generic SSO in the drop down list box.
      3) you have /analytics/* in the Redirect URI

      Restart the Admin server and bi_server after doing these.

      Thanks.

      Delete
    2. Hi Andre,

      Thanks for the reply. I have confirmed that the changes have been made to web.xml and weblogic.xml per the instructions. I've confirmed that the /analytics/* redirect is in place. Lastly, I SSO is enabled and the Generic SSO selected. I've restarted the servers and the physical boxes a number of times, but continue to receive the Error 400. Any other avenues you or anyone else can think of that I might investigate?

      Delete
    3. Geoff, I then suggest you use some web debugging tool (like Fiddler) to observe the redirects and then match the failing page to the actual target service. For example, I once was beating my head against the wall because analytics was running in the BI managed server an I was entering the Admin Server port for the Published Site URL, hence getting a 400 error.
      Andre.

      Delete
  15. This comment has been removed by the author.

    ReplyDelete
  16. Andre, hi do you know if OBIEE supports the SAML single logout? how to log it out from IDP or other SPs?
    btw, I've got SAML working now.

    ReplyDelete
    Replies
    1. Hey there Tony,

      SAML single logout would be a feature of Weblogic, and not OBIEE. Unfortunately, the answer is no. There's no SAML single logout in Weblogic.

      Cheers,

      Andre.

      Delete
  17. Hi Andre,

    Another question. In your article you say "It is a must that they are also secured by the container, otherwise Weblogic won't trigger the authentication process.", can you tell me what 'container' here refers to?

    Thanks,

    Geoff

    ReplyDelete
    Replies
    1. Geoff,

      'container' here refers to the application server where the application runs. Specifically, I am talking about web.xml having the auth-method set to CLIENT-CERT. That basically tells the 'container' that the application expects perimeter authentication. Weblogic expands the original purpose of CLIENT-CERT to also include SAML tokens, among others.

      Cheers,

      Andre.

      Delete

Note: Only a member of this blog may post a comment.