OBIEE - SSO -- Integrating with a third party login with AD authentication / passing user and pass in URL

Implementing SSO or Windows Native authentication in OBIE is something we do frequently.

Basically, we integrate OBIEE with Microsoft Active Directory and obtain centralized password management. 

This is also more secure and easy for the users.. They don't have to remember or manage their OBIEE usernames and passwords as they already have more important usernames and passwords, I mean their domain users and passwords. 

This gain we make by implementing SSO is actually in convenience, manageability and security. This benefit or gain is provided by all types of SSO configurations. In single password implementations, users login with their domain usernames and passwords. In windows native authentication, they don't even login as we get the credentials (or lets say the auth info) from the client OS on the fly in the backend transparently to the user :) It's been a long sentence :)

Anways, this is what we do in OBIEE and even in EBS envirıonments. In EBS, we use OID and OAM as well. (Things get complicated there but that 's true :)

So I guess all of us are familiar with this single sign-on (single password or no password)  concepts already. 

However; what I want to share in this blog post is something, which is a little different than a standard configuration.. A scenario, a real life story, a workaround; you name it :)

That is, suppose your customer wants your OBIEE to authenticate the users with AD usernames and passwords but suppose the customer has a custom web page which is in front of the OBIEE and the customer wants to get the usernames and passwords through that custom web page. The custom web page must authenticate the users and then redirect to OBIEE..

So what we do?

Well, we implement SSO in OBIEE side. This is what we need to do in the first place. 

Then we make our OBIEE to get the user and pass through the OBIEE url. (on-the-fly login using url arguments).. Note that this is the simplest way of doing this work.. Ofcouse, customer's ability to post the usernames and passwords using any other method than this one, will make us change/improve the design of this login flow.

At this point, we pay attention to the following;

"12.2.1.3 LightWeightSSO is ON by default and NQPwd/User wont work." 

This means, the news versions of OBIEE won't let you in with the usernames and passwords supplied through the url.

So, what we do? 

If that is a must.. I mean if the page can't post the username and password information to OBIEE using any other method than the url method, then we disable the LightWeightSSO. 

In other words; If we must use the NQUser and NQPassword login url parameters, we must disable lightweight SSO using the WLST disableSingleSignOn command. 

The following document will help us for that;

OBIEE 12c: Using NQUser and NQPassword in URL, Fails to Login When Single Sign-On (S
SO) or Lightweight SSO (LWSSO) Is Enabled (Doc ID 2316810.1)

Once we configure our OBIEE side, we tell the customer to make the necessary modifications in the custom webpage to make it pass the username and password information to OBIEE during the login process. That is it..

We reached our goal.. Clients will use the custom web page to enter their AD/domain usernames and passwords and then the custom web page will make OBIEE to authenticate it in the backend and the clients will see his/or her BI dashboards without authenticating again.

Before finishing, 2 important reminders ->

Don't forget to implement a full path SSL for the HTTPS communication.

Consider implementing  LDAPS for the ldap traffic between OBIEE and AD.

This is the story of the day :) I hope you will find it useful.