Sunday, April 22, 2007
Take AIIM on Security
John Newton appropriately noted that the folks at AIIM are negligent in that they haven't figured out how enterprise security concerns should converge with ECM standards. He also noted that ECM vendors consider security as a second-class consideration. Hopefully, over time when industry analysts such as Alan Pelz-Sharpe of CMSWatch, Barry Murphy of Forrester, Nick Patience of the 451 Group and Karen Shegda of Gartner start covering security standards that are applicable to the ECM space within upcoming research reports.
Anyway, I figured I would comment on some wonderful things said by John:
- Trying to address security in some of the standards groups such as AIIM’s iECM initiative and JSR-283, the successor to JSR-170, has been politically tricky. It is difficult to figure out what a common view of security is given all of the different models of security such as Access Control List, Role-based Security and Policy-based Security used in Records Management, let alone all the different vendors’ implementations of each. However, looking at this problem going forward, without addressing and standardizing security, we are creating huge barriers to interoperability and not meeting the requirements of new models of interaction on the internet.
Interoperability is key which includes thinking about security considerations. ECM is no longer a standalone play and is starting to become integrated into enterprise applications. I suspect that Salesforce.com will deeply integrate ECM into CRM such that the user believes they are working with one tool and not two.
In terms of politics, I would love to understand whether this can be solved by having more enterprises participate in standards creation? Is it that the agenda is too driven by software vendors who have their own insular issues to deal with? Maybe instead of complaining, I should actively participate? John, could you put me in contact with the speaker coordinator for this event so I can personally address this issue?
In terms of whether it should be ACL, role-based or policy-based, I have the following thoughts. First, I believe that customers should think of which model best suites them by having the ability to configure which model works best. Second, I would also say that the better model supports an open SDK where customers if they aren't happy, can write their own.
- There needs to be a common way of addressing identity between different services whether those services are in the enterprise or outside. As we start to bring customers and partners into the process of serving themselves or helping us design new products and services, we can’t just rely on internal directory services. OpenID is the only standard that I am aware of that provides a neutral way of identifying users and is not dependent on any single vendor.
It seems as if many vendors in this space can leverage external authentication services but yet require their own identity services which is interesting at some level and flawed at another. Whether you choose OpenID because you want a vendor-neutral way of identifying users or something more proprietary such as CardSpace doesn't really matter much to me as long as you choose one and solve for this problem-space quickly. In terms of difficulty in implementation, it isn't that much code to actually support both at the same time.
- The big, looming problem in content is the fact that huge numbers of users are adding, accessing or updating an even larger number of pieces of content. This calls for a model that controls content through definition of context such as time, location, metadata or role. XACML could very well fit this model. However, users need to understand this model as they set up the controls on the content.
If the industry embraces XACML, the enforcement could occur based on inspecting meta-data which does require enterprises to pay attention to controls on the content. I suspect that you are fearful in proposing this since many customers don't really have a sound, thoughtful metadata strategy and therefore it may fail for other reasons.
- Identity is not sufficient for determining roles or entitlements. There needs to be a more open way of integrating multiple directories without revealing sensitive information. This is the same problem we are trying to solve for content and directories need the same mechanism to define access.
May I say that pass-through authentication approaches are also inadequate in that it sometimes becomes important to understand the credentials especially once we move away from username/password like constructs?
- As search becomes increasingly federated, such as through the OpenSearch API, managing identity and entitlements on content becomes very problematic. The search sources should filter out any content to which the user doesn’t have access. However, that requires some cooperation with the software that is doing the aggregating and the content sources. ECM systems will probably control the most sensitive information, but this will need to be aggregated with public sources as well to create effective search applications for the enterprise.
Should search leverage the same entitlements model? If search engines also supported XACML then having a layer that externalizes so as to make consistent would be a good thing.
- If you are at AIIM, bring the issue in relevant sessions. I don’t have all the answers nor does any vendor. People in the middle of this problem like James can help by bringing up their use cases. If we start asking the questions, then perhaps we can collaboratively answer the questions and solve this problem. If you think standardizing this is hard, try imagining building next generation systems without standardizing these security needs.
John, I can tell you that enterprises such as AIG, Home Depot, Merck, J&J, Boeing, Washington Mutual, Bank of America, GE, Schwab and Merrill Lynch have all started to have this conversation in a public way and have started to engage the discussion at many industry analyst driven conferences as a first step. I can also say that if vendors would like for me to share additional insights, all they have to do is ask...