Enter the Entitlements Server
Join the DZone community and get the full member experience.
Join For FreeIt is always striking that so much work is done on authentication
technologies, but so little on authorization. Usually authorization (the
decision on "who can do what") is baked into code in applications. This
makes it difficult to change these rules later, or to audit the rules.
Entitlements Servers fill this gap, by externalizing authorization from
applications. Marc Chanliau has written a really useful article on
entitlements servers, which provide this service exactly.
He gives a good example of when an entitlements server is vital:
He gives a good example of when an entitlements server is vital:
Suppose a homegrown portal application must present a sensitive piece of customer information such as a Social Security Number (SSN) when a service representative views a customer's profile. It is determined that in order to ensure compliance with various privacy regulations, only directors and senior managers may be able to view a customer's SSN. A decision has to be dynamically made whenever the application must show an SSN as to whether the current user may view the actual data or some default value (e.g., "XXX-XX-XXXX"). The decision must take into account the user's job title. A dozen parts of the application that can display a customer's SSN mean a dozen places for this business logic to be applied.He then goes on to explain how an Entitlements Server works in the framework of RBAC (Role-Based Access Control) and the PEP/PDP/PIP model. Gateways like the Vordel Gateway are often deployed as the PEP part of this model, and I've written recently about the benefits of integration between the PEP and the Entitlements Server.
Now assume that the policy needs to be changed after the application has been in production for some time. The business has determined that senior managers in California may not view an SSN. This is an exceptional situation that requires another piece of information to be considered as part of the entitlement decision. But what if we take the example even further? Suppose that only directors above a certain salary grade can view SSNs. Now the entitlement logic has been split into multiple decisions based on runtime attributes. So the business logic must be adapted.
You can see that authorization or entitlement policies evolve very differently from application requirements. Having the entitlement logic "hard wired" into the business logic means changing code each time there is a policy change.
http://soa.sys-con.com/node/1923919
application
Business logic
Published at DZone with permission of Mark O'Neill, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Getting Started With the YugabyteDB Managed REST API
-
File Upload Security and Malware Protection
-
Mastering Time Series Analysis: Techniques, Models, and Strategies
-
Merge GraphQL Schemas Using Apollo Server and Koa
Comments