You are currently browsing the Identity category
Updated below. And as a reminder, this is my personal blog, and I don’t pretend to represent the views of my employer, Novell.
With Oracle acquiring Bridgestream and now Sun acquiring Vaau, I know all of you are asking yourselves “I wonder what Bob thinks about this?”.
No? Well, I’m going to tell you anyway.
Novell decided earlier this year to develop our own roles module, which you might think killed any chances of us partnering with third party RBAC vendors, but not so. Just last month we conducted a joint project with Eurekify, a relationship that both sides are looking to expand. So why would we develop a roles module in-house instead of acquiring an existing vendor? And once down this path, why still partner with Eurekify?
There are two distinct pieces to RBAC software. First is the software that computes user privileges based on roles and provisions them. This functionality requires a very specialized database that is highly tuned for performance in a rather narrow set of tasks dealing with identities and entitlements. We call this specialized database a directory, and Novell happens to have one. For role-based provisioning to work effectively, it needs to be built on a directory. Acquiring a third party product and integrating it into an existing directory requires a massive re-write. So we didn’t do it. (Actually we did acquire some third party RBAC software that was already built on top of eDirectory, and have been enhancing from there.)
The second piece of RBAC software is the roles mining and analysis that supports the development of optimal role definitions. This functionality requires a lot of ad hoc queries and computations based on matching many different pieces of data. This workload has a very different profile from the straight role-based provisioning, and requires the flexibility of a relational database.
Vaau, Bridgestream and Novell’s roles module all support the first category. Vaau and Bridgestream are trying to also compete in this second category, but they are playing catch-up. The clear leader in role mining and analysis is Eurekify.
Vaau and Bridgestream are trying to be all things to all people, but they will face the challenge of, on the one hand, integrating with Sun’s/Oracle’s directories to support role-based provisioning, and on the other hand, trying to expand the analytical capabilities that can only be built on top of a relational database. They’ll be busy for awhile.
Meanwhile, Novell is not trying to pretend we compete in the role mining and analysis space. We are providing a highly tuned role-based provisioning capability based on eDirectory, and we will partner with Eurekify for the things a directory, and a directory company, can’t do well.
(Now, to kill any rumors, I know of no acquisition talks with Eurekify, or the lack thereof. I’m not being coy. I truly have absolutely no information that is not already in the public domain. Actually, I have less, since I’m sure there’s a lot that is public that I haven’t seen.)
So the Bridgestream and Vaau acquisitions are somewhat of a “me-too” strategy, matching Novell’s direction of integrating role-based provisioning into our IdM suite. But the acquisitions carry significant added challenges as well. And they preempt Oracle’s and Sun’s ability to partner with Eurekify for role mining and analysis, which given Eurekify’s leadership in this space, they may come to regret.
Update: Novell has announced our roles module, named the Roles Based Provisioning Module.
I’ve authored a whitepaper titled Smart Implementation of Role-Based Access Control now posted on the Novell Consulting web page. Here’s the blurb I provided to the web team:
Role-Based Access Control (RBAC) is an identity-based approach to provisioning and access control that can improve security and compliance, while at the same time reducing IT costs. Achieving these benefits, however, takes more than technology — it takes new business processes and a new way of thinking about access rights. Based on Novell Consulting’s experience implementing RBAC with our clients, this whitepaper describes our best practice approach to RBAC.
I understand that vendor whitepapers are a dime a dozen, but I really put some effort into creating some compelling content for anyone looking at implementing RBAC. Unlike so much that’s written these days on the topic, it’s based on real-world experience. But, you be the judge.
I also have a second whitepaper in the pipeline dealing with another of my areas of consulting experience: the economics of open source. Stay tuned.
§ February 8th, 2007 § Filed under Identity, Open Source Comments Off
Congratulations to all those in the OpenID world for Microsoft’s embrace of your efforts! It’s a great milestone not only for JanRain, Sxip, and Verisign, but also folks at NetMesh and SixApart not officially involved in the agreement.
It’s also a good deal for Microsoft, which is what seems to have gotten some hackles up. From Kim Cameron:
Here is Dick Hardt, CEO of SXIP, explaining our joint announcement on OpenID and CardSpace to people in the community who may worry that Starship Microsoft is about to land on OpenID and squish it.
This morning Microsoft announced they would support OpenID in future identity server products. Although this is a huge endorsement for OpenID, there will likely be many people that are fearful of what Microsoft’s involvement may do to OpenID.
[...]
I look forward to bridging the Microsoft and OpenID worlds today. The team at Microsoft get what we are doing in OpenID, and want to enable their technology to take advantage of the reach of OpenID, as well as enable the OpenID community to take advantage of CardSpace technology. This looks like a win-win for everybody.
[...]
Let me say something about potential squishing. It just won’t happen. One of the best things about OpenID is its organic quality, and the last thing we want to do is interfere with that.
Also via Kim, some commentary from Scott Kveton at JanRain:
There are a couple of points I’d like to make outside of the above announcement to hopefully address any concerns that the OpenID community might have:
- JanRain will never require users of our libraries or services to use Windows CardSpace ™. We offer support for this technology as another option for users much like using our Safe SignIn and Personal Icon technologies on MyOpenID.com. We’ll also continue to support the OpenID efforts going on with Mozilla and Firefox.
- Windows CardSpace â„¢ is shipping with Vista today and is a well thought-out technology that helps address many of the privacy and security concerns that people have had with OpenID. OpenID helps users describe their identity across many sites in a public fashion. The two together are very complimentary products and each has its strength.
- Microsoft did not cave in to the OpenID community and the OpenID community is giving nothing up to Microsoft. This is a collaboration on bringing the best technology to the marketplace as quickly as possible to help secure users and solve the single sign-on solution once and for all.
- Please reserve judgment on what this all means until you see it all work together. The technology is really quite simple and the ramifications for end-users is huge. It also goes a very long way to completely addressing the phishing concerns we’ve heard so much about.
Why is it that any collaboration or cooperation with Microsoft is immediately greeted with suspicion, paranoia and a sense of betrayal? Well, actually, I know why, but is it still justified? My employer, Novell, is still getting hammered by those convinced we sold our corporate soul to the devil when we signed a deal with Microsoft. Matt Asay, who is otherwise a thoughtful commentator on all things open source, said at the time the deal was announced that “Novell got duped.” Daniel Lyons at Forbes said:
Microsoft has done this many times before, so often that Redmond has a name for the technique: embrace, extend and exterminate. And yet people keep doing these deals. Usually, it’s weak, struggling, desperate companies with declining market share and little hope of turning things around. In other words, just like Novell.
But the consensus among those of us within Novell working on the front lines post-Microsoft-deal is that it is unquestionably a good thing for Novell, our customers, and the open source community. And so I believe the assurances of those involved that the Microsoft-OpenID deal will turn out similarly.
Now, none of this is to say that there is a new reformed Microsoft today that only wants to share the love with the rest of the industry. But I think these deals reflect the fact that Microsoft is not omnipotent. Bottom-up community-driven efforts can reach a tipping point, where Microsoft needs the community as much as the community needs Microsoft. I think this is true of OpenID as well as Linux.
*”Best Friends Forever.” In case you’re not a South Park fan, see here.
I have installed a plug-in for WordPress that enables commenters (and bloggers) to log in using an OpenID url. I’m using mylid.net as my identity provider, although of course there are plenty to choose from, and the blog should handle any provider seamlessly.
The plug-in seems to work pretty well as-is. Let me know if you run into any authentication or user interface issues.
Georg Greve of the FSF Europe has an article posted on Groklaw criticizing the Novell agreement to work with Microsoft on improving conversion between ODF and OpenXML. (He also provides a follow up to various comments posted to Groklaw.)
My concern with his discussion is the same I have with much of the free software agenda: he is expecting open source users to accomplish via individual actions what can only be accomplished via political action. This puts the burden on those least able to effect any sea change, while dodging the hard work of lobbying to enact legislation.
I have been living inbetween the Microsoft Office vs. OpenOffice.org battle lines for several years now. As a consultant to big business and big government, I don’t have the luxury of ideological purity. When we are conducting an open source assessment and strategy, it’s understood that we will provide the client a deliverable in ODF. To do anything else would be undercutting our whole message.
But when we are conducting an identity management or resource management engagement, the client may not have bought into open source at all, and doesn’t really care about anything other than being able to read, distribute and re-use our deliverables. We can provide them a pdf document from OpenOffice, but clients typically want to take our slide deck and repurpose it for their own use. It is in our interest that they be able to do so, since we want them to present our recommendations to their executives to get approval to move forward. Regrettably, 9 times out of 10 they want the deliverable in MS Office format. We have little ability and even less incentive to insist otherwise, since after all, they are the customer.
This presents a dilemma. If we know we are going to have to provide a deliverable in MS Office format, and since the conversion from OpenOffice to MS Office isn’t always perfect, do we develop the document in OpenOffice and clean up the conversion, or do we develop it in MS Office (running in VMWare or WINE) to start with? I take the first route, but this imposes a cost, especially if I have to repeatedly revise the deliverable.
This is the real world I live in. Greve isn’t providing me with any practical solutions. For example:
As several people have pointed out, constructively supporting the use, spread, adoption and legislation for truly Open Standards, such as the Open Document Format (ODF), is one of the most useful things people can do. This includes using ODF yourself for cooperating online with others, as this LWN.net comment proposes.
Funny enough, all of this brings to mind RMS’ essay We Can Put an End to Word Attachments of 2002, only that it would need updating to recommend the Open Document Format, boiling down to: I am very sorry, but I could not read your attachment because it was saved in a format that my office could not read. Could you please resend the document in the universal document format “Open Document Format” (ODF), the international ISO standard for document exchange?
Naturally the message should be adapted to the situation, recipient and context in order to have the right tone. If people feel attacked or criticised for having used the “wrong” format, such reminders may end up being counterproductive. But discarding the possibility of changing social habits is no less counterproductive, and ignores evidence to the contrary: Just ask all the people who are now sorting their garbage for recycling and compare that to the position they took 30 years ago.
I’m sorry, but this is terrible advice. It won’t work in the business world, and especially not when dealing with customers. It is simply preposterous to expect an MS Office user in corporate America to change their office software because I refuse to read their document.
However, Greve’s comment that we should support legislation is right on target. This is an issue that can only be pursued politically. I think the argument is best made by a commenter quoted by Greve:
I don’t, however, think that it’s inappropriate to ask a vendor to change their software to comply with a standard. Do we seriously give MS Office the standing of a national language? The standing of English, or French, or Spanish, or Chinese, or Japanese? Do we really have no right, in the standards process, to ask Microsoft to change their software? Well, not so much change their software, but to implement the standard the other way around – for MS Office to implement the standard, not for the standard to implement MS Office, which is obviously why it’s 4000+ pages, and getting bigger.
Legislation needs to catch up with the technology. A huge percentage of the world’s artifacts are contained in office documents. Who is going to define this lingua franca, Microsoft or a global standards body?
Greve is pessimistic on this front:
The criteria of what constitutes an Open Standard are under permanent debate in various regions of the world and generally conclude at a set of principles that should be adhered to, but mostly without compliance checking.
The OpenXML specification was written to fulfill these criteria in theory, but in reality, will it prevent Open Standards? If so, it will undermine the expressed will of the political debate, which was intended to serve interoperability.
But understanding this and reaching a correct conclusion requires some grasp of technology, and the apparent strategy behind OpenXML obviously counts on the fact that politicians either are isolated from technology or not interested in the technological background and will apply a “the truth must be somewhere in the middle” approach instead of considering the technical facts.
The result of this then is the “mistaken salomonian solution” of accepting both ODF and OpenXML as sufficiently Open Standards, which is no solution, at all.
However, Greve has provided all of the compelling arguments why the salomonian solution (or is it Solomonian?) is unacceptable. We need to make this argument with our legislatures, not give in to defeat out of a belief that legislators won’t understand technical issues.
But in the meantime, here in the real world, I only ask for one thing: an incrementally better conversion between OpenOffice and MS Office so I can continue to use OpenOffice while giving clients what they ask for. OpenOffice doesn’t have to implement all 6,000 pages of the OpenXML standard. It just has to improve its existing conversion to make it “good enough”. Then let standards legislation and the vastly superior economics of OpenOffice do the rest.
Via Dave Kearns, I learn of the Open Media Commons project sponsored by Sun whose goal is to “develop open, royalty-free digital rights management and codec solutions.” I’m all for that. While DRM raises the hackles of many, I think it’s necessary to enable various business models for content creators.
I’m a bit confused, however, by some of the use cases published by the Open Media Commons. Dave has a link to this slide deck (pdf), which he quotes from in his newsletter. The use cases include one controlling health care worker access to patient medical records, and another for corporate user access to enterprise reporting. If this is DRM, then how does DRM differ from identity management?
I admit I’m not totally up on DRM, but I have always seen digital rights management as a mechanism to embed access control into a media file. That media file could be text, a spreadsheet, software, audio, video or graphics, but the file carries with it its own authentication and authorization. This is very different from a typical enterprise identity management scenario, where access to data (and application functionality) is controlled externally to the report or document produced. So in the electronic medical record apps I’m aware of, access to patient records is controlled by the EMR system itself (plus perhaps an identity management infrastructure) external to the patient record. The same is even more true for an enterprise reporting system. So Sun’s description of these use cases as “DRM” just doesn’t seem accurate to me.
Having said this, I can see an application of DRM to the patient record use case, but in a way that perhaps was intended but not spelled out in the Sun document. If my medical record is recorded in a chip inserted in my shoulder, and I turn up unconscious in an emergency room, I would want the ER staff to be able to access the medical record. However, I wouldn’t want someone standing behind me in line at the supermarket to access my medical record by scanning the chip without my knowledge. Hence, the medical record would require DRM to authenticate that the person accessing it is a health care worker in the absence of any external IdM system (and in the absence of my ability to approve the access.) If this is what the Sun folks have in mind, then I’m totally on board. (I still don’t get the corporate reporting use case, though.)
A final area of confusion for me is Sun’s “fair use” use case. They make it sound as though fair use requires the copyright-holder’s approval and authorization. Now, IANAL (I am not a lawyer), but my understanding is that fair use is a right granted by the laws of the United States (and other countries I presume) and does not rely on the granting of permission by the copyright-holder. I can satirize, parody or critique any publication or speech by anyone, and in so doing quote directly from the copyrighted material, without authorization from the author. Requiring an author to grant a fair use “license” up-front would, it seems to me, violate the whole intent of fair use law.
If Dave Kearns, any of the Open Media Commons folks, or anyone else can clear this up for me, I’d appreciate it!
The ANSI RBAC standard is incomplete. There, I’ve said it. The RBAC inquisition can torture me all they want, but I won’t recant. I’m sticking to my heretical view.
ANSI/INCITS 359-2004, originally crafted by NIST, defines the logical construct for role-based access control, and has become holy writ for those of us going down the RBAC path. I recently talked about an additional object not part of the RBAC model, and got pushback from some colleagues because it’s not part of the canonical NIST scripture, so to speak. So let me lay out my case for this heresy.
The RBAC model shows users related to roles, which are related to permissions. At the time of execution, this is all that’s necessary: if the user is a member of a role that provides the appropriate permission, access is granted. But this model is not sufficient for the engineering of roles up-front.
An enterprise has a set of users, each of whom is entitled to a set of permissions. We want to define a set of roles that will aggregate permissions in a way that is useful to the business and reflects the way the business operates. We can start this task by creating a permissions matrix with all users listed down the side, and all permissions listed across the top, and a binary indicator in each cell showing whether this user is entitled to this permission or not.
This is quite a matrix. Besides it’s size, it has a few drawbacks. For role engineering, we don’t care which users have certain permissions, but we do care why certain users have certain permissions. We want to be able to automatically provision/deprovision users to roles based on their identity attributes. User ID or user name are irrelevant, but the profile of the user’s identity attributes, such as job title, job code, location code etc. (assuming they’re an employee) are very relevant.
As I’ve written before, there are two domains to the role engineering problem: a) mapping permissions to roles and b) mapping users to roles. A user-permission matrix may help for the first, but it won’t for the second. And it is more unwieldy than it needs to be even for the first problem domain.
All we really care about for role engineering is defining roles that will cover each unique combination of values for the identity attributes. This set of unique-combination-of-identity-attribute-values represents the provisioning requirements that need to be supported by roles. While “unique-combination-of-identity-attribute-values” does seem to roll right off the tongue, I have been using a different term: job. Granted, this term really only works for internal users, excluding customers, partners or other external users. But at least for internal users, this term is descriptive, and doesn’t require a lot of explanation to the layperson.
We don’t care if 1,000 employees have a single job, or one (at least initially). The job is entitled to a set of permissions for which roles must be defined. In fact, another way to think of the job object is as a unique combination of permissions. (If we have perfect identity data, these two definitions will give us the same result, but in practice we don’t, so they diverge a bit.)
So for the purposes of role engineering, we have a new object: users are related to jobs, which are related to roles, which are related to permissions. Once the roles and the user-to-role mapping rules have been defined, the job object can be bypassed.
So even though I too worship at the altar of the ANSI RBAC standard, I have come to add a new book to the RBAC bible. Just don’t burn me at the stake.
§ May 31st, 2006 § Filed under Identity Comments Off
A new political movement, dubbed Unity08, has been started to target Republican and Democratic moderates repelled by the polarizing political climate we find ourselves in. It’s an intriguing idea, but alas this is not a political blog, so I’ll leave it to others to comment on the politics of it all. What interested me was the second of Unity08’s three goals:
Goal Two is for the people themselves to pick that Unity Ticket in the first half of 2008 – via a virtual and secure online convention in which all American voters will be qualified to vote.
They are planning to utilize e-voting on a national scale! Granted, this is not a government election, but given that the results would likely end up in the courts if in dispute, it still must be beyond reproach. Voters will need to be registered online, their registration information independently validated, and their identities securely authenticated. The ballots will need to be auditable and non-repudiatable. Unity08 is hoping for 20 million voters to support their candidate, so this will be no small task!
E-voting has been in use in Europe on a small scale, but to my knowledge nothing has been attempted of this scale before. I wonder whether the Unity08 founders appreciate the identity management challenge they will be facing.
I suppose they can avoid some of the complexity by dumbing the whole thing down so that it is closer to voting for American Idol, or an election in Florida, rather than a certified one-vote-per-voter election. But I hope they don’t. I would love to see someone tackle these tough challenges and pull off a national e-vote in the U.S. It could change the face of democracy forever.
A simple explanation for my lack of blogging — Novell, or at least my little corner of Novell, has been extremely busy. And busy is good. I have been doing a lot of consulting work around RBAC and role definition, and will share some of our learnings in this and a few future posts.
The whole role definition problem in RBAC actually has two aspects: 1) determining the entitlements that belong in a role, and 2) defining a set of rules for assigning identities memberships in a role. Both pieces of the problem have to be solved simultaneously to come up with a useful set of roles, but the first seems to get more of the mindshare. But for now, let me address the second.
Without role membership rules that can be automated, we are left manually assigning users to roles. RBAC is still valuable in this scenario, since we are manually provisioning bundles of entitlements instead of individual entitlements. More importantly, we are codifying a set of access policies in the form of the role construct. But we are missing out on a significant cost reduction and risk mitigation opportuniity if we don’t specify role membership rules. These rules automate provisioning in the RBAC world, and codify a second set of security policies at the same time — which employees are supposed to get access to what.
The problem is that the correlation between identity attributes (normally sourced from the HRIS) and the “to-be” role memberships is often pretty weak. We have begun using two metrics to measure the “fit” of proposed membership rules to roles. The first is coverage, which represents the amount of the desired role population that can be identified by a set of membership rules.
A proposed set of rules for role membership, based on identity attributes, will provide a set of true positives, i.e. a set of identities that are correctly specified as members of a role. But the rules may also specify a set of false positives, or a set of identities that the rules indicate should be placed in the role, but in fact have no need for the entitlements contained in the role. The rules may miss some identities that should get the role but don’t — these are false negatives. Then there are the identities that don’t get the role, and shouldn’t, i.e. the true negatives.
Coverage is the ratio between the number of users correctly identified by the membership rules and the total number of users that should get the role:
coverage = true positives/(true positives + false negatives)
It’s nice if coverage is 100%, but anything above zero is a good thing, since it represents provisioning that can be automated.
The second metric is accuracy, which represents the percentage of identities specified by the membership rules that truly should get the role:
accuracy = true positives/(true positives + false positives)
An accuracy less than 100% is more problematic than a coverage less than 100%, since any false positives represent a violation of the least privileges principle. Still, a set of rules that include errors may be of value. Identities that are identified by these membership rules can have an automated provisioning workflow request created which can then be sent off for approval. The approver must sift out those that really need the role and those that don’t. However, since the request is created automatically, no one has to remember to create the request, and the cycle time will be shorter than in an entirely manual process.
So accuracy and coverage have become our key metrics for deciding to what extent we can automate the placing of identities in roles. Feedback is welcome!
§ March 1st, 2006 § Filed under Identity, Web 2.0 Comments Off
My employer’s announcement, with IBM et al, of Higgins is of course very cool. While it got played up in the press as a rival to Microsoft’s InfoCard, fortunately that spin has been ably and thoroughly debunked.
Everyone describes Kim Cameron as someone wanting to do what’s right for all of us, not just for Microsoft, and I’m sure that’s true. I can’t help, though, but look at it from Ballmer’s or Gates’ perspective…why interoperate with another OS vendor? Why not keep it all closed, distribute InfoCard with Vista, and take over the identity layer of web 2.0?
I think it’s because Microsoft execs understand that their world is changing.
The desktop OS market has long been a natural monopoly, similar to power distribution, water and sewage, and (until a few years ago) telephones. Just as there is a great dis-economy to having two power grids, two sets of water and sewage mains or two telephone lines into your house, there has been a huge dis-economy to having two desktop operating systems. Regardless of any technical merit, the world largely settled on DOS and Windows as the common desktop platform because, at least for the enterprise customer, it was too expensive not to conform. And of course Microsoft has succeeded by leveraging the natural monopoly in the operating system market into adjacent markets, themselves often a natural monopoly as well.
But as software moves from the desktop to the internet, the desktop will no longer be a natural monopoly. Users don’t have to run the same desktop OS to access SOA software on the web. Software developers don’t have to develop for a specific desktop platform — they can just develop for the web. The dis-economies of multiple desktop OSs is disappearing, thanks to open standards and SOA.
Regardless of what some may think of Ballmer and Gates, they understand the world as well as the rest of us. I suspect they’ve played out this scenario and have concluded that closing InfoCard off will not result in yet another Microsoft-dominated natural monopoly, but instead, a marginalized Microsoft. Since InfoCard couldn’t possibly achieve complete ubiquity as the sole identity provider, keeping InfoCard closed would result in Passport The Next Generation.
« Older Entries