Applied SOA: Part 8–Security

This is part of a series of blog post about Applied SOA. The past blog entries are:

• Introduction
• SOA Basics
• Service Discovery Process
• Service Taxonomy
• Interoperability
• Service Composition
• System Consistency

In this article, I’ll cover security.  Security is a very broad topic and by no mean unique to SOA.  I’ll focus on what is specific about service security.

I once had a colleague whose mantra around security was the triple ‘A’:

• Authentication
• Authorization
• Audit

I actually find that triple ‘A’ a very good summary of security concerns in most systems:  who are you, what can you do with the system and keeping traces of what you did.

Authentication

When a service is invoked, it is done by something (e.g. a browser, another service, etc.) on behalf of somebody (e.g. an end user, a system user, an anonymous agent).

Some concerns jump in:

• How do we identify users in your system, i.e. what is the identity model in your system?  Is the identity a username?  A SID?  A set of claims?
• What is the authentication process, what are the credentials involved?  User name / password?  Certificate?
• Where and when is the authentication done?  Once and a proof of that authentication (e.g. token, cookie) is transported thereafter or is it done at each tier boundary?  Service boundary?
• How does it flow through service composition?  Does the end user identity flows all the way or does the identity of services take over somewhere in the pipeline?  How do you address the case where a service composition is done through asynchronous means, i.e. can the invoker identity be stored with the asynchronous message?

In the Microsoft realm of technology, some classical approach exist.  Using Windows Authentication is often used within a corporate network as a secure way to authenticate user with little friction (user is already logged in on his / her workstation).  Identity can flow via impersonnification or caller context.  The database is often considered a trusted subsystem, i.e. that it doesn’t require the end-user identity, trusting the calling services.  In some cases, you might want to flow the identity right through the database though, in order to strictly enforce security policy.

Outside corporate firewalls identity is often managed using custom means, i.e. username / password and a combination of cookie & custom token.  Claims based security model is rising and becoming more common but is still a young technology.  Interoperability is a challenge with Claims based as very little products support it hence you would have problem to flow the identity everywhere.  This is often managed by having a security policy of controlling the user identity at the Enterprise boundary and then flowing the service identity.

Authorization

Now that you know the identity of the agent invoking your service, how do you control access?  Many models are possible given the following variables:

• Are you going to be context insensitive (e.g. this operation requires role X to execute) or context sensitive (e.g. this operation requires role X and role Y.<the name of the department you are trying to access> to execute)?
• Are you going to control the access at the operation border only?  If so, a user can either invoke your service operation or not.  You might also need to control what the user can see and perform security trimming even once the user has been given access to the service operation.
• Are you going to grant access based on role (RBAC), to a set of claims or to a set of permissions, itself determined from role, claims and other data about the user identity?
• Where are you going to control access?  Everywhere?  At an entry point only?

Typically, you’ll have a mix of those variables in your system.  Just being aware of them and which compromise you are making in your architecture will go a great way of ensuring the clarity of the security model, how well it will be understood by different stakeholder and hence the strength of its eventual implementation.

Audit

Often forgotten in security is the audit.  Indeed, we can secure a system with access control (authorization), but another big requirements for a secure system is to be able to trace back what a given user did or who did what in a system.

Audit is the ability of tracing back actions.  This is typically enabled by logging actions to a store.

Now the first question you need to ask yourself is if you’ll need to audit easily, i.e. via some UI with search facilities, etc. in which case you want the logging information to be easily mined or is audit going to come as a consequence of some rare legal problems, in which case you just want the information to be available so that some professional could go and mine the information on a need-to base.

Logging can be done at different level:

• At the service boundary you can log information about an operation, payload in / out, time of request, identity of the user, etc.  .  In an SOA architecture, this should be sufficient to reconstruct user actions.
• You can continue to log within a service, at different layer, even going as far as logging DB access.  This is useful if your service implementation changes often or if their logic is strongly influenced by some configurable sources (e.g. business rule engine in BizTalk, custom application configuration, etc.) in which case service operation treatment might vary over time and it could be hard to reconstruct actions just by looking at service log.

You can log actions within your system, e.g. by stamping changes with a user name, by keeping all changes, etc.  .  This is done by systems such as TFS which never forget anything.  It is easier to do in such systems because they have generic entity management system.  On system managing many type of entities (e.g. many tables in a DB), it can become difficult to keep all changes in the system without cluttering information schema.  In those cases, you might want to perform logging on the side, e.g. in log files.

Regardless of where you log, it might be challenging to reconstruct user actions from log.  So it’s better to think in advance at what type of reconstruction you would need to do to make sure it will be feasible.  Often the reconstruction scenarios are simple, e.g. who changed the salary of X?  But sometimes, it can be harder, for instance, if you need to reconstruct a long running business process where different people can have played a different role.

Again, you’ll often end up with a mix of the options presented here, i.e. logging on the side + keeping last changes in store which you can then expose at the application level.

Golden rule

Architect with security in mind day 1!

We repeat that everywhere all the time but more often than not, security comes second.  This is actually quite natural since as an architect you typically sit down with business people to specs out an application.  Those stakeholders often have very remote concerns about security.  A good way to get around this tendency is to involve security-aware people (e.g. legal, your Enterprise Security guru) early in the process.