How to provide security to SOAP web services ( JAX-WS )
Security is the major concern in the network based distributed client server environment.
Why web service requires more security?
Because ,most of the web services will provide services to the clients via internet.So compare to intranet , internet is less secure.
While doing transaction , The client may submit sensitive data like authentication data ,bank details . This data will transfer along with web service request via internet.So it require more security and protection.
Web service is a widely used technology .So the chances are more to hack or theft the data while performing a transaction
Transport Layer Security—SSL :
Authentication—communication is established between two trusted parties.
Message confidentiality—data exchanged is encrypted.
Message integrity—data is checked for corruption.
Secure key exchange between client and server.
SSL Limitations :
SSL can secures the communication at transport level(transport layer) rather than at message level. As a result, messages are protected only while in transit on the wire.So we must encrypt the data before transfer.
SSL (Secure Socket Layer) provides security to point-to-point, But web services required end-to-end security. Which means,
A typical web service can communicate with multiple nodes in a XML-based documents.
Other important ways to provide security to SOAP web services as follows.
XML Encryption :
It uses the W3C’s XML Encryption standard to encrypt the SOAP message body or few portions of it . Typically, various encryption algorithms are supported.It explains the below main aspects,
How digital content is encrypted and decrypted.
How the encryption key information is passed to a recipient.
How encrypted data is identified to facilitate encryption.
Example XML file to provide security to SOAP web services:
<CreditCardNumber>5534 7865 3465 0109</CreditCardNumber>
<EncryptedData xmlns="http://www..." Type="http://www...">
XML Digital Signatures :
WS-Security’s use of the W3C’s XML Digital Signature standard enables SOAP messages to be digitally signed to ensure message integrity.
Typically, the signature is a computed value based on the content of the message itself. If the message is altered en route, the digital signature becomes invalid.
Oracle Application Server supports DSA-SHA1, HMAC-SHA1, RSA-SHA1, and RSA-MD5 algorithms.
<!-- The signedInfo element allows us to sign any portion of a
<!-- Following is the result of running the algorithm over the
document. If changes are made to the document, the SignatureValue is
changed. The security application verifies the SignatureValue,
extracts the X.509 cert and uses it to authenticate the user -->
<!-- Following is the public key that matches the private key
that signs the document -->
<!-- Following is the certificate -->
Web Services Security (WS-Security) specifies SOAP security extensions that provide confidentiality using XML.
Encryption and data integrity using XML Signature. WS-Security also includes profiles that specify how to insert different types of binary and XML security tokens in WS-Security headers for authentication and authorization purposes.
WS-Security Tokens :
Web services security supports the following security tokens:
Username—defines how a Web service consumer can supply a username as a credential for authentication). For more information.
X.509 certificate—a signed data structure designed to send a public key to a receiving party. For more information.
Kerberos ticket—a binary authentication and session token. For more information.
SAML Token :
The Security Assertion Markup Language (SAML) is an open framework for sharing security information over the Internet through XML documents. SAML was designed to address the following:
Limitations of web browser cookies to a single domain: SAML provides a standard way to transfer cookies across multiple Internet domains.
Proprietary web single sign-on (SSO): SAML provides a standard way to implement SSO (one login for multiple applications)within a single domain or across multiple domains. This functionality is provided by the Oracle Identity Federation product.
Federation: SAML facilitates identity management (Ex : account linking when a single user is known to multiple web sites under different identities), also supported by Oracle Identity Federation.
Web Services Security: SAML provides a standard security token (a SAML assertion) that can be used with standard web services security frameworks (e.g., WS-Security) – This is the use of SAML that is particularly relevant to web services security, fully supported by Oracle WSM.
Identity propagation: SAML provides a standard way to represent a security token that can be passed across the multiple steps of a business process or transaction, from browser to portal to networks of web services, also a feature supported by Oracle WSM.
The SAML framework includes the below four parts:
Assertions: How you define authentication and authorization information.
Protocols: How you ask (SAML Request) and get (SAML Response) the assertions you need.
Bindings: How SAML Protocols ride on industry-standard transport (e.g., HTTP) and messaging frameworks (e.g., SOAP).
Profiles: How SAML Protocols and Bindings combine to support specific use cases.
In the context of WS-Security, only SAML assertions are used. The protocols and bindings are provided by the WS-Security framework. SAML is widely adopted by the industry, both for browser-based federation and federation enabled by web services flows.
SAML assertions are very popular security tokens within WS-Security because they are very expressive and can help prevent man-in-the-middle and replay attacks.
Typically, a SAML assertion makes statements about a principal (a user or an application). All SAML assertions include the following common information:
Issuer ID and issuance timestamp
Optional subject confirmation (for example, a public key)
Optional conditions (under which an assertion is valid)
Optional advice (on how an assertion was made)
SAML assertions can include three types of statements:
Authentication statement : issued by an authentication authority upon successful authentication of a subject. It asserts that Subject S was authenticated by Means M at Time T.
Attribute statement : issued by an attribute authority, based on policies. It asserts that Subject S is associated with Attributes A, B, etc. with values a, b, and so on.
Authorization decision statement (deprecated in SAML 2.0, now supported by XACML): issued by an authorization authority which decides whether to grant the request by Subject S, for Action A (e.g., read, write, etc.), to Resource R (e.g., a file, an application, a web service), given Evidence E.
SAML assertions can be embedded (i.e., a SAML assertion can contain another SAML assertion). SAML assertions can be signed (using XML Signature) and/or encrypted (using XML Encryption).
Together with WS-Security, WS-Policy is another key industry standard for Oracle Fusion Middleware security.
A Web service provider may define conditions (or policies) under which a service is to be provided. The WS-Policy framework enables one to specify policy information that can be processed by web services applications, such as Oracle WSM.
A policy is expressed as one or more policy assertions representing a web service’s capabilities or requirements. For example, a policy assertion may stipulate that a request to a Web service be encrypted. Likewise, a policy assertion can define the maximum message size that a web service can accept.
WS-Policy expressions are associated with various web services components using the WS-PolicyAttachment specification. WS-Policy information can be embedded in a WSDL file, thus making it easy to expose Web service policies through a UDDI registry.
Web Services Security (WS-Security) specifies SOAP security extensions that provide confidentiality using XML
Encryption and data integrity using XML Signature. WS-Security also includes profiles that specify how to insert different types of binary and XML security tokens in
WS-Security headers for authentication and authorization purposes. WS-Security token profiles are described in the
WS-SecurityPolicy is part of the Web Services Secure Exchange (WS-SX) set of specifications hosted by OASIS (in addition to WS-SecurityPolicy, the WS-SX technical committee defines two other sets of specifications: WS-Trust and WS-SecureConversation, described later in this chapter).
WS-SecurityPolicy defines a set of security policy assertions used in the context of the WS-Policy framework. WS-SecurityPolicy assertions describe how messages are secured on a communication path. Oracle has contributed to the OASIS WS-SX technical committee several practical security scenarios (a subset of which is provided by Oracle WSM 11g). Each security scenario describes WS-SecurityPolicy policy expressions.
WS-SecurityPolicy scenarios describe examples of how to set up WS-SecurityPolicy policies for several security token types described in the WS-Security specification (supporting both WS-Security 1.0 and 1.1). The subset of the WS-SecurityPolicy scenarios supported by Oracle WSM 11g represents the most common customer use cases. Each scenario has been tested in multiple-vendor WS-Security environments.
To illustrate WS-SecurityPolicy, let’s use a scenario supported by Oracle WSM: UsernameToken with plain text password. As mentioned earlier, Username token is one of the security tokens specified by WS-Security. This specific scenario uses a policy that says that a requester must send a password in a Username token to a recipient who has authority to validate that token. The password is a default requirement for the WS-Security Username Token Profile 1.1.
This scenario is only recommended when confidentiality of the password is not an issue, such as a pre-production test scenario with dummy passwords.
Example of WS-SecurityPolicy :
An example of a message that conforms to the above stated policy is shown below.
Example of Message Conforming to WS-SecurityPolicy :
<?xml version="1.0" encoding="utf-8" ?>
<wsse:Security soap:mustUnderstand="1" xmlns:wsse="...">
<wsse:Password Type="http://docs.oasis open.org...>
The example above contains a <Nonce> element and a <Created> timestamp, which, while optional, are recommended to improve security of requests against replay and other attacks. A nonce is a randomly generated (unique) number. The timestamp can be used to define the amount of time the security token is valid.
Web Services Addressing (WS-Addressing) :SOAP does not provide a standard way to specify where a message is going or how responses or faults are returned. WS-Addressing provides an XML framework for identifying web services endpoints and for securing end-to-end endpoint identification in messages.
A web service endpoint is a resource (such as an application or a processor) to which web services messages are sent.
The following is an example using WS-Addressing (
wsa is the namespace for WSAddressing):
Example of WS-Addressing :
WS-Addressing is transport-independent; that is, the request may be over JMS and the response over HTTP. WS-Addressing is used with other WS-* specifications, such as WS-Policy.
WS-ReliableMessaging (WS-RM) defines a framework for identifying and managing the reliable delivery of messages between Web services endpoints. WS-RM is predicated on the SOAP messaging structure (SOAP binding) and relies on WS-Security, WS-Policy, and WS-Addressing to provide reliable messaging.
WS-RM defines a reliable messaging (RM) source (the party that sends the message) and an RM destination (the party that receives the message). WS-RM mandates prerequisites, for example, trust between endpoints must be established, and the message and endpoints must be formally identified (this is achieved through the use of the complementary WS-* specifications mentioned earlier).
WS-RM Policy defines a policy assertion that leverages the WS-Policy framework in order to enable an RM destination and an RM source to describe their requirements for a given sequence.
|Related Posts :|
|How to call C# .Net WCF web service in PHP SOAP client|
|How to create WCF web service in C# .NET ( visual studio 2013 )|
|How to call java SOAP web service in php ( php web service client )|
|What is RESTful web service (Introduction to RESTful web services)|
|How to call a web service from another web service (web service chain)|
|How to handle custom exceptions using SOAP faults in web services|
|How to Create a java web service using bottom up approach|
|Create a java web service from WSDL (Top down approach) in Eclipse|