Specification for the Web Services basically refers to defining numerous techniques so as to implement the Web service security. Access of the generic user is normally provided to the entire web service requests by default. But, for the reason that majority of the WebSphere Commerce trade approach via the Web services assistance cannot be implemented by the user, Web Service Security can be done allowing several credentials to be used.
Basic or the Fundamental is of the ways to security of the Web service. What happens in this approach? Here in the log in credentials of the user will be attached to the header (header of the SOAP envelope). But the major drawback of using this approach is that the authentication details are found in a plan text enclosed in a SOAP message. And in case where the transfer rules are not safe and secure, it can be easily visible to the attacker with proper network tracking techniques. As a result of this, this approach should always be used in combination with safe and secure transport norms like those in HTTPS.
The subsequent example lists the basic or fundamental authentication
Listing 1: basic or fundamental authentication
<soapenv:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header> <wsse:Security soapenv:mustUnderstand="1" <wsse:Username>John </wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2003/01/oasis-200301-wssusername-token-profile-1.0#PasswordText"> John1 </wsse:Password> </wsse:UsernameToken> </wsse:Security> </soapenv:Header> <soapenv:Body> <!—text text text --> </soapenv:Body> </soapenv:Envelope>
The thing to take care here is that in accordance with the up-to-date Web Security Specification, the credentials for the users are enclosed within the security edge of the header of the SOAP. What does this node or edge does? This basically serves as the shelter for the security details that is supposed to be linked with the Web service request.
The time when this approach is used to authenticate a user, the controller of the Web Sphere trade Web Service will pull out the details regarding the credentials of the user. This is done form the SOAP header and request is sent out to the business service so as to initiate an altogether a new session depending on the credentials details that have been found. An activity linked to the user specified will be established but the drawback of this process is that such activity will not last for unlimited time but only for the period for which processing of the request takes place. Here we will assume that the same process is not required to process the upcoming requests and post the servicing of the request, the activity will marked as complete and cannot be used for any further requests.
Authentication of the user takes place by the WebSphere App Server service engine at the time when global security is active or enabled. The credentials will be placed on the thread at this moment of time. The role of a Web service controller here would be to come up with a activity that is not permanent with the credentials pulled from the thread of the context of authentication. The process helps in making the service engine and WebSphere security in user authentication which in turn does not require any supplementary integration or implementation apart from the reading of the credentials. The credentials are usually read from the thread.
Enabling of the security on the app server comes with a lot of drawbacks as well. You might need to adjust with the performance factor. But for the reason that certificate is meant to follow the concept of transport protocol, in cases where there is a route or solution to permit the transport to offer this sort of validation and that too without making the WebSphere global security active or enabled, this process or approach could be put into practice without hampering the performance of the entire system. When is the default messaging user used?
In cases where one needs to have a generic flag so that in cases where the details on the credentials are not located on the requests of the Web service and the generic flag is set, in such cases there is no need to execute the request, rather the default messaging user can be used or in fact will be used. This flag is known by the name of secureTransportProtocol. If the flag is raised i.e. when the value of the same is set to true, the assumption will be made for the Web services framework that the configuration has been set for the protocol so as to comply with the validation of the credentials. Also the validation of the user ID is taken into account for that particular activity which will be nothing but the default messaging user.
Below listing displays the request in the cases when there will be no credentials and the request in such cases will be taken care under the wcsadmin authority.
Listing 2: Displaying the requests
<Messaging EcIncomingMessageDtdFiles="NCCommon.mod, NCCustomer_10.mod" EcIncomingMessageDtdPath="messaging" EcMimePropFile="lang_mime.data" EcSystemLayoutFile="sys_layout.xml" EcLayoutPath="messaging" EcUserLayoutFile="user_layout.xml"
The activity token is a technique to set up a session for a usual protocol that is session-less.
The subsequent is an instance of a SOAP request that deploys activity token:
Listing 3: Instance of a SOAP request
<soapenv:Envelope xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header> <wsse:Security soapenv:mustUnderstand="1" <wc:ActivityToken> <wc:ActivityGUI>10001</wc:ActivtyGUI> <wc:Signature>sg99bs99gesgs</wc:Signature> </wc:ActivityToken> </wsse:Security> </soapenv:Header> <soapenv:Body> <!—text text text --> </soapenv:Body>