Workflow in the skies

As an all too frequent flyer, I am constantly amazed at the stupidity of other travelers. Here’s a recent example. After a lengthy delay in Montreal, we finally boarded. With status, I got on third. THe first guy on, in first class, immediately held up EVERYBODY ELSE by stopping to pull out of his bag everything he wanted at his seat before he shoved his stuff into the overhead. He took his sweet time about it. Then he decided to pull his bag back out to retrieve another item. I strongly suggested he do this off to the side, that he was preventing the many other passengers from getting on, thereby delaying our pulling away from the gate. When he decided to ignore me, I decided to not let him do so, and within two seconds, he was off to the side. I’m getting cranky in my old age. I also suggested to him that next time he get his crap out BEFORE he got on the plane.

Workflow. It’s all about workflow. In this case, I was the workflow engine. Things must be accomplished according to policy. You can’t get your permissions in E-Business Suite unless your attributes or business roles say you can. And if you have a task, such as approving a request, or manually provisioning a request that’s been approved, or getting your crap out of the way so the rest of the passengers can board, then the workflow engine will either take care of it, according to policy, or send out the notifications, in the form of an email or the pushy guy who’s boarding third, and you will be nagged and possibly threatened with further action if you don’t comply.

Things happen according to POLICY. And if there are exceptions, if things do NOT happen according to policy, then there’s a POLICY for that. If you DON’T fulfill an assigned task, an escalation will be automatically performed, and perhaps your manager will be notified. Or perhaps the guy who boards third will offer to shove your crap in the overhead for you, and you along with it. Escalation. Policy.

There, I feel much better.

Are passwords dead? Still? Really? No kidding?

I'm in a writing group at my library. The group brings their brilliance a couple of times a month and we critique each other, and it's a wonderful thing. Even a part-time novelist like me can always use tips and hints.

We also trade the wisdom from very successful writers we like. Recently, one of our members brought up something I first heard in high school: never start a story with "the alarm clock rang." It's been DONE. Whatever clever thing you think you're inventing has been done to death. Whenever you think you're being original, try harder. 

So it's gotten very annoying to read, over and over and over, articles entitled "The password is dead." Everbody thinks they're being clever, apparently. An old friend of mine just gave a talk on "passwords are dead" in the UK. When I heard, I thought, oh crap, him too.

It's time to move on. In fact, I'm going to provide encouragement here to do so, by summarizing what all these articles say. Save yourself the time. Here we go.

We get it. Yes, passwords are easy to hack. Keyloggers steal the creds as you use them. Cracking programs figure them out (although a 3 strikes and you're out scenario takes care of that). Linked accounts mean a single compromised account can compromise ALL your accounts, including Facebook, Twitter, email, your bank, etc.

Observe some best practices:

Get yourself an email account for password resets that isn't your usual one. I have one just for registering for junk that might end up turning into spambot targets. And don't make it first-dot-lastname. Make it something stupid and random.

Don't use real answers for your security question. Mother's maiden name is a FINE question, as long as the answer you provide is something else entirely. Remember, a 2008 vice-presidential candidate's email got hacked because somebody clicked on Forgot Password and provided the easily-Googled answers.

Don't use common words, your wife's name, your kid's name, your favorite sports team as your password.

Don't keep using the same passwords over and over. When your password expires, don't go back to it. EVER.

Keep passwords long. Each additional character means another order of magnitude for crackers.

As an enterprise, consider multi-factor. IP address, device fingerprint, anything at all that can be used in conjunction with credentials is a good thing. 

 

There, all done. 

Web service security – when and where

It’s always challenging to explain when, where, and how to apply functionality when there are multiple solutions in an environment that overlap. “Product A already does that, so why do I need Product B?” Occasionally a vendor will make it simpler by deprecating a function in one product when it becomes available in another (or, like CA, you keep five products that all do the same thing). Of course, this can upset users of the first product who upgrade and suddenly find they can’t do something they used to be able to. Believe me, I get it.

The old Oblix product used to do some basic provisioning and workflow, but a while after it was acquired and became the Oracle Access Manager, its provisioning abilities were subsumed by Oracle Identity Manager. It simplified the story, that’s for sure.

The old gateway functionality of OWSM (Oracle Web Services Manager) was moved into OAG (Oracle API Gateway) because, honestly, it makes more sense there. There is still overlap between the products, but here’s the deal. Whenever there turns out to be more than one way to do something, and the customer asks me, “Well, how should  I do this?” the answer could be, “It depends.” And what it depends on is:

1)      At what point in the process do you want to do it

2)      What other functionality has to surround it

3)      Who in the organization will own it

With web services security, you might qualify this with: will the security portion be owned by the SOA guys, or the security guys?

OWSM is still the way to go for last mile security. It’s all the way in the back of your reference architecture, right? It’s waaaaaay back there where your services live. The Gateway, on the other hand, sits in front of everything. Before a request makes it anywhere past the DMZ, it’s intercepted by the Gateway, validated for safety and cleanliness, protocol-transformed as necessary, redacted and/or enriched, given a thorough spanking, then sent on its way.

(In fact, the request could be throttled, measured, routed, or suffer any number of other indignities as well.)

 This IS the most secure way to do things, of course, because this means the request is vetted before it makes it anywhere toward the back, where it gets processed. Bad, evil, corrupt, malicious, or malformed requests never get the chance to eat up any CPU, since they are stopped at the front door. This architecture greatly reduces the chances of anything bad slipping through. Additional policies being handled by OWSM, or the Enterprise Manager, have their turn to take a swing if the request makes it that far. Defense in depth, right?

 And HERE is why you want to do those transformations in the front as well. Keep those decisions off the bus, out of the code, away from the apps themselves. If you’re running in SOAP, but now you’ve moved into the REST or JSON era, let the Gateway handle that nonsense, so you can take your time migrating your code or backend policies. You are future-proofing, or at least temporarily preserving, your apps or services.

Just as there is value in abstracting identity consolidation at the directory level rather than the code, there is value performing these service security and transformation functions in front rather than the back. Think of the Gateway as a security abstraction layer. By the time the service or app receives a request, that request has been hammered into an acceptable shape.

It works like this for me at home. Before we ever make it to a funeral, my wife and kids have decided that whatever I’m wearing is not going to work, and I’m wearing something completely different by the time I make it to the car.

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.

SOCIAL, MOBILE, AND THE BUSINESS REASONS

One of the biggest recent drivers to the fattening of my travel schedule is my customers’ perceived need for a social/mobile strategy. Many of them have ample reason for such a beast, in that they feel strongly that accepting authentications from, say, Facebook will increase their traffic. And it’s true, when you make it easier for somebody to just pop over from an existing online session, without making them cough up yet another id and password, makes them more likely to visit more often. And they don’t have to consult their extra text files or Post-Its to find those additional creds.

N.B. Sometimes there IS a benefit to those extra creds, however. You may want to segregate some of your identities, especially when you use them to express strong political views, or download racy pictures.

A number of organizations I’ve spoken to are pretty sure they need a social/mobile plan, but only because of peer pressure, or even managerial pressure. I sat in a meeting a number of months ago with a security chief and his boss’ boss, and that ranking manager had convened the gathering specifically to find out how we could help them with their mobile plans. I asked, simply enough, “What is your business use case?” And, whaddaya know, they didn’t have one of those. They only knew, they should be putting their stuff on mobile. “Which stuff?” I asked again.  “Product? Marketing message? Contact info? Just a mobile version of your corporate landing page?”

Too many companies haven’t given this sound thought. Same thing with social. Yes, we want users to authenticate via Facebook. We just don’t know WHY.

I have precious few banks or other financial outfits asking for this. But companies that make textbooks, retailers, those kinds of people definitely are. And for them, it makes sense. But again, you need to know HOW these initiatives serve the BUSINESS. If they don’t, then it’s just noise, and wasted resources. Fine, have a nice mobile version of your homepage. You can always add some kind of ecommerce to it later. But don’t go nuts until you know WHAT PURPOSE it will serve.

Plenty of social sites have been hacked. A well-known news site was hacked a few months ago, and implanted with a phony story about an attack on the White House, causing the market to drop like a rock and wipe out, for a few hours, billions in portfolio value. Plenty of people have creds for news sites so that they can comment on articles. You may have established yourself in many places, and you may leverage those identities to get you to still other sites. And if any of those are compromised, perhaps the compromisers may then assume your identity in ways you haven’t considered.

It’s one of the arguments AGAINST single sign-on: if just that one portal credential is hacked, then every application in your SSO circle can be infiltrated. Okay, so if your Facebook account is hacked, everything you access via FB is vulnerable.

This is why we employ multi-factor, right? Oh, that’s your FB token? Cool. But which IP address are you using? Or which device?

Because of cloud and federated partnerships, we are asked to trust an increasing number of authentication sources. But we should do so only if we see the critical business need. And then we should still dictate at least some of the terms. If someone says, “Trust me,” we should reply with, “Yeah, okay, just give me a good reason.”