Archive

Posts Tagged ‘ad’

Policy Translation – The Art of Access Control Transcends RBAC, ABAC, etc.

After some holidays, lots of internal meetings, and some insane travel schedules, things are settling back down this week just in time for me to head to TEC. So I can get back to spending time with Quest’s customers, partners, and having great discussions with people. In the last week, I had three excellent conversations, one with a panel of folks moderated by Martin Kuppinger from Kuppinger & Cole set up by ETM [link to podcast site], another with Don Jones and an audience of folks asking questions set up by redmondmag.com [link to webcast], and the third just today with Randy Franklin Smith [link to webinar site]. All these discussions revolved around managing identity (of course); they focused on the business’s view of IAM, wrapping proper security controls around Active Directory, and controlling privileged user access, respectively. Even though the subjects seemed quite far apart, a common question emerged: how do you translate the policy the business has in mind (or the auditor has in mind) into something actionable which can be enforced through a technical control? Put another way, the problem is how to take wishes expressed in business terms and make the come true with technology. To me, this is the central question in the IAM world. We have many ways to enforce controls, many ways to create compound rules, many ways to record and manage policies. But the jump from a policy to a rule is the tricky bit.

Let’s take an example and see what we can do with it. Everyone in the US and many around the world know SOX, and most that know it are familiar with section 404. There is a great wikipedia article about SOX section 404 if you want to brush up. Section 404 makes the statement that it is “the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting.” While this makes sense, it’s hardly actionable. And businesses in the US have relied on many layers of committees and associations to distill this. What is that process? It’s lawyers and similarly minded folks figuring out what executives can be charged for if they don’t do things correctly in the face of vague statements like the one above. So they come up with less and less vague statements until they have something they feel is actionable. Of course, what they feel is actionable and what some specific IT department sees as actionable may be quite different.

From the filtering at the high levels of the interbusiness activities you get a statement like “Understand the flow of transactions, including IT aspects, sufficient enough to identify points at which a misstatement could arise,” which comes from the work done by the SEC and POCAB to interpret SOX section 404. That approaches something IT can dig into, but it’s hardly actionable as is. But now a business can take that, bring it inside the organization, and have their executive management and IT work out what it means to them. Of course, there are scads of consultancies, vendors, and others who would love to assist there. Your results may vary when it comes to those folks, or your own folks, being able to make these statements more or less actionable. With this specific statement about the “flow” of data and not allowing “misstatement” to arise, there is general agreement that having IT staff with administrative powers that could, in theory, alter financial data is a risk that needs to have a control. And from that general agreement has risen an entire market for privileged access management products that allow you to restrict people who need administrative rights to do operational tasks in IT infrastructure from using those rights to somehow change data that would be used in any kind of financial reporting (or use that access to do any number of other things covered by other sections of SOX or other regulations like PCI, etc.).

What should be apparent is that things like RBAC, ABAC, and rules based approaches to access control are all simple and straightforward when compared to taking policy and making it actionable. Putting an RBAC system into place is taking action. But, as anyone who has been through an RBAC roll out will tell you, the hardest bit is figuring out the roles. And figuring out the roles is all about interpreting policies. So what is the answer for all those folks on these webcasts who wanted to know how to master this art? The short answer is like the old joke about how you get to Carnegie Hall: practice. The medium length answer is to find a consultancy and a vendor that you trust and that have had the right amount of practice and make them do it for you. The long answer is to follow the path I took above trying to explain the question. You need to analyze the requirements, break them down, and keep doing that until you start getting statements that look slightly actionable. Of course, that takes a huge amount of resources, as evidenced by all the money that’s been spent on SOX alone in the US (that same wikipedia article quotes one study that says the cost may have been 1.7 trillion USD). And the final trick is to take your actions and breakdowns back to the top, your auditor or CISO or whomever started the chain, and validate them. That’s a step that gets skipped all too often. And then you see million dollar projects fail with one stroke of an auditor’s pen.

Identity Myth: SSO is Hard; Truth: Old Apps Suck

December 1, 2010 Leave a comment

I sat down with a very smart group of folks and they were saying how they think SSO is very, very hard. If your world is all Active Directory (AD), it’s easy. But that is true in a tiny percent of the world. Everywhere there is some odd ball application and in most places there are just as many applications not using AD as there are using it (even if they buy Quest solutions, sadly). The cloud, something everyone is forced to mention in every tech blog post, also complicates this. How do you do SSO when the identities aren’t under your control? Or, reverse that, how do you get SSO from your cloud vendor when your on premise applications aren’t under their control? But every time I have the SSO conversation at length with people the conclusion is always the same. If all you have are applications from the last 10 years and some cloud stuff, there are approaches, including Quest’s, that can fully solve that problem. You can integrate into your commodity AD authentication, put up SSO portals, or use widely adopted standards like SAML – or all of the above in a clever combination. Even thick client GUI applications can be tamed with enterprise SSO (ESSO) solutions at the desktop. The things that always end up falling through all the cracks are older applications. Things that are often the crown jewels of the business. Applications that are so old because they are so critical that no one can touch them without huge impact to the business. But the older technologies resist almost every attempt to bring them under control. Even ESSO, which is the catch all for so many other laggards, can’t tame many of the odd green screens, complex multi field authentications, or other odd things that some of these applications demand at the login event. When I’ve spoken to our SSO customers, they always seem happy with 70-80% adoption on their SSO projects. They know they will never get that last group until the applications change. But there doesn’t seem to be any compelling event for those applications to be changed. So SSO continues to seem hard, but we all know that’s not exactly true.

ghosts of the interscaler directory at #cat10; let’s do it!

There were a lot of points at Catalyst 2010 where Kim Cameron’s Interscaler, Federated Directory and Identity Schema came up in my mind, though went unmentioned by the speakers. I know I wasn’t alone, either. It was there like a ghost in every discussion. When Anil John spoke about Background Attribute Exchange (BAE), one of the first questions was about how to ensure schemas would be in sync. When Nishant Kaushik spoke about federated provisioning, again questions had everyone talking about how directories would be able to rely on attributes being “exchangeable” across domains. And when the folks from GM gave their talk the second or third question was about how they decided what attributes would be included in their avatar identities and which would not.

How does this move forward? I get dizzy when I look at all the standards bodies around identity. I’ve got a lot of energy to offer around this and don’t know where to push it. It’s not about a product or a vendor. I’d like to see this be an industry thing that everyone can benefit from.

#eic10 part 1, 2010 an interstellar odyssey -or- the directory monolith

No one knows how to make a big proclamation in the identity world like Kim Cameron. His keynote at #eic10, the Kuppinger Cole European Identity Conference for 2010, was no disappointment. Kim reviewed his ideas for the “Federated Interscaler Directory”, which was often misquoted as saying “Interstellar”. The basic idea was to “extend” the current ubiquitous Active Directory platform to hold a more flexible framework for relationship expression, policy enforcement and other elements that directories of today are missing. While adding all that, this new directory platform should also scale, in the sense that it could administer millions of identities, as well as support advanced features like federation, token translation and other things that are clearly becoming part of next gen identity.

On it’s surface, that all sounds nice. But it also sounds dangerous to me. One other theme at #eic10 throughout many talks, and something Kim even said during his, was that we shouldn’t want identity systems to be monolithic (he said so in reference to the ability to federate with other IdP’s outside the directory itself). But the system Kim described and the picture he used to illustrate it looked pretty monolithic to me. A lot of what he described is possible today already with a loose federation of platforms from many vendors and open source projects. You can enforce all the policy you need with a XACML authorization engine and properly tooled interfaces and proxies for applications and providers. You can manipulate schemas and the objects they serve up as needed with virtual directories. If Microsoft were to make AD into one big solution for all that, then the biggest differentiator would be having its monolithic status versus the loose coupling of many other components. I tend to be a fan of loose couplings, but I’ll keep the jury out until I see more from Kim.

One thing that I really liked was Kim’s call for everyone to work together on a common identity schema. It’s not the first time he’s done so. At PDC he made a great presentation that described the same idea in much greater detail [link to the PPTX Powerpoint file from PDC]. A project of this kind, if well done, could solve many, many interoperability and operational challenges in the identity world. So much time is spent now negotiating, either in research or in calls at run time, to figure out what attributes and properties of an identity are available. If there were a completely standard schema and a means to publish it easily, then that goes away.

I’ll have more thoughts from the conference later.  For now I’m going to put on my space suit and leave the Microsoft ship and hope Kim hasn’t locked the bay doors when I get back.

#TEC2010 thoughts

Last week was #TEC2010. It was my second year at the event, and I was again stunned by the unique vibe it has. Since TEC is focused on education for the folks in the trenches of managing directories, the crowd is markedly different from many other events I attend. There were some senior management types around, mostly owing to the Microsoft centered nature of the event and their shops being very heavily Microsoft focused. The vast majority were people who architect, deploy and maintain directories, though. And it was far from just Microsoft directories. I heard every type of directory mentioned by the folks in the crowds, from RACF to Novell.

One of the main highlights for me was Conrad Bayer‘s keynote about Active Directory and the future of identity services at Microsoft. It was very refreshing to hear someone from the top of the technology food chain at Microsoft saying a lot of things that have been true for a while. Conrad directly acknowledged the breakdown in the concept of using structured hierarchy to represent the relationships between identities and organizations in today’s world. He also gave a nod to the difficulties there are with peer-to-peer federation approaches, though he said ease of use should mitigate that, which I do not agree with. He also pointed out the competitive advantage Microsoft sees in RMS when compared to other identity vendors. I found that odd, but very interesting. Lastly he called out that most clients he speaks with thinks that identity is one of the last things they would move to the cloud, which is something I hear a lot as well.

The other session I enjoyed very much was Brian Puhl‘s. Brian is from Microsoft’s own MSIT division and is in charge of identity services. As he put it, his job is “dog fooding” – using what Microsoft makes for Microsoft’s benefit. Likely the most notable thing about the entire presentation and discussion that followed to me was that the word authorization was in the title and never once did the term XACML make its way into the chatter. At points I got the feeling there was some very complicated mental gymnastics going on to avoid the idea that policy expression needs a platform and protocol. At one point Brian said point-blank “my hosting provider needs to give me a mechanism to express the complexity and facets of my required policies”. I almost coughed out “XACML”, but held it back. Two observation Brian made that struck me as totally true were that trust (and policy) often boils down to contracts and that key management is every bit as important and encryption itself. These are two lessons that only someone who has had to wrestle with lawyers or exotic devices’ key renewal protocols would be able to offer.

By far, the best part of the conference was speaking to the hundreds of fellow attendees – and this year I was thankfully just an attendee so I had no booth duty to distract from the fun. I had conversations with the world’s largest banks, small law firms, government affiliated agencies who remained nameless and everything in between. Every one of them had backlogs of issues they were looking to get ideas on, and the peer level advice flying around was worth it’s weight in platinum. If only there was a good way to bottle that – that would be something we could all use.

AD Bridging gets respect at Burton’s Catalyst09

day two at catalyst09 was very on target for me. the identity track was all about leveraging existing resources for bigger ROI and that’s all we ever talk about in PM meetings around here. Burton’s Mark Diodati presented about the AD Bridge space, a name he may have invented, and then there was also a customer case about the practice of doing AD Bridging for Unix, Mac and Linux systems. the best part was when a person in the audience took the mic during Q&A and thanked Mark and Burton for taking the AD Bridge products seriously and the whole audience erupted in applause.

i’ve got lots of notes and thoughts about everything that went on. i’ll likely be posting reactions to catalyst09 over the next week.

stuck in the middle with you

last week i was at a meeting at one of the financials, and it was no surprise that they want to talk hard cost cutting. they want to get everything they can onto their low cost, well run MSFT platforms. at the meeting are myself and the account manager who brought me in as well as another sales rep and their accompanying talking head. it must be fun for clients to schedule dueling consultants. i know i would in their shoes.

everyone was on the same page at the start. the topic was how to get their LDAP user stores into either AD or ADAM as easily as they can. they were reserving the choice between AD or ADAM for later. the conversation strayed a bit and we were talking about how they also wanted to get SSO for their external users out of this if they could. the other consultant kept dismissing my claims that they were going to have to go through a transition period due to their stated need to keep some users on LDAP longer than others. it went in circles until i asked him to lay out his plan. “First,” he said “you move everyone to ADAM”. the head architect from the client and i smiled at each other.

wasn’t the point that they could not just “move everyone to ADAM”? so many people seem to miss the part in the middle where both the old and the new have to work together for a while. and if you can’t see that, then you’re not seeing the real problem. if we could just snap our fingers and put everyone on shiny new tech all the time, shops like QSFT would be out of business. it’s all the hard parts that people get stuck on in the middle of these projects that make it interesting…

Categories: iam Tags: , , , ,
%d bloggers like this: