What are the security challenges unique to an SOA?
The second problem area, however, is even more telling, and goes to the essence of how the SOA works: Because the service composition layer acts as a layer of abstraction and masks the details of the underlying technology implementation from the users, each service abstracts the user identity context from the underlying applications. This makes it difficult to associate the users of the overall functionality, since the SOA itself provides no overall security context. For example, when the getSalary API call on the ERP system comes in through the Web services interface, how is the ERP system supposed to know whether that call is authorized? The calling party is the getSalesCommission service or maybe the service composition software that service runs on.
Therefore, the "islands of security" approach breaks down in a service-oriented model, because
users can access services located on different systems at different times, and the underlying
applications no longer have the user context they require to authorize specific actions. To provide
the necessary security for these services, the enterprise needs a single identity management and
security policy infrastructure that governs the access to the four interfaces in the example (the
portal, the business service and the two atomic services) in a way that provides the overall
security context for the systems, services and applications. Enterprises must institute policies
that apply to their entire enterprise network (including participants invited from outside) and
administer that security in a tiered, hierarchical fashion with a centralized root administrator.
Departments or other organizational groups may then have their own administrators, but those
administrators must in turn be administered by a more senior admin at a higher level within the
This was first published in November 2004