Bill Dettelback's Blog

Product: BEA Workshop Product Family Archives

SOA and Data Security

One topic that keeps on coming up over and over as I talk with customers implementing SOA is the concern over data privacy.  The typically use case looks like this- multiple groups need access to the same database but for legal or organizational reasons cannot view each other's information.  For example, HR is a treasure trove of sensitive information the rest of the organization shouldn't see, as is Sales forecasts, Manufacturing quotas, and corporate growth projections.  Lots of data is sitting in databases with no more security than basic authentication and private views/tables for each application group.

The problem is exacerbated by SOA- when you start service-enabling data, how do you make sure that consumers of the data can only see exactly what they're entitled to.  A brute-force solution would simply shut off those services you're not allowed to see.  But that tends to cause service creep, since you'll have to create a new service for each new consumer.  So the problem is really how to enforce security policy against data oriented services without writing lots of custom service proxies that are secured at the endpoint level?

AquaLogic Enterprise Security provides a fine grained entitlement policy engine which can describe how to grant or deny access down to the individual value of a row of data.  We've done some interesting integrations between ALES and our AquaLogic Data Services Platform (ALDSP) in our latest release so that you can actually provide XQuery statements as part of policy definitions.  This means that you can call an ALDSP service to get some data and automatically have ALES apply an XQuery "narrowing" filter as part of the security check.

For example, say you have a data service that retrieves a list of investment funds:

If you haven't seen an ALDSP service before in Workshop- the data service method is "getFunds" (on the left) and the shape of the returned data is shown in the middle (FUND).  The data service itself is coded in XQuery- and ALDSP does the "magic" behind the scenes to translate this into the appropriate SQL.  What's important for this conversation is the shape of the result set- notice we have an element called "FUND_TYPE" which could be "EQTY", or "BOND", or "FX", etc.

Now say that your Fund Managers are segmented in groups according to fund type, Equity, Bond, etc...  In ALES we can express a set of policies that provide a data redaction filter in XQuery so only those funds of a certain type are returned:

We can read these policies to say, "grant access to the DataServices/Invest/FUND.ds/getFunds method for group equity_fund_manager, returning aldsp_xquery_expression "./FUND_TYPE = 'EQTY'".  There is a different policy for each fund type, and the policies will be enforced depending upon what group the user is part of.

There are a few benefits to this approach:

1. The data redaction policy is completely independent from the data service definition.  All users call the same getFunds method and behind the scenes ALES removes those rows they can't see.  The security policy can evolve independent of the service definition itself.

2. Only one data service is needed for all users- there is no need to build a separate getEquityFunds, getBondFunds, getFXFunds... service for each user type.

3. The redaction happens before ALDSP returns the results to the caller- so there is no performance penalty if we have a million fund records but only care about three Bond records.

4. The redaction is fully audited by ALES, so we can keep track of how many times the service was invoked and if an unauthorized user attempted to see rows he shouldn't.

5. Absolutely no code is written to get this behavior- the data service is created visually in Workshop, and the ALES policy is constructed visually thru the Administration Console.  The only code required is the service consumer (which we can even streamline considerably using the ALDSP Service Control).