Message contract we can use when we have pass authentication detail to soap header instead passing as paratmeter in datacontract like ex. license key or user credentials. Passing parameter is not secure.
But we can secure datacontract using security(transport or message). Why do we need messageContract? then what is difference bewteen message contract and data contract/
"Message contract has full control on SOAP message and we can also add Protection Level and message can encrypted and secure. It could be signing or encrypting SOAP header information.
Mixing message and data contracts will cause a runtime error when you generate WSDL from the service."
Related
I was testing below SOAP web service security example.
http://www.mulesoft.org/documentation/display/current/SOAP+Web+Service+Security+Example
Here in the soap component configuration, key value pair is action and UsernameToken TimeStamp. In Enabling WS-Security it is mentioned that key value are constant of WSHandlerContant class. But if instead of UsernameToken i use the constant variable USERNAME_TOKEN of WSHandlerContant class i am getting errors.
Can anyone tell me where i can find possible value of key value for SOAP security.
http://www.mulesoft.org/documentation/display/current/Enabling+WS-Security
http://people.apache.org/~coheigea/stage/wss4j/1.5.5/site/apidocs/org/apache/ws/security/handler/WSHandlerConstants.html#PW_CALLBACK_CLASS
Below are the contant field values that we can use in SOAP Security configuration.
http://people.apache.org/~coheigea/stage/wss4j/1.5.5/site/apidocs/constant-values.html#org.apache.ws.security.handler.WSHandlerConstants.RECEIVE
I am creating a WCF webservice whose requests/responses are supposed to be signed only.
For this, on ServiceContract attribute I have set
ProtectionLevel = ProtectionLevel.Sign
That works ok.
Due to requirements some SoapFaults are supposed to be thrown from service; two types of SoapFaults:
related to application
related to WS-Addressing (e.g. MessageID is missing)
For this I am using the normal of approach of dealing with SoafFaults: create an IErrorHandler in which a Message instance is created with MessageFault.CreateFault.
Almost all the returned SoapFaults are not encrypted (which is ok for me),
my question is why the ones with action="http://www.w3.org/2005/08/addressing/fault" or "http://www.w3.org/2005/08/addressing/soap/fault" are encrypted?
Check out http://msdn.microsoft.com/en-us/library/aa347791.aspx and http://msdn.microsoft.com/en-us/library/system.servicemodel.faultcontractattribute.aspx.
It states that
If you select a binding that enables security and you do not set the
ProtectionLevel property anywhere on the contract, all application
data will be encrypted and signed.
I guess that the build in types by default use this behaviour. You can verify this by looking at which exception is actually thrown.
I implement a ASP.NET MVC3 application, where data is accessed through WCF services.
The WCF service uses EF4.1 for data access with DBContext and POCO classes for entities.
I can annotate the properties with data validations attributes on the server side, and also I can implement custom validation by defining either custom validation attributes (derived from ValidationAttribute), or by implementing IValidatableObject ).
But I have a problem: if validation fails, what is the best approaoch to pass validation error info from WCF to client, and then use it in MCV3 client?
As I understand with WCF, every data exchanged between client and WC service should be part of the data contract, and should not use exceptions as ways of passing meaningful information between server and client (like throwing a ValidationException with extra properties set for Validation failure info).
Also in WCF who uses EF I call dbContext.SaveData(), but if data is not valid, it throws exception, which I don't want.
So:
how can I call validation explicitly in EF and make sure either the object is valid and I can call SaveData(), or the object is invalid and I can collect somehow validation failure information to pass to client.
Haw can I pass this validation failure information back to client, as part of data contract, and not an an exception.
Thanks
You can use two approaches:
Use standard response data contract for success and fault contract with FaultException<YourFaultContract> for validation failure. Typed fault exceptions are way to define "expected" exceptions - it is just another data contract passed in SOAP Fault describing some failure.
Create response data contract which contains something like result code, response data, failure message etc. and use this data contract for both success and failure. I don't like this approach but it is easier to use in some ESB where faults are processed in special way.
I have a WCF Service which returns a list or array. When it is called by a third party, does it automatically serialize into the proper soap envelope?
Yes it does automatically serialize it, by wrapping it with a SOAP Envelope.
This can be disabled if required.
I need to provide non repudiation in my WCF services and want to store all my incomming SOAP requests into a SQL server DB with signature/security data and all the envelope stuff.
This way, when a problem occurs, we can tell to the client "Hi, THIS is your signed message" exactly as you wrote it.
To do this, I need to store a relationship between the SOAP envelope XML's and my persisted bussiness objects/transactions.
Example: THIS is the SOAP Envelope used to add Customer ID=4567 to my Customers datables.
I need to establish a link between SOAP envelope and the bussiness transaction performed by my app. Storing ##identity of the logged message could be a solution. But, where do I put it? In the SOAP Body? Keep it in memmory?
I've reading about logging in WCF and wrote a Database Logger that inserts into tables the log info instead a text file, but i don't know how to link this data with the parsed/deserialized bussines datacontract object that arrives to my WCF service's method.
I don't even know if this is the rigth approach!
Any pattern/tip/hint/tool/help would be appreciated.
Thanks.
If you have enabled the message logging feature of WCF (http://msdn.microsoft.com/en-us/library/ms730064.aspx), you can write a custom listener, and there add all the logic you need. To write a custom listener you only have to implement the TraceListener interface (fairly simple) and then configure WCF to use it, adding it to the listeners section inside the system.diagnostics, replacing the default listener.