Uniform Service Authentication and Authorisation

The problem with using short-lived access tokens to enable authentication and authorisation of service requests, is that they only really work for synchronous interactions which themselves are short-lived.  Access tokens in, potentially long-lived, asynchronous messages run the risk of expiring.

An interesting alternative is to use certificates to sign (and optionally encrypt) messages.  For example, service A sends a message via some number of queues to service B.  Service A has a private certificate which it uses to sign the message.  Service B receives the message, and uses the corresponding public certificate to validate the message signature, and since this would only work with Service A's public key, service B knows the message originated from service A, and can authorise the request accordingly.    This would work equally well for synchronous calls.

Of course, this means a lot of certificates deployed to a lot of places, but certificates could be obtained from a central service, and access control applied.

So service identity is sorted, but would about user identity?

I suggest that users and core services need to be separated by a gateway layer (application or service), which would be responsible for establishing user identity via some means (basic auth, OAuth, Kerberos, or whatever), and then sending a signed user identity assertion (along with any roles it might have) along with requests and messages, much like is done in SAML.  Downstream services would trust the gateway to appropriately establish this identity, and trust would be ensured by means of the above certificate mechanism.

If you're looking for an identity & access management system, then check out OpenAM.  ForgeRock are doing an excellent job of supporting it, and the major releases are open sourced and free to use. We use it at IG for SAML, OAuth, Windows SSO (Kerberos), LDAP authentication amongst other things.  It is very easy to configure, either manually or scripted (e.g. via Puppet), and provides us a resilient, scaleable, standard authentication capability.  It does also provide policy based access management, but we've not ventured there yet.

And there it is.

Read More

How I explained SaaS to my wife

Wife: You've been staring at that screen for ages.  What are you doing?

Me: Thinking about writing a post on SaaS.

Wife: On what?

Me: Software As A Service.

Wife: Is that what you were telling me about the other day?  Service-oriented thingy?

Me: Service-oriented Architecture.  Yeah, it's similar, but instead of little services which you can use to build your program, you get a whole program as a service.  Imagine Excel on the internet - or the "cloud" as it's being called - you don't have to install it on your computer, you just go on the internet to use it.

Wife: The internet?  Isn't that slow? 

Me: It can be, so you need to be careful what kind of programs you do this with.  For instance, there's a company called SalesForce who offer a Customer Relationship Management program via SaaS.  Companies use it because it saves them having to install and manage lots of computers to put this big program on.

Wife: Interesting...

Me: Are you being sarcastic again?

Wife: No, not at all.  I'm just wondering if they do HaaS?

Me: What?

Wife: Husband As A Service.  I still need that light upstairs fixed.

Read More

Extensible Web Service API

The only constant in life is change, and this is no different for Service-oriented Architecture (SOA). Services must be built with this in mind: that they will have to adapt to new or changing requirements. Extensibility is the ability for services to adapt whilst preserving existing consumer contracts.

We would expect the following types of changes to services to have no impact on other consumers:
- internal source code changes
- interface changes
- take on of new consumers
- environmental changes

Read More

What is SOA - Contract based

Software in general is required to conform to a defined functional interface, and services are no different in this respect. For example, web service interfaces defined in WSDL (Web Service Definition Language) allow the definition of data types, input and output messages, operations, invocation protocols, and even the location of services. WS-Policy may be additionally used to define additional elements of the interface such as security policies.

Read More

What is SOA - Service Characteristics - Reusable

A service is said to be reusable if it can be used in more than one context, even in contexts for which it wasn't originally designed.

So how do we achieve this noble goal?

1. Business domain modelling

If you understand your business domain and model services according to that domain your services stand a better chance of being reused than if they were built in isolation to localised requirements. Business process modelling should drive the requirements for services.

Read More

Building a REST Java web service API using the Spring framework

Building a REST-ful Java web service API has never been more restful than now, using version 3+ of the Spring framework.

 First some annotated Java code:

@Component
@Controller()
public class SampleController {

     @Autowired
     private SampleService service;

     @RequestMapping(value = "/samples/{reference}", method = {RequestMethod.GET})
     @ResponseBody
     public Sample getSampleByReference(@PathVariable String reference) {
          return service.getSampleByReference(reference);
      }
 }

Read More

What is Service-Oriented Architecture : Service Characteristics

The full series of posts on Service Characteristics:

Service Characteristics - Contract
Service Characteristics - Abstract
Service API Characteristics- Composable
Service API Characteristics- Autonomous
Service API Characteristics - Discoverable
Service API Characteristics - Distributed
Service API Characteristics - Reusable

These will apply whether you are writing RMI, CORBA, SOAP or REST web service APIs.

Read More

REST Web Service API HTTP Response Status Codes

What HTTP status codes should your REST web service API be returning to clients?  Does it matter?  Before we launch into this topic, a quick recap of some interesting HTTP status codes:

200 - "OK"  All is well
204 - "No Content"  Nothing returned, but all is still well
400 - "Bad Request"  There is problem on the client's side
500 - "Internal Server Error" There is a problem on the server side
301 - "Moved Permanently" The resource has moved
303 - "See Other Server" Returns a URI to another resource
404 - "Not Found" Server has no clue what the client is asking for
409 - "Conflict" Client has tried to perform an operation that would leave one or more resources in an inconsistent state
401 - "Unauthorized" Client attempted access to a resource without providing the necessary authentication credentials
403 - "Forbidden" Client is not authorised to access a resource

Read More

REST Web Service API - Naming Guidelines

The following offers a suggested set of URI naming guidelines for REST web service APIs that have worked for me in practice.

The book RESTful Web Services RESTful Web Services defines three basic rules for url design which act as a great starting point:

• Use path variables to encode hierarchy: /parent/child 
• Put punctuation characters in path variables to avoid implying hierarchy where none exists: /parent/child1;child2 
• Use query variables to imply inputs into an algorithm, for example: /search?q=jellyfish&start=20 

Read More

What is Service-Oriented Architecture - 10 Key Web Service API Attributes

Services in a Service-Oriented Architecture must be:

1. Interface, Policy and Contract based
2. Location transparency
3. Autonomous
4. Abstract
5. Reusable
6. Composable
7. Stateless
8. Discoverable
9. Extensible
10. Loosely coupled

Read More

Why Service-Oriented Architecture (SOA)?

If you take a look at a typical medium to large company, the enterprise landscape is littered with systems and applications that firstly use diverse and often obsolete or hard to support technologies, and secondly overlap in terms of the business functionality that they offer. The result is a maintenance and operational nightmare that is increasingly costly to run and hampers business growth.

There are two aspects to this problem: (i) the technology platforms, and (ii) the applications.

The answer to the first is virtualisation, i.e. the ability to standardise on a minimal set of technology platforms that can be grouped and offered as virtual platform service to the enterprise. This reduces operations costs and allows cost effect use of the platforms as economies of scale are applied.

The answer to the second, which is what people usually mean when they say SOA (Service Oriented Architecture), is a way of organising software so that instead of applications being rigid monoliths they become dynamic collaborations of autonomous software services, each providing a distinct function.

The key to achieving both of these is standardisation, both of the enterprise technology set, but also the business processes that utilise that technology. In other words the most fundamental precondition for SOA is a mindset change: that the strategic needs of the enterprise supersede the tactical needs of the local business unit. So before you go out and buy an ESB and the other goodies that will give your business "agility" and other such gloriously profitable attributes, make sure your organisation understands and is prepared for this, that it will need things like an enterprise architecture function, governance and a very patient and even enlightened business community.

Read More

REST Web Service API Documentation using RESTdoclet

IG Group has open-sourced RESTdoclet, a maven plugin for generating web-based REST API documentation from REST Java web services implemented using the Spring REST framework.

The plugin:

·         supports Spring 3 REST annotations and JavaDoc out of the box,

·         does not require any additional annotations,

·         is easily integrated with Maven continuous build processes, with minimal configuration,

·         supports multiple streams of service development, and

·         publicises documentation in an interactive, Javadoc-like form, to the web, thus providing a source-code agnostic guide to service consumers.

Read More

What is Service Oriented Architecture - SOA - Accepting Change

"The only constant is change" and the world of Service Oriented Architecture (SOA) is no different. No matter how much upfront business process modeling is done, or how perfect your service granularity is, or how wonderfully compliant you are with WS-*, the reality is that your services will have to change to keep pace with change - business agility implies change. And if your SOA has been working, there should be a whole host of consumers of those services who will not be happy at all with having to change. Change involves project cost, cost requires budgetary approval, and approval requires a Business appetite for the change. But since the change won't always appear to benefit the Business, it will very often not be approved, and your SOA will go the way of most system landscapes: to legacy, riddled with complexity, redundancy and consequent fragility.

Read More

Orchestration vs Choreography?

I was going to write a post on this subject but found an excellent article by Mike Rosen instead.

Job done. :)

Read More

What do I put in my SOA service registry?

I'll talk later about asset management, but for now, what exactly belongs in the Service Oriented Architecture (SOA) service registry?

Well, services obviously, stupid.

But what about stored procedures? Or legacy, remotely invokeable services? Or batch feeds? Or ETL (Extract Transform and Load)?

Read More

SOA Service Registry/Repository

How exciting. At long last I am a working somewhere with thousands of services, a SOA registry/repository, a service registrar and established governance processes around the use of services.

Could life get any better for an SOA believer?

Yes, because unfortunately some groups have decided that all this stuff is too much bother and have come to a peer-peer arrangement regarding the use of services.

So the registry is inaccurate.

So the whole house of cards collapses in a horrible, useless heap.

You see, reuse like recycling only works if the there are practical as well as ideological reasons for doing it. In this case either the governance was not strong enough, or the populace were not sufficiently bought into the enterprise benefit of SOA. Take your pick.

Lesson? A registry does not an SOA make, whereas an organisation (emphasis on organise) just might have a chance.

Read More

What is SOA - Service Characteristics - Composable

Composability is the ability of services to be used in orchestration scenarios by higher level services or processes. It is a special case of the reusability characteristic in that the services need to be uniform as well as reusable. The reason for this primary reason for this requirement is that the orchestrating service will in all probability but built using something like BPEL not a conventional programming language, so any variations in service style become more difficult to deal with.

Read More

What is SOA - Service Characteristics - Stateless

A service is said to be stateless if the consumer of that service can make use of any operating instance of that service. This is achieved by services not storing any internal data (state) that would be required if the consumer happened to invoke another instance of that service.

In general this goal is achieve by ensuring that all service data (including state) is kept in an external store common to all instances of that service.

Read More

What is SOA - Service Characteristics - Distributed

Services should be distributable, that is they need not and indeed should not run in the same process as the consumer. Services that run in the same process offer no possibility of runtime reuse to other consumers.

In order to achieve this goal you minimally need two things: a remoting framework and location transparency

Read More

SOA Web Service API Management

I have written and published an article at SOA World on SOA Web Service API Management and ITIL.

Read More