Does authorization equal entitlements?

Does authorization equal entitlements?

Summary: Back in the early mists of identity time, "identity management" was referred to as "AAA" (triple A) -- authentication, access control and authorization. Over time, AAA evolved to mean authentication, authorization and acountability.

TOPICS: Security

Back in the early mists of identity time, "identity management" was referred to as "AAA" (triple A) -- authentication, access control and authorization. Over time, AAA evolved to mean authentication, authorization and acountability. Those were seen as the three large functional categories within what came to be called identity management. Eventually, as technology and understanding evolved, categories such as provisioning, federation, web access control, E-SSO, etc. were added. The big three categories remained, but we came to call the whole group of functions "identity management."

Recently, a startup named Securent brought me back to thinking about "authorization." Securent has released some products to deal with what they're calling "entitlement management" at the application layer. The naming convention is interesting, and useful.

As the enterprise has come to deal with the networking of everything, the topic of "authorization" has risen to the top. Controlling "access" to the enterprise was always a nice first step, but it doesn't solve the problems of compliance in today's regulatory environment. Access control was the application layer's version of the network firewall, it created an "inside" and and "outside" and controlled who could get inside. This concept works well as far as it goes, but as has been found with firewalls at the network layer it doesn't scale well and it tends to fight the type of mobility networking seeks to deliver.

Authorization -- dealing with who has the right to do what with what, where, and when -- gets to the heart of the problem: what are people *entitled* to do. It jumps over proxy concepts like location, devices, etc. and goes right to the problem at hand. Thus, "entitlement management" as a category makes some sense. Is that just semantic trickery on the part of Securent in this case? Maybe, maybe not (I haven't seen the products). But it could be a useful semantic step in facilitating the conceptual shift from "barrier security" paradigms to the truly identity based paradigms networked computing requires.

Beyond authorization and entitlement, the breaking wave in identity is visibility. You can provision, federate, authorize, entitle, and audit - but what you're ultimately trying to provide is real-time visibility into a network. Seeing what's going on gives you the ability to enforce policy, but seeing across the entire networked environment of the enterprise is not an easy process.

And the authorization of entitlements is the next step in that process.

Topic: Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • A few points...

    First off, I'm glad to see you enlightened individuals come around. I've been in this specific space for close to 5 years, I've been trying to spread the light, but to little avail - good to see it getting some real traction.

    I used to claim that "authorization" was just another word for "access control" - I still think that, in a wider sense - but I just understood from this article why some would differentiate, and why the difference is important. "Access control", in your lingo, is about the perimeter - who is in and who is out, whether you can "access" the [b]*SYSTEM*[/b]. Authorization is about what you can do when you get there.
    To me, these terms are still identical, but for reasons stemming from two inaccuracies, or mistakes, in your description: that this can be done (1) at the perimeter; and (2) should be done for systems.
    (1) The perimeter no longer exists, in architecture if not in fact, and is no longer relevant. The perimeter is a networking concept, controlled by firewalls, routers, proxy servers, etc. and is limited to the world of the network.
    Which brings me to my second point:
    (2) Access control / authorizations should be done for systems. Systems (i.e. hosts, platforms, etc) do not provide proper context for correct authorization. This should be done at the application level.

    And regarding Securent, while they are very interesting (I actually took a look at them not so long ago), they don't quite get it - hence the obtuse mouthful of an imperceptive term, "entitlement management".
    I can say this based on 5 years doing "entitlement management", whatever that means. Just didn't know that's what I was doing....
    • A (long) clarification...

      A bit about me: I've been working in the application and network management space for just over 14 years now focusing on security, primarily for the big players in the producer of technology space and also spent several years working in the consumer space. About 8 years ago, I worked for a start-up called Netegrity, that helped to spearhead the web-security service space. I now work for another start-up, Securent, that I believe is taking the granular authorization space to the next level.

      First and foremost, Security is about asset protection. An asset could be anything ranging from your office, to datum that's stored on some storage system. There are four distinct parts to security from a business perspective: (a) defining what your assets are (b) identifying what assets need to be secured (c) identifying the users/consumers of a secured asset and (d) controlling the use of the secured asset.

      Most of the focus of security has been on the last two of these business imperatives. At one time, each application that consumed some data asset that was classified as secure also encapsulated the enforcement aspect of security for those assets within the application. That is to say that application developers embedded security into each application in a silo, much like each door to a secure room included its own lock and key. As secure business-critical applications proliferated through the enterprise over time, it quickly became evident that this silo-based approach would not satisfy many requirements of corporate governance. For instance, one could not easily answer the question, "what rights does this user have?" or "given these rights, what can this user do across my applications?". In some extreme cases, it became hard to even answer the question, "what users currently have access to this application?". Silo data became stale as user-bases grew and user turn-around became frequent.

      Thus the idea of turning reusable security-related functions into services was born. The theory was simple: take security-related functions such as logon, logoff, registration, password-management and coarse/fine-grained access control out of each application silo and put those functions into a security service. The solutions that sit within the service should plug and play. The service should provide abstract interfaces to applications that give up their embedded security-management features for those of the service, so that if a specific solution used within the service changes over time, applications are not impacted; the change should be transparent. To meet this challenge, many vendors embarked upon providing technologies to help build out this security service. To do this, we had to break up the various aspects of security and make a clear distinction between authentication and authorization. The former is synonymous to logging on to the security service by providing some set of credentials, which after verification would help the user obtain a session token -- a skeleton key -- that would allow the user access to various applications that uses the service. Authorization, on the other hand, is everything that happens after authentication that allows the service and the applications to determine what a user is allowed to do, if anything. Simply put, authorization is business-logic represented as rules or predicate statements (if...then...) that help determine the scope of what the user can see and do in an application.

      Single Sign-On was nothing more than a side-effect of turning authentication into a service but sadly, it was touted as a "feature" of a lot of the authentication service products sold in the market. If security (authentication and authorization) was to become a true service, the service would have to provide a data-abstraction layer that would allow access to various enterprise and application data-stores that contained credentials used by a user to authenticate and appropriate entitlements that would help to authorize a user. Thus, it became apparent that in order for a user to be able to access an application sitting on the security service, it would be insufficient to simply establish user credentials in the data-stores that were consumed by the service alone. Parts of the user's identity -- say their user-ID -- would also have to exist in the application's own data-stores so that after logging on to the service, the application that the user was attempting to use could personalize content for the user using information derived from its own stores. In the days of the application silos, each application provided administration interfaces so that users of the application could be managed in the application's data-store. We would need an equivalent of this function in the security service. Thus Identity Management (IM) was born. The IM components of the security service would ensure that the requisite components of a user's identity used for authentication and authorization would be centrally managed, while the service automagically populated these identity elements in the appropriate service and application data-stores (through a process called provisioning that is synonymous to data-synchronization).

      The next logical step in this service revolution is turning authorization into a service function. This is by far the most challenging aspect of a security service: how do we go about taking the 100s or perhaps 1000s of existing enterprise applications, some packaged and others home-grown, to a service architecture? Is it even possible to take the business logic embedded in these applications that today handle fine-grained authorization onto a service? Won't the application owners lose some control of their applications? How is the assumption of risk managed?

      Like all complex problems, let's try to address these concerns by breaking the larger problem into smaller portions. I will state for the record that while it may not be feasible or even practical to abstract out every bit of business-logic from all applications onto a service platform, abstracting even a single line of authorization logic onto a configurable service platform means that there is one less line of logic that has to be maintained in the application. Forget ROI; this is common sense.

      You've also probably heard this time and again before, but it does need restating: your application developers should focus on writing secure code; not on writing security-management code. Most firms that are developer-heavy find themselves attempting to solve security-related challenges for their applications by creating their own widgets, instead of focusing their development efforts on creating functional services for their customers. Let the software vendors in the security space do their job in creating reusable security service offerings that can be easily integrated, while you let your developers focus on the products and service offerings for your business.

      Next, the actual challenge of abstracting fine-grained authorization is actually less related to stripping out n-lines code from an application and more related to how one can transport the authorization model from the application onto a service platform function. It would help if the vendor of the authorization service provided tools to be able to do this, that say, a business analyst could use. More importantly, it would help if those tools and the model itself could make use of standards that helped represent the authorization policies in a portable fashion. Luckily, a mature standard exists and its called XACML. XACML is an XML standard for representing authorization policies. Using a rules-engine that is optimized to process authorization models represented in XACML, we should be able to solve the challenge of transporting the authorization model of an application and onto a service.

      However, this alone will not address all the challenges. In today's economy, governance initiatives such as regulatory compliance demand that we must be able to report on and control all elements of data that find its way to a firm's P&L and Balance Sheet. So it is important that we are able to answer questions about who has access to what asset or what someone can do given a specific entitlement. This is where the entitlement management and granular authorization worlds collide. An analyst may have defined business rules that govern a specific business function. Another analyst may have done the same thing as it relates to another business function. Some of these rules will be subject to segregation of duty constraints that one or both of the analysts may not directly be aware of given the scope of their individual function. For example, a trading system analyst may state that a trader ("role") cannot approve his or her own trades. Similarly, a money-laundering system analyst may state that an approved trade ("asset") cannot be settled when the recipient is a resident of a country that is part of the trade-embargo list maintained by the US Government ("role"). The trading system analyst does not necessarily need to know about finite details of the money-laundering system analysts domain or vice versa. But when a trade is executed, the transaction flows between both the trading and the money-laundering system. If both these systems sit on a common security service, then the service must ensure that the intersection of the business rules does not violate policy and that entitlements adhere to segregation of duty constraints. So in the world of authorization, we should be able to manage entitlements and their constraints, while enforcing security policy intersections that may be business-unit opaque.

      In helping to report on security, the onus falls on the authorization platform to report not only on the entitlements that are defined within the service, but also on the entitlements maintained wholly by the application (not all business logic may be abstracted to the service). Ask the vendor of the product you choose if their technology can do that. It is a misnomer that an Identity Management system in and of itself will be able to do that for you.

      As for loss of control, if you authorization platform supports delegated administration of policies with fine-grained control of who can do what within the platform itself, then application owners can maintain administrative control. Moreover, if the security enforcement points used by the authorization platform support both programmatic (a.k.a code-able ) as well as declarative (a.k.a configurable) security models, then the application developers can still retain control.

      When security is moved from an application silo and onto a service, the assumption of risk is typically spread between the application owners and the service platform owners. From a security-related risk management perspective, if the application owners can retain control of security enforcement while utilizing the service platform, then risk is still primarily assumed by the application owner. If however, control of security management is taken over by some centralized corporate-wide entity to whom the application owners have to defer for changes to the security enforcement policies for their application (i.e. a purely declarative security enforcement model), then risk is predominantly assumed by the corporate-wide entity. The type and capabilities of solution you choose, to a great degree, dictates how risk is spread.

      As always, pick the solution that best fits your business needs, keeping in mind that technology is simply a tool and not the magic bullet...
      • A few comments on authorization management

        Hi! I am Ulrich Lang, CEO & co-founder of ObjectSecurity, a UK/US based company that has provided enterprise access management solution calle OpenPMF since 2003.

        I am still unclear about what 'entitlement' exactly means (technically/conceptually) in your context and how it differs from authorization (or authorization token?). Could anyone please explain? Thanks.

        I agree with many of the points made by Sunil. In particular, the good idea of removing authorization from the application logic has been on the table since the late 1990's (or maybe even well before that...), e.g. OMG Resource Access Decision (RAD). There were also various middleware security services that were external to the application (e.g. OMG CORBASec) and central authorization servers (e.g. OMG ATLAS) (we implemented these back then when CORBA was 'hot')

        In 2002, we were building various larger-scale secure middleware deployments and then simply "hit the wall running" without a decent central access manager (which is now sold as OpenPMF) with local plug-ins (for SOA/XML and other systems/middleware). But the real issue we hit then was that even with a unified central manager it is _extremely_ error-prone and time-consuming to specify and maintain a correct access policy. And it is even harder to give some evidence of the correctness and robustness. In most cases you will still end up with a large number of rules for an average distributed application (as our lab experiments have shown), and you will still not have a clear idea if you have covered everything and if you specified what you actually meant. Now if you think that's enough complexity, the problem is aggravated by agile SOA where the management complexity explodes because everything changes all the time...

        There are a couple of other potential traps which I won't go into now. So really central authorization management (is this 'entitlement'?) is a step in the right direction, but I think it is important to be aware of the problem space in all its dimensions.

        Hope this helps somewhat.
        • another brief note on 'entitlement'

          Here is a quick addendum to my previous posting: I have done a bit of research and also asked various scientific groups, and the consensus is that 'entitlement' apparently has no particular technical meaning (yet).

          One amusing thought from a researcher was that 'entitlement' sounds good for you, while 'access control' sounds bad for you - so it may all be about marketing...
  • another quick follow-up

    OK, I just found this in some large vendor's product flyer:

    Application security is now recognized
    as a key enabler to unlocking business efficiencies,
    meaning that the focus of security has evolved from
    ?keeping the bad guys out? to ?letting the good
    guys in.?

    Now maybe I am too technically orientated, but isn't security about both? If I don't have "keeping the bad guys out" measures, then there is no point only "letting the good guys in".

    Any further clarifications would be welcome.

    • Another definition from a large vendor

      "The word entitlements can mean different things to different people. For the purposes of this paper we will define
      entitlements as the set of privileges that govern what an application user can do."

      What's new?
  • RE: Does authorization equal entitlements?

    Most access control solutions are there to protect the workforce or sensitive areas of a business. An example of access control we used is <a href="">Tensor - Access Control</a>.
  • Entitlement Management Case Studies

    For additional <a href="" >Entitlement Management</a> case studies, you can visit Xceedium's website to find additional resources for planning a successful Entitlement Management strategy.