What is more important? What you buy or from whom you buy it?

I recently had a very enlightening and satisfying customer service experience.

Not too long ago, I bought a new car. I love the car - it drives great, gets great gas mileage, looks cool, and is basically everything I was looking for in a car. Unfortunately, this car was also having persistent issues with the emissions system, causing the Service Engine Soon light to come on after about 1700 miles. I dutifully took the car into the dealer to have it serviced. Then I took it in again. And again.

With each trip to the dealer, my frustration mounted. I began to conclude that I had inadvertently been sold a "lemon". I did some research into California's "Lemon Law" and as a result immediately contact the manufacturer to notify them of the issues with the car, tell them how frustrated I was, and see what they would do.

Because of other customer service experiences - satellite/dish providers and mobile/telco providers spring immediately to mind - I expected the worst. To my surprise, the customer service provided by BMW North America was superb. The customer service representatives (I talked to two during one 20 minute call) were helpful. They showed empathy for my situation. They told me they would advocate on my behalf. They offered suggestions for what to do next. They asked me what would I thought would help bring the situation to a successful conclusion and promised to work toward those outcomes.

As a result, I was immediately calmed. I asked for a root cause analysis of the problem and I agreed to another attempt to service the vehicle. In the end, I didn't get a root cause, but I did get my car back with the issue fixed, was treated exceptionally by the dealer, and am probably on my way to becoming a lifetime customer.

Every successful company cares about their customers. So what makes one vendor or manufacturer different from another?

I am very often asked by customers, partners, Oracle sales people, and others what differentiates Oracle and our Identity and Access Management products. Usually they expect that I will tell them what our products do, how they are built, and why that makes them different from other products they may be evaluating. What I typically tell people is that it isn't WHAT we are selling but HOW we stand behind it that makes all the difference. The example above perfectly illustrates the point.

Let's face it, there often isn't a lot of easily identifiable functional differentiation between products sold by big enterprise software companies. While most claim otherwise, this is also true of many of the smaller start up and niche vendors in the identity and access management market.

The same can also be said for car manufacturers like BMW, Lexus, and Mercedes Benz, which is what got me thinking about this in the first place, that it's more about from whom you buy and how they help you after you buy it than what you buy in the first place. Setting aside the price aspect for a moment, generally this kind of thing is referred to as a commodity.

So when I listen to customers talk about what is really important to them, I generally hear them focus on two things:

1. they think of most software and the hardware it runs on as commodities, and;

1. as a result it isn't the product functionality they are worried about, but the robustness of the solution and how easy it will be to keep it up and running in their environment.

In fact, when asked to spend $100, many will spend $70-80 out of that $100 on tools/features for existing software that facilitate diagnosing or troubleshooting issues. As it turns out, this is an indication that these customers are worried about whether - when something goes wrong - someone will be there to listen, to help them through their problems, to understand what defines a successful outcome, and be an advocate toward that outcome.

So how do vendors and customers work together to achieve a successful outcome? What do commodity vendors do to differentiate themselves from other vendors?

While working with customers, I've noticed a few things that our team does that almost always
help:

• Be proactive. If all your interactions are based on hair-on-fire escalations you generally don't have a good basis for cooperative, constructive problem solving. Since most enterprise software support systems are by their nature reactive, proactive communication will help by establishing a raport and creating trust outside of the scope of reacting to a specific problem. Proactive communication will also allow you to anticipate key upcoming milestones so that you can prime your reactive support system to be ready before problems occur.

• Be transparent. Tell your customer what you are doing and why you are doing it. Most support escalations occur when your customer contact doesn't know what to tell his/her boss. Picking up the phone periodically, even if just to explain that you have nothing new to report but are continuing to work on or monitor the situation, can help defuse most potentially explosive situations.

• Show empathy. Don't make exaggerated claims or promise to deliver things you cannot deliver. The single most satisfying thing about the customer service I received from my car manufacturer was the fact that they made it clear they were on my side. They made no promises other than to be my advocate. That was enough.

• Engage action. Get everyone on the same page about why they come to the office everyday: to ensure customer success. If everyone is on the same page about why, you can avoid disputes about what needs to happen, who needs to do it, and when it needs to get done. The most successful resolutions I've seen have been the result of strong collaborations of cross functional teams where the day job of most of those team members was not, strictly speaking, customer support.

This is a pretty basic description of what the folks at my car manufacturer did for me. Of course, there is no one-size-fits-all solution that creates undeniable differentiation around a commodity product. Nonetheless, when prospective customers ask me what sets Oracle apart, I don't spend a lot of time telling them about software features. Instead, I describe the process above, explain why that is important to us as an organization, and how that emphasis benefits customers.

Usually, that is enough.

How SSO works in OAM 11g

Here at Oracle, the access management PM team gets asked a lot of questions about how Oracle Access Manager 11g works, especially about the overall SSO model, what cookies are created and what they do, and processing flows between components, and how specific component interactions work to achieve authentication and SSO. In this post, we will explore the OAM 11g SSO model. It’s quite a bit different from the OAM 10g model, especially since we now support things like server side credential collection, server-based session management, and application scoped sessions.

Before we get started, it’s worth noting that OAM 11g supports the use of both OAM 10g and 11g Webgates as well as mod_osso plug-ins for Oracle HTTP Server (OHS). We support this through what we call the Protocol Compatibility Framework, which lets the OAM server communicate with and interpret protocol messages from the webtier agents mentioned above. This is an extensible framework so has the potential to support other clients or agents in the future.

OAM 11g uses a combination of host cookies or domain cookies (depending on the version of Webgate you use), a server cookie, and an in-memory session store (based on Oracle Coherence technology) to maintain and correlate user session information.

Since OAM 11g supports different Webgate versions and mod_osso, you will see different cookies depending on the version of Webgate being used, you will either see the ObSSOCookie (for 10g) or OAMAuthnCookie_host:port (for 11g).

However in both cases, the contents of the cookies are:

• Authenticated User Identity (User DN)
• Authentication Level
• IP Address
• SessionID (Reference to Server side session – OAM11g Only)
• Session Validity (Start Time, Refresh Time)
• Session InActivity Timeouts (Global Inactivity, Max Inactivity)
• Validation Hash

These cookies are updated periodically using an algorithm of 1/4 of idle session timeout. There are two main differences between the 10g and 11g cookies:

• The 10g ObSSOCookie is domain scoped and cookie encryption uses a shared key for all 10g Webgates.
• The 11g OAMAuthnCookie is hosted scoped and different host cookies may be issued for each resource accessed that is protected by a different 11g Webgate. Cookie encryption for each 11g Webgate is unique to that Webgate.

The values of the cookies will change over the life of a user's session, however you'll notice that the Session ID that is present is a reference to the server side session object, which remains the same across the life of a session.

In the typical deployment topology, you’ll have one or more Webgates deployed on web servers in the Web Tier, a variety of components deployed in the App Tier including an OAM admin server running on the Weblogic domain’s admin server, one or more OAM runtime servers deployed on Weblogic managed servers, a database to support the OAM policies, an LDAP directory against which you will authenticate users, an optional auditing database, and an optional BI Publisher instance for reporting.

Using an OAM 11g Webgate in the flow, let’s recap how this works:

1) An OAM 11g Webgate intercepts the incoming request for a resource, determines whether the resource is protected, and – if it is – the OAM 11g server constructs and returns a response back to the Webgate. That response contains the authentication scheme required to authenticate the user.

2) Next the Webgate sets a cookie (called OAM_REQ) to keep track of the target/requested URL and then redirects to the OAM 11g server, which routes the request to the credential collector. The credential collector serves up the login page, which captures credentials and posts the credentials to the OAM server. The credentials are validated against the ID store configured for this particular authentication scheme. Once the credentials are validated, the OAM server creates an authentication token, the session in Coherence, and creates a server side session cookie called the OAM_ID cookie, which has details about the user, the time the session was created, the idle timeout, and session identifier to the coherence session.

3) Then the OAM server constructs a response which is encrypted with the Webgate's key and redirects to the Webgate. The Webgate decrypts the response, extracts the authentication token and the session identifier, and uses that information to set OAMAuthnCookie, which is set as a host cookie: OAMAuthnCookie_. (In this step if you are using an OAM 10g webgate, the response from the server will contain the information required to set ObSSOCookie, if you are using mod_osso, the response will contain the information required to set the OHS host cookie.)

4) When subsequent requests are made from that Webgate, the authentication token is passed by the Webgate to the OAM server, which validates the authentication token, checks the validity of the OAM_ID cookie and session timeout, and does the appropriate authorization checks. As the result of authorization checks, additional attributes may be added to HTTP Headers and passed to downstream applications. This is especially useful when asserting user identity and group or role information to downstream applications such as those running on Oracle WebLogic Server and Oracle Fusion Middleware.

5) When requesting a resource protected by a second Webgate, the request flow will be similar to the above. Webgate2 will check if the resource is protected, and get the authn scheme details from the OAM server. From there WG2 redirects to the OAM server, the OAM server checks the OAM_ID cookie, and then generates a new authentication token for WG2, creates an encrypted response using the key for WG2, and redirects to WG2. WG2 decrypts the response, extracts the authentication token and session identifiers and sets an OAMAuthnCookie as a host cookie for WG2.

Updates to FFIEC Authentication Guidelines

The FFIEC published draft guidelines that update their 2005 guidance for authentication in Internet banking environments.

This updated draft guidance calls for:

• More risk assessments for banks to better understand and respond to emerging threats, such as man-in-the-middle or man-in-the-browser attacks, as well as keyloggers;
• Increased multifactor authentication;
• Layered security controls;
• Improved device identification and protection;
• Improved customer and employee fraud awareness.

The good news is that tools such as Oracle Adaptive Access Manager already provide many of the controls specified in the draft guidance. Check out the datasheet to see how OAAM can help meet the requirements of these updated guidelines.

This updated FFIEC guidance is consistent with another trend we've seen: more precise, prescriptive regulations that organizations need to meet in order to be in compliance. Typically more prescriptive regulations are seen in industry segments like financial services (or other highly regulated industries like healthcare) and then gradually spread to other industry segments.

Stronger Authentication Isn't The Answer

It seems practically every day I hear the same question. “My company needs a strong form of authentication for users of our web applications but we don’t like the downsides of hardware tokens/smart cards/etc, what type of strong authentication is better?” The problem with this question is it’s generally based on the false assumption that adequate protection for web applications can be achieved by deployment of “strong” credential based authentication alone. Of course, I am not disparaging anyone asking this question since the underlying assumption has been engrained in us all and it’s been enforced by various regulations and corporate policies to boot. So what is the best answer to this question?

Let’s start by breaking this down a bit. To clarify, I am using the term “credential based” authentication to refer to all authentication forms that verify a user’s identity by asking them to provide a credential. It really doesn’t matter if the “credential” is a password, one time password, biometric (typing rhythm/fingerprint/hand veins/iris/etc), or something else, they are all really just different types of authentication credentials in the end. So if a company chooses to simply substitute one form of credential for another they are not really increasing their security by much when considering all the types of threats. Some types of credentials and flows are stronger than others but there are threats that can’t be prevented even by the strongest of these. As well, there are soft and hard costs with such a change so a business better be substantially increasing their security not just swapping apples for nicer apples.

Just a few of the threats that credential based authentication of any strength cannot address are insider fraud and session hijacking. How can a credential prevent an employee/contractor/user from misusing the access they have been granted? Likewise how can a credential prevent someone/something from taking control of a valid user’s session and misusing it? The reality is that credential based authentication and authorization alone simply can’t. To address such threats, contextual risk analysis must be part of the solution to be effective.

A solution must actively “watch” the entire context of an access request to see what a user does and see how far their current behavior varies from their past “normal” behavior and/or the past behavior of all users. A solution must “learn” from past incidents what fraud/misuse looks like and identify how closely a situation matches to these past incidents. Also, a solution should be able to proactively interdict if the risk of a situation becomes too high. This risk-based interdiction may employee forms of credential based authentication that are both easy to use and an appropriate strength for the resource and level of risk at that moment. As well, interdiction could take the form of dynamic authorization policy adjustments based on the level of risk. To summarize, a company that wants strong access security for their web applications must take a more holistic approach which includes contextual risk analysis, risk-based strong authentication and risk-based authorization controls.