Seems to be a fair bit of hype and marketing about the supposed "new" area of Identity Management called "Entitlement Management" and a particular startup called Securent. InternetNews.com, NetworkWorld and DigitalIDWorld (to name a few) have all talked about it as being the "new frontier" even suggesting that Securent is the only startup in this area.
I beg to differ and I'd be willing to bet any vendor or startup out there dealing in network or application access control will no doubt have something to say about that. It's just that it hasn't been marketed well enough in the past. This type of "entitlement management" technology has been around for YEARS. In fact, many of the access management products on the market are built on this type of idea and most offer APIs to allow the externalisation of entitlements. The only thing missing with many of the existing products out there is an XACML interface into them - and I dare say this is being rectified in a hurry.
All the hype-mongers out there should look a little deeper into the solutions out there before "announcing" the arrival of the "next big NEW technologies" and further adding to the hype. Perhaps organisations are starting to take a look at "entitlement management", but it's not new. The only thing that's happening at the moment is that marketing is catching up with the technology. Maybe the marketing departments have leaped on this concept as the next thing to go after because most of the other areas have been marketed to death.
It kind of makes sense because vendors are now beginning to work their way down the application stack in the identity space. Perhaps market research has also helped determine that the security maturity lifecycle of organisations is at this stage in their identity and access implementations. Regardless of the reason, the industry seems to have reached the point where it makes sense to specifically market fine-grained authorisation as a key component. In the past, this was simply "value-add".
InternetNews.com goes so far as saying some vendors don't have solutions in the "entitlement management" space and singles out IBM in particular. The writer of that article should really do his research a bit better. I have a tip for him - go read up on IBM Tivoli Access Manager.
5 comments:
Ian, you are right that the need for Entitlement Management while not itself new has a number of new, compelling drivers. One of these is the fact that customers who have deployed IAM tools are finding that they are good for some things but lack the fine-grained access policies and ability to easily connect with existing repositories and attribute stores outside of the applications. BTW, before I founded Securent I did look long and hard at the existing IAM tools believing that surely they must have solved this old problem. I found that they don't.
Let me give you an exercise to confirm this for yourself. Please use your favorite IAM tool (presumably Tivoli) and show me how you would configure, enforce, and audit a simple policy: NY analysts cannot open an IM session with EMEA brokers. And for additional credit, please confirm that you can configure, enforce, and audit an equally simple policy: NY analysts cannot communicate with EMEA brokers over any communication channel. Of course you are expected to do this at very high performance, over widely distributed and heterogenous communication servers, provide on-demand review of the policies, and without writing any code (you can assume that you have an integration with the communication servers to instruct them what policy decision to enforce).
You can reach me at rgupta@securent.net.
Rajiv, appreciate you taking the time to discuss this. I did not mean to single Securent out specifically. I'm sure you have a very good product and have differentiation points that make your solution better for certain customers than the other vendors out there (as such, I'm very interested in finding out more about your solution). I was simply making the following points:
1) Entitlement Management has been around for awhile (you kindly acknowledged this).
2) There are other Entitlement Management solutions on the market.
I used IBM as an example because the article in question named IBM as not having such a solution, so I was just pointing out that this was not the case. The other large vendors also have similar solutions (some better than others).
Architecturally, access/entitlement management products are similar to your product. There's usually an administration point, central policy engine, an auditing engine and distributed policy enforcement points that communicate with the central policy engine to subscribe to changes in security policies. All that needs to happen is for CIOs or decision makers to mandate that applications across their environments leverage the centralised policy/entitlement solution in place (and obviously for the development and operational teams to adhere to the mandate). In my experience, many do not hence the lack of proper entitlement management integration and practices within organisations.
I don't particularly want to get into a feature/function discussion because those go on forever and we're usually no better for it. I can't really comment on feature/function differences either because I do not know about your product (as I said, I'm interested in finding out more about it).
To answer your question/exercise, there are many ways to do it depending on the flexibility of the product in question. I'll use the following as an example of how it could be done in one of the existing products out there:
NY analysts would be a role/group. EMEA brokers another role/group. Both easily created. You would then have to create the relevant objects within the policy engine corresponding to "IM sessions" and objects for each type of communication channel (could be VOIP, email, IM or even TCP/IP depending on how specific or granular we want to get). Typically, access control lists (ACLs) would play some part in linking all these objects/resources and roles/groups together with actions (e.g. communicate action, open action). The ACL would hold the actions against the relevant role/group and tie this to the object or resource. All these policy objects can be changed in real time and enforced immediately upon being changed. No code needs to be written. Simply a few commands or actions via the admin tool (browser, command line, client application depending on the product in question).
Auditing enforcement and administration actions are a given. These can be turned on and off and includes the ability to control the level of audit logging required. All decisions made on authorisation requests are audited, including the identities, resources and the decision made.
Performance is also a question of architectural product design. I do agree some products out there do not scale well. This occurs usually when every decision needs to go back to the central policy server. Scalability is non-existent in these cases. In a distributed heterogenous environment where a product subscribes to the distributed policy enforcement model, scalability is almost limitless. It becomes a matter of cost. ie. how many enforcement points do you want to put out there and have the applications leverage for performance and high availability - which translates to how much more hardware do you want to buy (or VMWare licenses if we're talking about virtualisation) and how much additional services do you want to pay for to do this extra work.
As for on-demand review of policies, the admin interface or reporting features of most products will allow for that. I do agree that this is up for debate as some products do it better than others. ie. some are in a form that is close to english and some are rather cryptic and non-sensical.
The biggest gap in the deployment of these solutions usually lies with ready-made integration. ie. how easily can the solution plug into the existing environment? At the application level, there's usually some development involved because the existing environment needs to be "taught" how to understand the decisions being made by the policy enforcement points. If i can assume integration with the existing environment as you say, then there's no need for any development anywhere. Just deployment, configuration and analysis (this is usually the hardest part) done to map business requirements and entitlement policies into the solution.
I'll send you an email directly so you have my direct contact and we can discuss this further if you wish and perhaps provide me with more details regarding Securent's solution.
Thanks for your response, Ian. I think the 2-tier model you allude to (PAP and distributed PEPs) has been the Achille's Heel of vendor attempts to repurpose their IAM products to address the needs of entitlement management. One reason I use the term Entitlement Management (EM) rather than "fine-grained" authorization is because it is not simply a measure of degree of granularity. In fact the product requirements are different enough that you need a different product architecture to adequately address the needs of fine-grained authorization. And so I don't, and neither do the customers, view existing IAM products as addressing EM. As proof of this are our customer wins where the customers are using us in conjunction with their coarse authorization products.
With respect to your proposed solution to the problem I posed, I don't see how one can create and manage ACLs where the resource profile is dynamic -- when Broker John participates in an IM session, he precludes Analyst Mary from participating in that IM session while he is there. And when he leaves a chat room, he precludes her from going in there. The context is much more dynamic than what a 2-tier authorization solution can handle.
Thanks for your email. I am looking forward to an informative email conversation with you.
Rajiv, seems we're debating somewhat over semantics, specifically the meaning of entitlements. It looks like ultimately we agree that we are talking about authorisation, we just differ in opinion about what consitutes a good authorisation management solution and where the gaps are. ie. your opinion that existing products do not fill this gap that "elevates" the authorisation concept to a point where they qualify to be called true entitlement management solutions.
I don't see how the 2-tier architectural model relates to authorisation business rules or policies. This 2-tier model is an infrastructure design decision and in my opinion does not relate to how dynamic the policies are. For example, you could just as easily define policies (no matter how dynamic or limited) and they would apply exactly the same way to the applications using them for decisions regardless of the product's architectural design from an infrastructure perspective. The difference would simply be where the decision is made. ie. at the PEP or at the PAP.
As for the example I gave, the resource profile can be as dynamic as you wish. The relationships between the participants (e.g. John the broker or Mary the analyst), the resource (e.g. IM), the method (e.g comms channel) and the action (e.g. participate in a session) and certain rules which only apply in certain situations (e.g. if a broker is participating in a particular IM session, then analysts cannot be allowed access it). You are right that a simple static ACL model cannot perform the functions you describe, but an additional angle such as these authorisation rules provide that dynamic flexibility. I admit, not all the large IAM vendor products can do this, but I know of at least 1 that can.
Part of the issue I see here is that we both have slightly different interpretations of certain terms and we're getting our wires a little crossed. I must admit my ignorance with regards to the functionality available in Securent's solution, so I may be missing some of the effect of what you are saying because of it.
My interpretation of what you are saying is that in your opinion, authorisation management + gap = entitlement management. I suppose what I'm getting at is I'm still trying to understand what you think this gap is.
Hopefully over email you can help me understand this gap. I'll send you a note to discuss.
Hi, nice blog & discussion!
I totally agree with the blog topic - in fact we had entitlement management running and publications about it in 2003. Externalized access control has been out there since (or before) 1995.
But it does not matter - I think Securent have done a great job hyping up good practice what we have said since 2000 but nobody listened back then ;-)
But let me throw in another aspect: We essentially had the XACML architecture running in 2003 (without the standard of course) and then soon realised that aggregating all the authorization rules in one place does actually not reduce complexity very much.
This is why we co-founded the topic area called Model Driven Security. It solves the problem that authorization management does not really provide that much value if the full complexity of all access rules across the IT environment is essentially aggregated into one place. There are numerous vendors in this space, and I believe this is where XACML may eventually provide vendor interoperability (*NOT* management).
The more interesting question is how to actually manage these policies, i.e. how to make these authorization/entitlement management solutions actually manageable. Neither XACML and "normal" authorization management solutions provide any support for actually reducing the complexity significantly. Gartner has put "Model Driven Security" (www.modeldrivensecurity.org, www.modeldrivensecurity.com) onto the hype cycle, and we are "Cool Vendor" 2008 with this. So some people seem to think we are on the right track...
We are currently the only real vendor in this space with our patented OpenPMF 2.0 technology (www.openpmf.com). It uses the concepts of Model Driven Architecture actually allow you to generate the rules that go into authorization management systems (e.g. XACML).
This may clarify things somewhat: in our view entitlement management with XACML solves policy interoperability, not management.
Dr. Ulrich Lang
CEO ObjectSecurity – World Leader in Model Driven Security Management
www.objectsecurity.com
Post a Comment