Databases Reference
In-Depth Information
Security Impacts of SOA
Consider a service that is invoked. In order to decide whether to service the request,
it must determine if the requestor is allowed to access this service. Access may be
controlled or restricted, based on the invoking code and also based on the originator
of the request. Consider a composite application in which
User A
makes a request for
Application X
, which satisfies the request by making another request to
Service Y
,
which in turn calls
Service Z
.
Application X
has no more a difficult job in accepting the request in this
environment than in a web application. It can require the user to authenticate,
potentially via some form of secure certificate or biometric-based authentication.
The challenges come when X starts to invoke services.
Service Y
must decide if it
will honor the request. It has three basic ways it can do this:
•
•
Accept requests: Effectively apply no security
Accept requests from
Application X
: Effectively require the client application
or service to be identified and authenticated
Accept requests from
User A
: Effectively require some way of propagating
the identity of
User A
through
Application X
into the service
•
Service Z
has the same set of options, but instead of application A being the
client in this case, it is
Service Y
. This potential chaining of services and potential
requirements for propagation of identity makes it harder to effectively secure the
environment. Later on, we will look at tools in the SOA Suite that can simplify this.
Management and monitoring impacts of SOA
In the same way that we have a more complicated set of security demands in the
SOA environment, we also have a more complicated set of monitoring requirements.
Have a look at the following diagram; it shows how a composite application makes
use of services to satisfy users' demands:
