Security is extremely important in SOA, where you do not control the infrastructure and may not know the ultimate owners of services with which you interact. The main issues of a basic security infrastructure are authentication, authorization and confidentiality. As the scope of the Service Oriented Infrastructure (SOI) extends, issues such as non-repudiation, message integrity and legally binding identity assertion become important too.

Authentication:

This is where the caller must use a mechanism to prove its identity to the resource or service in question. The credentials that the caller must use for authentication can be as simple as a username/password combination or a digital certificate which requires the involvement of a trusted third party. Needless to say, authentication requires some form of identity component (at the minimum a list of users and passwords).

There are 3 levels of authentications that can be distinguished. First for the caller to authenticate against the application front-end. Second, authentication against the SOI itself. Third, authentication against a single service (e.g., so only certain users can use the service). These different levels can be thought of as a stack, or hierarchy.

Authenticating against individual services can force a lot of redundant authentication logic and traffic, as well as administration overhead. If the authentication mechanism changes, a significant amount of reengineering may be necessary for each of these services. Even worse if each service has different authentication mechanisms in place. Therefore, authentication against the SOI is often the easier approach.

Authentication against the SOI is provides for SOA-wide authorization and identity assertion. It can make it easier for audit trails if the user only has to authenticate once. Plus it makes management and protection of authentication information a lot easier. Authentication against the SOI is usually based on the framework used to develop it. So in Java, JASS would be the preferred implementation.

If authentication against the SOI isn't possible, then single sign-on frameworks can be used. They provide a consistent view of an authenticated principal within all these environments. This allows for a single authentication step. SSO can be used in conjunction with Web services security, where, for example, username and password information is sent from the client as part of the SOAP Header. SAML is also something that should definitely be considered when exploring Web Services interactions. It's a standard and interoperates with legacy (proven) backend systems for authentication and authorization, allows for propogation of security information across domains, and provides for expiration of the security tokens.

Authorization:

This is the mechanism used to grant a called access to a specific resource (aka Access Control Lists). Different roles should have different rights to the system and services, c.f., administrator and user rights to an operating system. As with authentication, authorization can be done at different levels. Authorization only at the front end though, is often too simple since it can create server security issues since the backend services would have no form of authorization support. Authorization with the infrastructure (SOI) may make sense in many cases, but as with authentication this needs to be approached on a per case basis, possibly being overridden by the individual services. In fact a combination of authorization levels may be the norm: for example, a client authorizes with the SOI such that it is allowed to send messages to a specific service; however, the client message (implicitly the client) is then authorized by the service to ensure that it has access to a specific task within the service, something which the SOI does not have direct control over since that is a backend implementation choice for the service.

As with authentication, single sign-on frameworks can be used to provide information on roles a user is assigsed to, for use in authorization schemes. The specification of "run-as" roles can also be very useful. This allows one service, having provided access to a user in a particular role, to add another role to the user's subject so that they can access additional services (e.g. that are part of the same service composition), with less administrative overhead in setting up the roles.

Encryption:

There are two types of encryption that must always be considered: message level encryption and transport level encryption. The former means end-to-end security (possibly with different types of encryption being applied at different areas of the message payload); plus it allows some aspects of the message to remain unencrypted, which may be important for the SOI if it is to perform routing, auditing etc. without having to be able to decode each message that flows through it. Of course this has its downsides in that the message must be encrypted and eventually decrypted by the right authority: so authentication and authorization play here again.

Because of this, the second approach is often used, e.g., using SSL, which is ubiquitous. Two-way SSL can be used to pass user credentials and perform transparent login. But probably the biggest advantage of SSL is that it is well understood. Many security failures are the result of overly complex approaches and misconfigurations, so simplicity is often the best policy. Of course there are downsides (intrusion detection becomes almost impossible, spoofing is possible if someone gets "in the middle".)

Trust domains:

SOIs often use trust domains, whereby the authentication, authorization and general security are considered local to a specific domain. Once within a domain, you are considered trusted. Moving between domains requires passing through the levels of security again (c.f. a firewall). However, many security breaches have occurred when trust was misplaced and people or services within a trust domain breached the level of trust that they were given by others. So this approach needs to be used with considerable care and attention. The trade-off is obvious: simpler setup and management versus limited/no security beyond a specific point in the infrastructure.

Non-repudiation:

This is very important in certain domains (e.g., legally binding exchanges). Messages need to be non-refutable if they are to be used in a court of law. Despite the requirement to share information, the autonomy and privacy requirements of enterprises must not be compromised. This demands strict policing of inter-enterprise interactions, including non-repudiable access to shared information. For a member of a virtual enterprise, a typical requirement is the ability to inspect/modify shared information together with private information within a single ACID transaction. At the same time, inspection/modification of the shared information should both generate non-repudiation evidence and be consistent with inter-enterprise agreements.