Introduction
Web services based integration facilitates the composition of services across heterogeneous software systems whether new or old, between different departments, organisations, platforms, modernising of the old systems, devices, PCs, mobiles, etc. Typical web based security aspects and solutions differs from the service based applications. In the web based applications the system boundaries are known, centralised security management is available, information access is mostly based on the client-server communications, perimeter based security adoption is followed, known users access the systems so the security aspects can be managed in combination of network and web security solutions.
Whereas for the service based applications the following security aspects have to be considered:
- Need a “System of Systems” view
- As the service is consumed by heterogeneous systems over the networks, so the system boundaries are not known, also this brings the requirements of standard security approach.
- There is no prior relationship between consumers and providers, this brings a requirement for establishing trust between businesses / organisations.
- Centralisation of security management is required to control change management in a better way
- Need rich semantics to define tailored, dynamic, fine-grained access policies and a need for standards
- Establish separation of concerns between application and security management
MuleSoft solutions to web services security – Enterprise Edition and CloudHub
Considering the above security challenges for service based applications, let us see how MuleSoft provides solutions for these security concerns.
MuleSoft ESB allows different integration scenarios using Web services:
- Consuming existing Web services and adding security to an existing web service using proxy.
- Building web services and exposing them to other applications in a secured way using ws-security policy standards
- Exposing a web service and providing authentication to consumers by way of CXF interceptors added to the service.
The CXF module in Mule supports a variety of web service standards including ws-security. WS-security defines a new SOAP header which is capable of carrying various security tokens that systems use to identify a Web service caller's identity and privileges. CXF module in Mule provides different solutions to secure web services which are above the transport level security such as HTTPS. CXF relies on WSS4J in large part to implement WS-Security.
Following are some of the security aspects covered under the CXF module of Mule
- WS Security 1.1
- WS Policy
- WS SecureConversation
- WS SecurityPolicy
- WS Trust (client side only)
- WS-I BasicProfile 1.1
- WS-I SecurityProfile
- SAML 1.1/2.0
Mule simplifies the implementation of ws-security for web services using CXF based configurations. A service consumer sends a request to Mule ESB with ws-security headers which is capable of carrying various security tokens that applications use to validate and identify the web service consumer’s identity and the authorisation levels. Typically, a token can include encryption, digital signature and a time stamp. Some of the examples for security tokens provided by Mule are as follows:
- UsernameToken
- UsernameTokenSigned
- UsernameTokenEncrypted
- SAMLToken
- SignedSAMLToken
For example: In case of usernametoken based approach, the username and password will be validated by using CallbackHandler and the service consumer will be issued with a usernametoken for the given timestamp.
Mule also provides a way to create and configure different token validators to keep the SOAP component light weight and to separate security processing from the SOAP component. When the consumer requests for the service mule delegates WS-security processing to the Token Validators. Some of the token validators available in Mule are:
Username: This token validator validates the username and password credentials associated with each message similar to HTTP Digest authentication.
SAML 1: Validates SAML 1.1 assertion statements, if the validation is successful then Mule flow continues otherwise error response returned to the consumer.
SAML 2: Validates SAML 2.0 assertion statements, if the validation is successful then Mule flow continues otherwise error response returned to the consumer.
Timestamp: Examines the expiration of messages, if the messages have a times tamp which is expired then it returns the error response.
Signature: Verifies the digital signature attached to messages.
Binary Security Token: Verifies the binary encoded security tokens such as Kerberos tokens
References
https://developer.mulesoft.com/docs/display/current/Supported+Web+Service+Standards
https://developer.mulesoft.com/docs/display/current/SOAP+Web+
Service+Security+Example#SOAPWebServiceSecurityExample-ExampleUseCase
If you would like to find out more about how Systems Integration could help you make the most out of your current infrastructure while enabling you to open your digital horizons, do give us a call at +44 (0)203 475 7980 or email us at Salesforce@coforge.com
Other useful links:
Integration with LinkedIn using Mule ESB
Integration of Mule ESB with Microsoft Azure
Integration with Twitter using Mule ESB
