In part 1 we discussed using SAML technologies in the enterprise for the purpose of web application SSO and user security context propagation. Now let's expand this discussion to the benefits SAML technology can provide to web services.
Web services in the enterprise are rarely built to take advantage of existing centralized security services like authentication and authorization. In many instances web services have no security at all or have only basic protection on the transport layer (HTTP) using some proxy-ID without standard linkages to the security context of a user.
That approach works for basic security protection where user context information does not need to be communicated to downstream services or is communicated inside a proprietary message body, but will create a problem when integration with user oriented systems like e-commerce portals is required.
Let's look at a very common integration scenario where the front-end system authenticates a user based on some credentials and assigns the user application privileges using some security attributes/roles. Everything works fine within the application, but when external services must be called, the user security context is typically required by backend systems to process this request properly and to satisfy data protection and audit requirements.
The user already has a session created in the frontend application by authenticating against some enterprise identity store and has some roles assigned. All is required now is to wrap this information in some standard format which can be reusable by many if not all backend services. It is obviously very important to do it seamlessy without the requirement for any user interaction because we cannot be asking the user to provide his/her credentials every time a backend transaction is called.
SAML provides us with a good solution because:
It contains user security context
It can carry custom attributes in the same message (can be used for roles & authorizations)
It integrates natively with the SOAP protocol which is implemented by the majority of enterprise web services
It is based on standards, so little custom development is needed
It has built the necessary security features (message encryption/digital signature)
But to be able to achieve these benefits, the enterprise web services security layer must be integrated with user authentication and authorization services. In other words, web services security components must trust the SAML identity provider and the identity provider must support SOAP binding.
One of the common approaches to web services security which works well is to implement web services security as a separate layer in front of the enterprise service bus (ESB). By doing so web services will need to be concerned only with business functionality and web services security will be done separately by a dedicated security layer which can also be fully XML aware to provide granular security.
Web services security layer can consume SAML tokens, verify token validity, process tokens and pass them downstream in the form of SOAP header or it can verify the SAML token and leave it intact for processing by downstream services. It also should be able to create SAML token with custom attributes based on frontend user security sessions/context to be communicated to downstream systems.
Producing SAML tokens based on existing frontend application sessions can be a valuable method of encapsulating a legacy application user identity into a standard SOAP header which can be passed to any backend systems. Since standard SAML processing libraries can be used to receive and process this information, the integration effort and format coordination will be greatly simplified.
But in order to be able to produce SAML tokens based on existing user sessions, the SAML identity provider must be integrated with enterprise user authentication and authorization services. This approach will also allow for execution of custom logic to define necessary security roles or ad-hoc permissions for a user.