Enterprise systems based on SOA paradigms have shown great potential in showcasing business agility and tackling...
ever-changing business requirements. The SOA paradigm has completely changed the business outlook and the way we look at its underlying infrastructure. This approach mandates the granularity in business functionalities and services.
In addition, this independent service-based methodology brings in concerns in the infrastructural and business security. Let's take a closer look at the methodology and answer the issues revolving around the security, which obviously cannot be compromised.
Distributed loosely coupled SOA with associated security vulnerabilities
Service-Oriented Architecture (SOA) represents a model where an application/system is represented by a set of components, each of which offers different functionalities, the sum total of these making up the entire system. Each component is known as a service.
One of the prominent benefits of SOA is the ability to build applications, processes or more complex services from other less-complex services. This helps the developer to compose applications and processes in different platforms and also to evolve coordination without having to worry about the infrastructural and environment details. This SOA feature depends greatly on the services being constructed and exposed with coarse-grained interfaces.
Service granularity refers to the scope of functionality a service exposes. Fine-grained services might be services that provide a small amount of business-process usefulness, such as basic data access. Services of the most value to business experts are constructed from lower-level services, components and objects that are intelligently structured to meet specific business needs. These coarse-grained services can be created from one or more existing systems by defining and exposing interfaces that meet business-process requirements.
Service-level granularity brings on the concept of loosely coupled security. To provide the necessary security for these services, which are the building blocks for the business, the enterprise needs a federated security system that doesn't affect the characteristic feature of loose coupling, business agility and location transparency.
Figure 1: Enterprise solutions
Unlike the security model for existing applications, which is more of a container-based security (See section 1 of Figure 1), the SOA-based security model needs to be more granular and diversified in nature.
ESB -- SOA realization solution
Over the past decades, as companies have IT-enabled their processes and invested in IT infrastructure for business, they have built up an inventory of diverse and often incompatible IT assets. This gave rise to the Enterprise Application Integration (EAI) industry, which provided solutions to integrate these assets (both hardware and software) so that the integration platform took care of all aspects of making different functional components communicate with one another. The Enterprise Service Bus (ESB) is envisaged as an open standards-based message bus that provides a means to communicate between various applications in a loosely coupled or a coarse-grained manner. The applications that are connected to the ESB can communicate with one another based on a set of open standards and interfaces.
As in any other software application, security management for the services in the ESB can pose a significant challenge. The main difference in security levels of the service deployment is in the quantum of risks involved. Since the services provide an abstraction layer of the business-oriented functionalities, security integration across applications and enterprises is absolutely necessary. The focal idea of the services' security is to have an enterprise application security integration architecture to integrate security across applications and infrastructure, as well as implement appropriate level of security at run time.
Distributed security with diversified behavior
In a distributed SOA environment made up of many services, security deserves special consideration. The services involved may provide independent security features. But in a distributed environment where there are cross-domain interactions over a network like the Internet, services must have a way of knowing the credentials of the service requester to provide role-based access to the client requesting the service. There are two aspects to this issue:
- Internal security: This refers to the security implemented at the service level. A user (human or otherwise) must be authenticated when trying to access a service for the first time. This can range from a simple username/password authentication to more sophisticated measures such as biometric identification. The credentials of the user are captured in this step and stored for future reference. However, when accessing other services, clearly this localized security is inadequate.
- External security: This refers to the security implementation across the SOA application. If after the user has authenticated locally at a member service he wishes to access another service that is part of the network, the requested service must have a way to verify the credentials of the service requester. This issue is compounded if the internal security measures implemented at various services are diverse and heterogeneous.
A common approach to solving such problems is to have a central security server or implementation against which all services must authenticate. Upon being successfully authenticated, an identification measure (say in the form of a security token) is given to the service. Using this token the service can then access another service, which will verify this token with the central security server as being valid.
Within a SOA environment the format of the security can be standardized across all services. For example SOAP Message Security 1.0 (WS-Security 2004) is an OASIS standard for message-level security in the SOAP message. However, this is easier said than done because enforcing security in an open standards-based system like SOA is inherently more difficult than centralized security in a closed environment like a Kerberos-based network. There are a host of issues that must be addressed that include the following:
- Enablement of single sign-on (SSO) across diverse applications.
- Transformation of user credentials captured at each service end into a common understandable format.
- The ability to provide role-based access to each user, necessitating the need to maintain access control lists (ACLs) for each user.
- Scalability of the security system to accommodate an increasing number of services.
Federated security with open standards
In a standard distributed system, users frequently need to access multiple resources to conclude a single business transaction. Conventionally, every other user has to log on to the different systems, each of which has a variety of user names and authentication requirements. With the advent of SSO, users can log on to the system once and remain authenticated for all systems throughout a complete business transaction.
Although the SSO concept is appealing, it's not easy to employ because enterprise systems often have anecdotal security requirements and a large range of fundamental technologies on which they are deployed.
SSO can be developed for applications that are deployed locally or over a network. In the case of a network, after the user signs on to the primary domain (using Java Authentication and Authorization Service (JAAS), a Security Assertion and Markup Language (SAML) assertion can be sent over the wire to different applications. In local networks, user credential data is exchanged directly between applications.
The JAAS Authentication Framework (the pluggable framework) can be implemented to perform the primary authentication and then SAML can be used in those scenarios to achieve the SSO solution.
JAAS is an ideal tool for access control in a multi-user environment where users must be granted varying privileges. JAAS authentication is performed in a pluggable fashion. That permits applications to remain independent from underlying authentication technologies.
The JAAS authentication framework is based on Pluggable Authentication Module (PAM). JAAS authentication is performed in a pluggable mode that allows an application to add more authentication modules. Java applications can remain autonomous from underlying authentication technologies, thus both legacy and new authentication technologies can be easily configured without requiring changes to the application.
The JAAS authentication framework allows applications to classify any number of login modules in the configuration file. Applications can also specify a flag to each login module to specify the qualified weight of that module. The overall verification depends on the combined results of these individual authentication modules.
The SAML open standard was developed to solve the problems of Web SSO and the exchange of security information between security domains. SAML is managed by the Security Services Technical Committee (SSTC) of the OASIS standards body.
Many organizations use proprietary solutions to manage Web access and SSO. These solutions manage sign-in sessions within a particular security domain, but a standard mechanism is required when users need their sessions to flow across domain. One of the functions that SAML defines is this standard mechanism for SSO. SAML also defines a protocol that allows organizations to exchange attributes about a user independent of SSO.
Figure 2: Holistic view of distributed security architecture
Blend of JAAS & SAML strategy
The existing security infrastructure of the enterprise applications should not be done away with. When the existing applications are migrating towards SOA, the implementation strategy should be such that it goes along with existing security standard. That is the whole idea.
To provide optimized security in terms of resource utilization and performance at each service endpoint, the security implementation must inherently support the following requirements:
- Provide a fully self-reliant component in terms of security.
- Be configurable to different security systems in business scope.
- Follow an open standards-based approach.
JAAS satisfies those criteria completely and provides the security interface for each service endpoint.
The security credentials at each service endpoint must be translated across the SOA environment. The SAML component performs this role satisfying the following criteria:-
- Distributed nature
- Standard communication medium
- Single sign-on
- Agnostic to the primary authentication technology at the service level
To implement the overall security mechanism for the business system, SAML needs to be integrated along with JAAS at each service endpoint.
Figure 3: Blending JAAS and SAML in an enterprise scenario
The blend of JAAS and SAML can provide a viable solution if you have different applications of different security domains. The identity management systems (IMS) are in a trusted environment or the so-called Circle of Trust. One application authenticates the user using the JAAS Framework using its own IM and sends a SAML assertion to the service provider to access say, a Web service. The Web service might be completely ignorant about the SAML assertion, but it sends this SAML assertion to its own IM server. This IM contacts the IM server at the service consumer end, verifies the user and gives the authority to access the service for a particular duration.
In the enterprise scenario, this synchronization of JAAS and SAML solves the problem of security as well as SSO to some extent.
Technology vendors and standards organizations have recognized the risks posed by SOA security vulnerabilities. Standards bodies such as the Organization for Advancement of Structured Information Standards (OASIS) and various consortia such as the Liberty Alliance are working to formulate new technologies and best practices designed to make services more secure. To date, there are numerous standards under development that aim to address a broad range of issues, such as privacy, trust and reliability of services.
Important Standards for Web Services
|SAML||Security Assertion Markup Language is a standard for single sign-on for affiliated sites. SAML assertions communicate security information such as authentication, attributes and authorization decision statements.|
|XACML||Extensible Access Markup Language (XAML) makes it possible to express and enforce access control policies using a single XML-based language.|
|WS-Security||Web Services Security is a standard for enhancing SOAP messaging in order to authenticate parties and protect the confidentiality and integrity of Web Service Messages.|
|WS-I Basic Profiles||The WS-I Organization creates guidelines on how specifications will work together.|
Example: Case scenario with the suggested solution
We have considered a scenario where there is an existing application: a Web page that is secured by a local security system. A user is authenticated by this security system and allowed access to the Web page. This Web page contains a link that invokes a Web service and returns a response. From the user's perspective this link might appear as part of the same domain or environment as the Web page from where the link to the Web service is provided. But this Web service could be located in a different domain or on a remote server and would have a totally independent security system to which the user accessing the Web page has no access. The problem here is clear: There has to be a way to allow a user to access the Web service that lies outside the domain of the current application in a way that does not compromise security.
In our case study, the Web page, which is a servlet, is secured using JAAS. The JAAS uses a simple DBLoginModule that takes the username and password from a form and compares it to values stored in a database. Once authenticated successfully, the user is allowed access to the next page. This Web page contains a link to an external Web service. Since this Web service lies outside the scope of the JAAS implementation at the servlet, we have to find a way to convey the user credentials to the Web service. The Web service must allow access to the user based on the successful authentication at the JAAS application.
A user that has been successfully authenticated by JAAS must be allowed to access the Web service based on the credentials of the user. For that we have employed the SAML standard. As soon as the user enters the JAAS system, a SAML assertion is created based on that user.
The SAML token is placed in the SOAP header adhering to the WS-Security Standards. That is achieved using an open source implementation of Web Services Security -- WSS4J -- which builds the SOAP request with SAML token. At the service provider server level, in this particular case, the validation of the assertion is being done. The implementation of the SAML assertion verification is not bound by any specification. However, in our application we have a Web service handler that intercepts the SOAP request message and verifies the SAML token on the basis of a secret key or certificate.
If the assertion is valid, a session is created for the user at the Web service site, and the user is given a SOAP response in return for the service request. The user is given Role-Based Access, i.e. depending on the user; a period of time is being fixed (from the access time of the first Web application) to the access of the Web service. After this session expires, the user has to log in again and present a fresh SOAP message to the Web service.
In this case, the first Web application is the asserting party. In the simplest sense, an asserting party (source) sends assertions to a relying party to communicate information about a subject, either a person or system. In some cases, the asserting party responds to attribute queries sent from a relying party. In this case of SSO, a user authenticates to the asserting party. Once authenticated, when a user follows a link to the relying party's Web site, an assertion is sent to authenticate the user to the relying party, enabling access.
The Web service here is considered to be the relying party. The relying party (destination) is the system that receives an assertion and uses the attribute, authentication, and/or authorization decision information it contains. In the case of SSO, when the assertion is received, the relying party must decide whether to trust the assertion and grant the subject access to its applications.
Plugging the security vulnerabilities
In addition to the solution proposed above, a set of recommendations and best practices are proposed to improve the overall security profile of the enterprise:
- Make use of the WS-Security standard to maintain security information in the SOAP message header. This can include security tokens such as Kerberos token, Username/Password token, and SAML assertions.
- Employ Web service producer and consumer authentication such as the use of digital certificates on both server and client side. If that seems to be overkill, make use of HTTP Basic Authentication or use non-public-key infrastructure credentials.
- Use authorization measures such as access control mechanisms both at the service level and message level like HTTP Basic Authentication and XACML.
- Provide protection against malicious payloads and denial of service (DoS) attacks. These can be achieved using different security standards like JAAS and plugged in with SAML.
- Perform auditing and logging.
- Leverage existing security resources such as BIOS protection, network firewalls and networking security measures in general.
- If data packets cross multiple nodes from source to destination, then message-level security measures such as encrypted SAML assertion need to be considered.
- In the case of long-lived transactions across multiple domains, use of XrML to enforce rights across the various domains must be considered.
About the authors:
Bijoy Majumdar is a member of the Web Services Center of Excellence for Infosys Technologies, a global IT consulting firm, and has substantial experience in publishing papers, presenting papers at conferences, and defining standards for SOA and Web services. Prior to working at Infosys, Bijoy worked as a technical architect and was key member in designing enterprise solutions with leading-edge technologies. He can be reached at email@example.com.
Anshuk Pal Chaudhuri works as part of the Web Services Center of Excellence (COE) for Infosys Technologies, a global IT consulting firm, and has substantial experience in publishing papers, presenting papers at conferences, and defining standards for SOA and Web services. The Web Services COE specializes in SOA, Web services and other related technologies. Anshuk has developed and deployed Web services in various J2EE-compliant servers. His current focus is on Syndeo - Web services Management Framework. Anshuk's current research interests are WS-Security and different open source products. He is also working in different binding frameworks for XML. Anshuk can be reached at Anshuk_PalChaudhuri@infosys.com.
Vikram Sitaram works as a software engineer with Web Services Center of Excellence in SETLabs, Hyderabad. His current focus is on XML and Java Web services. His interests include WS-Security and Shared Data Services. Vikram can be reached at Vikram_Sitaram@infosys.com.