Agile, decoupled security for better service orientation

Service orientation is about agility. Without a resulting agility, there is no point of doing SOA. Unfortunately, enterprise SOA infrastructure initiatives sometimes fail in part because its security mechanisms and processes demolish any agility that was built into the SOA itself. This happens when security is an afterthought. Simple barriers are good for security but they can easily become preventers of agility.

When security fails to maintain agility, one of following two possible consequences seems to emerge. The first is a failure of the corporate SOA initiative – without agility, the SOA fails to provide value. The second is when users of the SOA infrastructure work around the security mechanisms and processes to restore the needed agility. Holes are poked in the barriers themselves to accomplish what is needed – this is obviously dangerous and non productive.

To avoid such problems, one must implement a security that enables agility. One of the key ingredients of such an application of security is the decoupling of security from the services themselves. Consider the figure below where agility is represented on the Y axis and decoupling on the X axis. Note that I consider decoupling not as a binary ‘on-or-off’ state but rather along a scale with varying degrees.

On the left extreme, security is embedded as part of the application logic itself. There is no decoupling and therefore no agility with applying security at this level. This type of approach cannot accommodate important SOA patterns such as service compositions and global policies. Any change at this level requires potential interruptions of service and costly development phases. Moving along to the right, we come to container level security. This is a first step towards decoupling but the security is still running in process of the service implementation, very close to it and with very little added agility. Agent based solutions can offer additional decoupling in the sense that they can receive instructions from a centralized authority. However, agent based solutions are still running in process of the services themselves and have a native dependency to the container of the service implementations. There is still limited agility and a potential lock-in problem.

On the top right, you find security as a service, a security implementation that runs out of process, in a transparent way to the services themselves. Security as a service is a pattern typically implemented by gateway-based solutions – centralized policy enforcement points (PEP) and policy decision points (PDP). Security as a service requires a neutrality towards the services that they act on behalf of. This neutrality is achieved through the use of standards based mechanisms.

About these ads

2 Responses to Agile, decoupled security for better service orientation

  1. Jason says:

    If your security requirements are simply to restrict access to resources/services, I can see how you can quite cleanly de-couple that from the application. However, if your security requirements include restrictions on rows of data, it is almost certainly necessary to be mixed in with application logic, because the restriction itself is usually quite domain specific.

    For example, take user Joe. It is quite easy to decouple the question, “Can Joe list system users?” as long as the answer is either yes or no. However, if the answer is “Yes, but only those users that are in Joe’s company,” that is application logic isn’t it?

    I mean, you can still de-couple in a code sense. A security service is responsible for answering the questions, “Can Joe see all users?” “Can Joe see users in his own company?” “Can Joe see his own user?” Then the user list service (or some helper class called by that service) is responsible for asking the security service those questions until it gets a yes answer and applying filters on the query (or until it runs out of options without a ‘yes’ and has to throw an exception).

  2. Jason, thanks for your comment.

    It is quite common for soa security infrastructure (such as our gateway) to have an application level awareness which enables this kind of rich decision making.

    To use your example, in-policy rules would include a combination of message level inspection, LDAP or SQL lookups to determine the restriction you are suggesting. In the end, the service implementation focuses on returning the data and the policy enforcement point will let a security administrator author policies that go well beyond typical authentication responsibilities.

    Another example of this pattern is in when our gateway controls access to medical records (see http://www.layer7tech.com/case-studies/securely-sharing-medical-records-through-soa). Not only does the policy validates the digital signature of the request, but also validates the fact that the signing party should be allowed to consult this particular document consulting a practitioner-patient relationship authority (database).

    Often, different security responsibilities end up being distributed across various architectural components but decoupling security logic from application logic seems to be winning pattern emerging.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: