Authenticating Web Services with SAML
- Web Service Collaborations
- Enter Single Sign-On!
- SAML (Security Assertion Markup Language)
- XACML
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In last week's article, I discussed various facets of enterprise security and how they assume challenging dimensions in Web service architectures. This week, let's see how two of the most important facets of security—authentication and authorization—are addressed in the Web services locale.
We first discuss the need for affiliation among diverse Web services, followed by the challenges they imply in terms of security. We then proceed to the concept of single sign-on, followed by detailed discussions on SAML and XACML (two technologies that enable service authentication and authorization across different subsystems and domains).
I've used the following terms frequently in this article:
Authentication: Determines whether to permit a user to access a given system or not.
Authorization: Determines what kind of privileges can be given to a user who has been authorized to access the system?
Principal/Subject: A user or client application or a client Web service requesting access to a specific resource
SAML: Security Assertion Markup language
XACML: XML Access Control Markup Language
Web Service Collaborations
Web services have to correlate, collaborate, and work along with each other to deliver meaningful business benefits to the end consumer or application. It is difficult to develop, maintain, and reuse heavyweight Web services, which encapsulate all business logic required for a specific operation into a single service.
Web services architecture recommends the evolution of modular and reusable business services, which can be used across multiple business applications. In a bank, for example, there might be several applications that need access to specific client information available in the mainframe system. Instead of writing independent client information access routines in each and every application, it makes sense to evolve a common client access Web service and expose it to all other applications.
Having said that, from the security point of view, challenges arise when authenticating and authorizing a client across multiple Web services.
For example, let's say we need access to three different Web services in order to satisfy a client's business request.
These services may well be independent of each other at the application level. The first service may be attended by a back office system, second by a credit card processing system, and third by a customer relationship management system. Each of these systems may require its own procedure for authenticating a client request, but it is difficult (and maybe impossible) to expect the client application to authenticate itself three different times as the service gets processed.
Even in our day-to-day enterprise activities, there are several occasions when we reauthenticate ourselves with almost every single system we access—such as billing, accounting, finance, stores, resource management, material management, and so on. But we have been managing this with some difficulty, given the fact that there are limited or no interactions across these systems. But in internetworked/service-driven enterprise architectures of the near future, it will simply not be possible to live with it.
Thus, it is essential to evolve frameworks that enable exchanging a principal's security credentials across the network.