SSO - how does your Driver's License stand up to the challenge

As a frequent traveler, I can't imagine my life without one piece of plastic in my wallet- my Texas Driver's License.

On the day of travel, I use it to get past the airport security, get into my rental car, check into the hotel, get cash from my bank (I do not carry any debit cards as a safety measure), get past the paranoid girl at the check out counter who insist on seeing my id before she can swipe the credit card for that bottle of water, and prove that I am of legal drinking age as I sit down at the hotel bar after a long day.

In all of these transactions, I whip out my trusted Texas DL and authenticate myself as Mr. Sachin Jain. Some people look at the id, some run it under devices that pop up the various security features embedded within the card, and almost all of them look up to match the photo on the card with my face and confirm that I am who I am saying I am.

I was authenticated by the system using a token(my Texas Driver's License) issued by a central/trusted token provider (Texas Department of Motor Vehicles).

Once the authentication is done, my identification is confirmed. There is almost always a second piece of token which then authorizes my access to the service I am seeking- my boarding pass, notations on the boarding pass giving me premium access, TSA pre-check privileges, my reservation confirmation to a particular car for certain period of time, a hotel booking, my credit card, or my date of birth on the DL itself, .

Imagine if I had to carry a separate piece of identification for each of these interaction! My wallet would be bursting at the seams. I would have to go through the hassle of bringing the right id that will work for a particular encounter. i would have missed opportunities because I don't have  the ID for the most popular joint that yelp suggested, or for that hotel I bid for on Priceline as I am walking out of the office on Monday afternoon.

Driver License - SSO

Similarly in computer security, SSO  is a way of authenticating a user based on a Central Directory. When a user requests access to a resource, a certain web site, their HR records, email, etc. the provider redirects the user to a login page hosted by the SSO authority which presents a challenge-response, mostly in the form of a id/password combination or additional mechanisms.  Once the user gets past this screen, the SSO authority confirms the user authentication and passes a token identifying the user to the servicing application. The application can then bounce this token against its provisioning store and give access to the user to the appropriate resources based on the authorization.

Several applications can subscribe to the SSO server, thus eliminating the need for the user to maintain multiple authentication tokens (id/password) to get access. Most of the time, if the user has already been authenticated once to an application, the SSO provider can leave a token on the browser session user tries to access another application with the same SSO provider, no log-in is necessary. This provides seamless access to multiple applications

This is a very simplistic, 10,000-mile high description of how an SSO echo-system works, I hope this helps you grasp the basic concept and find similarities/differences between a real-life and virtual SSO implementations.

Tech Term of the Day
SSO:- Single Sign On

Further Reading

• https://en.wikipedia.org/wiki/Single_sign-on
• 101 Things To Know About SingleSignOn

Sachin
Architect - Oracle Engineered Systems
Exalytics/Exalogic/Exadata
BuzzClan LLC

BuzzClan is a business consulting company collaborating to provide Oracle software advisory services & implementation services. BuzzClan LLC is committed to providing substantive business value on each and every client engagement. We do this through a combination of industry-specific business expertise, technical skills, proven project management methods and our “onsite - off site - offshore” delivery model. We strive to work in partnership with our customers to build high-performance teams and create business solutions that will last.

External table based authentication and autorization in OBIEE

Sachin
JainSys Inc. The basic out of box security available with OBIEE is via the administration tool. To administer the users/groups one logs in to the RPD and open Security Manager (Manage/Security). Groups, users and their relations are managed via this.

The drawback to this method is that every time we need to add users or manage groups, this becomes an admin task involving IT. In an enterprise application, there are other means of maintaining user access like SSO or custom admin screens which allow for the designate admin roles in the user community to manage access to users. This generally runs off of a custom profile implementation.
A typical layout for this type of security implementation is done via a set of three tables:

• USER
• ROLE
• UserInRole

This allows a many to many association between users and roles.

To take advantage of this in OBIEE we have to configure the system to query the database on login. The steps required to do so are as follows:

1. Setup database connection.

Start by importing from the database which has the security/profile tables.This Connection pool will be used later in the process.

2. Once we have the connection pool ready we now need to set up an Initialization Block. An IB is executed every time a user logs in and a session is being created. The idea is to get teh User name and password passed on through the login page and use that information to query the database and authenticate the user.

3. Open the RPD and Create an new IB by clicking the menu
and then on the Variable Manager :
We need to do this on a "Session" IB not a "Repository" as this will be done as each user logs in.
Select the Data Source Type as "Database".
(If you do not see Database as an option then you may not have a valid ODBC or Oracle client on the server. If you have been able to complete the import step above then this shold not be an issue. Else this is about time you install a client to connect to the data store.)

4. Initialization string: We now need to define a query which will take the UserId and Password passed on to the login screen and check the tables to see if this user exists and have access to this application or not. This is also our chance to grab items from the user profile like Display Name, groups they are assigned to etc.
Typical sql at this point is:

select username, grp_name, SalesRep, 2 from securitylogons where username = ':USER' and pwd = ':PASSWORD'

:USER is a way to indicate that the value of that variable will be substituted on run time.

5. Variable Target: This section allows us to define some variables to contain the results. There are some predefined session level variables:
USER ; PASSWORD; DISPLAYNAME; LOGLEVEL; EMAIL etc
See this for details

The variables should be lined up in the order they are being returned from the query to allow proper assignment.

Check the "Required for authentication" check box to indicate that this IB is used for authenticating users.

Save.

6. Testing : The logs for any issues with this test can be found at {OBIEE Dir}\OracleBI\server\Log\NQServerLogs.log.

I kept getting :
[nQSError: 13011] Query for Initialization Block 'Authentication' has failed.
[nQSError: 17001] Oracle Error code: 911, message: ORA-00911: invalid character at OCI call OCIStmtExecute.
[nQSError: 17010] SQL statement preparation failed.

because I had the semicolon at the end of the query. Apparently statement preparation did not like it.

Once there is data in underlying tables, this should be a easy!

7. Next tasks: setting up groups and managing RPD level and Report level security. That's calls for another blog i guess!! Sachin
JainSys Inc.