Many companies have embraced the concepts of Service Oriented Architecture (SOA) at least to the point of creating a few Web Services that are consumed by different applications. Embracing the use of SOA often comes about when an Enterprise Architect is sitting in a kickoff meeting and the need to reuse some critical data foundation functionality, such as Customer Relationship Management (CRM) or Master Data Management (MDM)—through the use of a service interface rather than replication of a nightly batch feed—arises.
These initial services tend to not be secured, or they are secured through some non-standard means such as including username and password information directly in the SOAP body or through HTTP Basic Authentication. This article will outline some basic standards that can be set-up in an Enterprise with minimal effort.
Enable a Security Interceptor
Using a Security Interceptor is a basic way to quickly implement Enterprise-Wide Web Security. Employing the use of a standard Security Interceptor can bring an Enterprise a long way in Web Service Security. The concept of a Security Interceptor is shown in Figure A.
 |
The basic concept shown in this diagram is that the web service producer has enabled a Security Interceptor to take care of all the functionality related to authentication of the web service. The interceptor can also insert information into the SOAP header of the message related to the user, such as groups the user belongs to, so that the service itself can respond in different ways based on the user’s role in the organization. Taking this process to a different level, the Security Interceptor can also be externalized from an individual service and actually be localized to a single provider that all consumers (clients) use for web service communication. The benefit here is that web service producers need not worry about setting up their own interceptors; they can rely on the central interceptor service to manage security and implementation of standards such as Web Service Security. The producers can, in turn, simply limit their network communication to only the interceptor.
Single Sign On and Web Service Security
Now that all of the web service traffic is going through security interceptors and verifying identity against a single repository, more architectural benefits are available. In Graphic A, it is possible to implement security several ways. One way is to create a single user in the repository used by the Authentication Provider to protect the service. This method is the most basic way to implement security. Although the least secure, it requires the same stringent management of the credentials that are typically employed for a database service account for a transactional application with direct database access. This method may be fine for services that are read-only in nature and do not deal with secure data. The credentials here may just be a means of tracking access to the application to ensure service level contracts are not being abused in terms of access. The more appropriate way to access services, however, is for the user to request information or to perform the transaction in question.
 |
The architecture that provides this ability builds on the previous example and is shown in Figure B. In simple terms, the user logs into a web application that performs some look-ups or transactions through one or more Web Services. The Web Services have already been set-up to utilize a Security Interceptor which in turn leverages a central Authentication Provider. The web application can also be set-up to utilize the services of the Authentication Provider for the initial authentication into the application itself.
Typically, the Authentication Provider dispenses a token that the web application will store locally and is checked during each request to a protected resource. This same token can be passed down to the back-end code of the application making the web service calls, such that the token can be added to the SOAP header of the web service call. This process allows the Security Interceptor to validate the user without the need for their credentials and grants access to the service. Now there is no need to protect the service with service accounts. The interceptor can actually identify the user and provide that information to the web service producer itself for more intelligent processing if required.
Conclusion
While much of the information provided in Graphic B may be common knowledge at this point, few organizations implement it. The reason for this lack of implementation may be budgetary. It is widely believed that purchases must be made to implement this type of architecture over and above the purchases for application and web servers that host the Web Services themselves—specifically the central authentication provider.
With the ability to standardize on protocols such as Security Assertion Markup Language (SAML) and Web Service Security, it is very possible to create a local authentication provider that can be used for web site authentication and for Web Service authentication that is standards –based. With minimal effort and no additional dollars, the benefits that such architecture can provide are clear. What seems to be not as clear is the way to go about getting there. Standardizing usage on Security Interceptors authenticating against a central repository is a very basic first step which can unlock the door to achieving a solid Enterprise web service security architecture.
