June 2007 Archives

William Dettelback's Homepage
Bill currently works on the AquaLogic Enterprise Security team. His focus is on customers implementing SOA Security, particularly Authorization and Entitlement solutions. Bill has been helping customers develop solutions in Financial Services, Telecommunications and Healthcare for BEA since 2002. Bill has a Bachelor's of Science in Computer Science and Master's of Science in Computer Science from New Jersey Institute of Technology.

Desperately Seeking Identity Services

I've been out in San Francisco this week at the Burton Catalyst Conference, listening to the sessions, meeting interesting people and participating in the OASIS XACML Interop demo event (more on that in a future blog).

Yesterday I was given the opportunity to be part of a panel discussion on Identity Services.  Mark Diodati from the Burton Group spent some time prior to moderating our panel talking about Identity Services and why they are needed by the enterprise.   His thesis is that identity standards such as SAML, SPML and XACML don't go far enough towards making identity-focused services accessible to developers and end-users.  He drew parallels between the "good old days" of Web Access Management that began with custom ISAPI filters and evolved into a mature SSO market compared to the custom authorization solutions of today and the emerging market for Entitlement Management solutions.

He outlined the types of Identity Services that he's thinking of:

• Authorization (the primary identity service being built today)
• Authentication/Credentialing (mostly credential transformation)
• Provisioning (classic identity provisioning)
• Attribute/Profile (which may be tied to or part of the Auth service)

When I looked at his list I had to smile- it is almost exactly how we've laid out the security framework inside many BEA products (including ALES).  Way back in WebLogic Server 7.0 we (quietly) introduced this pluggable infrastructure for Authentication, Authorization, Role Mapping, Credential Mapping, and Auditing that let WLS interoperate with third party or custom providers of these capabilities.  Today, this framework is utilized by many BEA products and this lets us plug in ALES as the Authorization and Role Mapping provider for WebLogic Portal, Integration, AquaLogic Service Bus and AquaLogic Data Service Platform.  During the panel discussion, it occurred to me that in a small sense, BEA has been leveraging the idea of Identity Services within our own products for years.

But Mark wanted to go deeper on this idea- what exactly makes an Identity Service different from other types of services?  Well, certainly there are specific schemas and protocols we can rely upon (at a very basic level you have things like LDAP and SAML).  But how are organizations going to use an Identity Service?  Should we have a single Identity Service that performs the full gamut of Authentication, Authorization, Attribute retrieval and so forth, or should we have discreet services for each concern?  What sort of service binding is most appropriate- SOAP, REST, XML/HTTP, RMI?  How about performance- can we expect Identity Services to scale to the thousands or hundreds of thousands of users?

I think this is an interesting set of questions- and I certainly don't claim to have the answers.  But what I find most interesting is that the "Identity" folks are now asking the same sorts of questions that the "Application" folks were asking about services in general few years ago.  I'd argue that while Identity Services provide a very specific set of capabilities in your SOA they don't necessarily have to be architected or thought of any differently than your business or data services.   If your SOA needs a single, coarse grained Identity Service, then you can certainly compose it from finer grained services via a service bus proxy model.  If you need greater scalability then it's possible to load balance and distribute Identity Service implementations across multiple physical domains.  In other words, the software side of Identity Services is pretty straightforward to solve.

What really makes Identity Services an interesting challenge is how we can make them standard and dynamically understandable no matter who is using or creating them.  Because Identity Services are so focused on a few narrow concerns it should be possible to come to an agreement on how they "should" be structured.  This will open up a lot of opportunity for users of Identity Services to reduce costs when they need to interoperate with other user's services.  Think of financial institutions that are constantly merging and acquiring smaller banks- if they could simply re-direct the acquired applications to their own Identity Services this would cut out a huge amount of work integrating systems.  We can even toss around the idea of dynamically discoverable and understandable Identity Services where you don't need an architect to explain the subtle semantics of how his Auth service works.

All good stuff for a panel discussion- and by no means are we there yet.  What do you think- are you building Identity Services today?  What do they look like?  Do you think that in 5 years you'll be ripping them out for a COTS solution?  I'm interested in what you think.

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).

July 2007

Search this blog:

Archives

July 2007
June 2007
May 2007

Recent Entries

Desperately Seeking Identity Services

SOA and Data Security