Access Management - dime a dozen?

As I type, I’m heading to Toronto to discuss authentication, authorization, and SSO with a customer. The account manager tells me that the client largely thinks of access management (AM) as commoditized. It’s hard to argue with that, since I’ve been slinging SiteMinder, RSA, Securant, and Oracle Access Manager for a number of years. I honestly believe that some vendors more than others have kept up with the times, augmenting their products, building in new features, and creating hooks out to the cloud, although there aren’t many of these. Some people have acquired this kind of tech and then let it languish, instead of adding features and increasing usability.

So there you have it, the path to looking beyond commoditization. They can all log you in, they can all authorize you, based on attributes or groups. But then all the little differentiators come into play. Let’s talk about those.

Federation. Baking this into the base product is a noble cause (although it hurts single track vendors like Ping). Oracle has long had the ability to seamlessly integrate OIF into an authentication scheme, but now it’s a single layer, for all practical purposes. The eating and spitting out of SAML assertions is now de rigeur. There, I’ve worked in a disgusting metaphor and some useless French in the same sentence.

Distributed user data. Sure, your creds get bounced off of AD. But if your authorization data is localized, why wait until you reach that app or target database? Consolidating, or at least virtualizing, all that user data, across multiple sources into a single authorization source, allows the security mechanism to validate you up front, then pass along any needed personalization or qualifying data through headers or cookies or session variables.

Fraud detection and prevention. One of the name “open source” vendors out there claims to have this, but they do it one lousy factor at a time. “Your IP address is bad. And, uh, that’s about it.” You really have to look at a combo of factors, such as a user’s device, the time of day, their download history, their transaction volume, and anything else that might come into play. Again, in combination. A true risk engine can mitigate this. But most vendors don’t have such a thing.

N.B. Regarding “open source”  …. If they’re a vendor, and they’ve productized their offering, they’re not really open source any more. And I wish people would stop reflexively thinking that “open source” means somebody is pure of heart and fighting the evil giants. They’re trying to make a buck like anybody else.

Propagating identity to web services. The endpoint application is still logging in to the database and whatever else on your behalf, with its own creds. But the ability to push the user’s identity to the back end means a more accurate audit trail, and can provide much needed authorization context.

Hooking to fine grained entitlements. What about those permissions that are beyond the web server, the stuff your broker or gateway can’t necessarily see? You need to propagate identity to that as well, so that the security mechanism can check to see if you truly can wire more than $50,000 at a time. Or if you’re a crook or a deadbeat.

Transformations. So I wrote a bunch of web services based on SOAP. But nuts, now the world’s gone JSON and REST. I have to rewrite all that stuff on the back end, right? Nope. Not if my gateway has the ability to intercept that SOAP/XML, check for bad packages and viruses, then transform that request into the proper protocol. This future-proofs my apps. And when somebody invents another protocol in a couple of years to replace REST (eg. JAML: Jeff’s Access Markup Language), I simply update my gateway’s filters to handle that dialect as well.

A sound access management foundation still handles the basics: name and password. But it should also allow you to easily bulk up to handle a variety of other use cases and user types. When you’re shopping, check the fine print, and ask the finer questions.