I try to implement WCF Client (C#) to consume a specific web service from NEXI. Service required a WS-Security (signature & encryption) and client authentication.
In documentation specific standards.
WS-Security Spec.
In accordance with the WS-Interoperability Basic Profile 2.0 the Secure WebServices Interface uses SOAP 1.1 with an HTTP Binding and specifies additional requirements.
1.Hashing algorithm must be SHA256
2.Signature Algorithm must be RSAWithSHA1
3.Encryption Algorithm must be AES256
4.Certificates used MUST have a key length of 2048 bits
5.Certificates used MUST have been generated using only SHA-256 as a hashing algorithm
6.Certificates used for signature and encryption MUST be issued by known Certificate Authority
7.Certificates needs to be exchanged between parties
8.Parties have to manage multiple certificate for the same purpose (signature and/or encryption) to overcome any gap when certificate renewal occurs. Parties have to exchange renewed certificate at least 30 days before current certificate expires.
9.All SOAP messages MUST be serialized using UTF-8 character encoding of the Unicode character set
10.Use SOAP Request-Response Message Exchange Pattern as specified in SOAP 1.1 (see http://www.w3.org/TR/2000/NOTE-SOAP-20000508/)
11.A correctly processed client request MUST be answered with a server response, consisting of a HTTP response with a 200 Status Code containing a soap:Envelope element
12.The soap:Envelope element MUST contain a soap:Header child element
13.The soap:Body element MUST contain exactly one, namespace-qualified child element
14.The soap:Body element MUST have a wsu:ID attribute with a unique value that enables it to be included in the signature and encrypted
15.Encription Key must be encrypted and included in soap:Header “xenc:EncryptedKey”
16.The wsse:Security element in request messages MUST contain exactly one wsu:Timestamp
17.SignedParts and EncryptedParts:
a.SignedParts: wsu:Timestamp (the request timestamp)
b.EncryptedParts: Body.
I am looking for a solution or help to setup all this requirements to single request.
I tried the implementation in SOAPUI but I am not able to meet all the requirements. I also tried to create a WCF client in .NET. but I am not able to set individual namespaces and I don't know how to create a request that meets all the requirements.
Expectations:
The request according the documentation should look like:
Request:
Request
Response:
Response
Related
As a service provider (SP), i'm trying to create request for SLO using the URL redirect flow. After going through a lot of articles, this is what i came up with:
Create a logout request xml and digitally sign it
Convert the request xml to base64 url encoded string
Append the base64 encoded request xml to the SLO url as a querystring
Redirect page to the above constructed url (IDP)
IDP will then perform necessary SLO steps for all SPs at its end and
redirect back to our current application (which initiated the SLO
request)
Parse above response and show message in UI accordingly
However, when i got into the actual implementation, i'm faced with the following challenges, some of them not specific to SAML SLO.
To digitally sign the logout request xml, is it mandatory to
load/import the x509 certificate from .pfx file or can i use any
certificate from the certificate store which has private key?
For demo purpose, I've successfully signed the request using a certificate in my local system which has private key. This process appends the signature and pulic key information in the logout request xml.
I've encoded (Base64Url) the request xml but the resulting string length is too long (more than 4k chars), which would exceed the maximum length allowed in URL/GET request. Have i got this step wrong?
None of the articles/SAML spec mentions how the querystring should look like. Is the querystring parameter name defined by the SAML spec (which i could have missed) or is it dependent on the IDP?
All in all, i feel that SAML spec lacks articles with proper implementation which is making it extremely difficult to get the hang of it.
Note: I didn't include any of the codes i've written so far since my questions can be answered without them. However, if required, i can include them.
Few of the many referenced articles:
SSO, SAML and SLO
SAML Logout Request (SP -> IdP)
Sign XmlDocument with X509Certificate2 and Verify in C#
I would strongly suggest using an existing SAML library instead of rolling your own.
Some of these are free and you can examine the source code to see how to do it.
Or alternatively just use the stack itself!
I am trying to consume a Java web service from a C# client. The service requires BinarySecurityToken element with value type X509PKIPathv1.
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1">
MIIH......
</wsse:BinarySecurityToken>
Since WCF does not support X509PKIPathv1 value type, I am generating the SOAP message by hand, signing it using the SignedXml class, encrypting it using the EncryptedXml and sending it using the WebClient class. As for the value of BinarySecurityToken element, I used the value generated in SoapUI for the same certificate, and it works.
But, I would like to be able to generate this value programmatically from .p12 file, and not having to paste it from SoapUI again every time when the certificate expires.
The WS-Security documentation is a bit vague, so I am not sure how to go about it. This is all the information it gives about this token type:
#X509PKIPathv1: An ordered list of X.509 certificates packaged in a PKIPath
How to generate this value from .p12 file in C#? SoapUI does it somehow.
So this may not be a fully solution to your problem but it may help you out somewhat.
This:
#X509PKIPathv1: An ordered list of X.509 certificates packaged in a PKIPath
means is a asn1 sequence or chain of certificates that you have used to sign your message. You can even see it here.
To give some context asn1 is way of representing data in way independent of the machine you are using. This data is binary and not human readable so you transform it to bade 64 and that is what you see in that field.
I am not entirely sure what the exact content of your .p12 file is but at the very least I assume it has the certificate of the private key you used to sign your message and maybe the chain until the publicly trusted certificate or CA.
I am mostly a C++ developer and I know openssl provides a C like api to read a certificate manipulate the underlying asn1 structure and the output it as a string.
Sorry for not providing with a greater level of detail or a code example
I'm attempting to make a client that uses WCF to communicate with a SOAP endpoint made in Java. The service requires me to send my PKCS10 request inside a encrypted SOAP request, using a X509 certificate that I have received from the service using another function, but I can't figure out how to configure WCF properly to allow me to only encrypt but not sign, seeing as I have yet to receive my final certificate from the service.
I've tried to set the X509 certificate I've received from the server as both DefaultCertificate for the service and the ClientCertificate, but no matter what kind of options I set for the binding and endpoint, I always end up with the error "The private key is not present in the X.509 certificate" and that's because (I assume) there are only the following ProtectionLevels in WCF:
None
Sign
EncryptAndSign
I understand the error here because obviously I haven't received the service's private key and setting the service's certificate as the ClientCertificate I would expect this error, but is it me who has misunderstood something here?
Shouldn't it be possible for me to just encrypt the SOAP envelope using the service's public key that I've already received, without having to sign it as well with my own private key (which I haven't actually received yet)?
I have implemented a SOAP client based on the code in this thread Client to send SOAP request and received response however I would now like to extend this to allow us to encrypt the soap message using X509 certs and tripleDes and wondered if there was a starting point. the output payload i am looking for will need to include an xml segment based on schema http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd and probably also include headers, anybody have any links to behind the scenes with soap encryption.
I have found this Creating Signed SOAP Message as a String with C# aqrticle which seems to be having a similiar issue, where is the theory behind creating the hash values for soap signing.
Bit late to my own funeral but it appears the solution is here:
Creating Signed SOAP Message as a String with C#
I do not understand when I should put the [MessageHeader] instead of the [MessageBodyMember]?
I have read that it's used to conform some protocol like Soap, but still, what does it change at the end?
SOAP is a protocol in which each message (request or response) is made up of two parts: the Header and the Body, inside an Envelope:
<s:Envelope xmlns:s='the namespace for the soap version'>
<s:Header>
<!-- SOAP headers will come here -->
</s:Header>
<s:Body>
<!-- SOAP body members will come here -->
</s:Body>
</s:Envelope>
You normally wouldn't use [MessageContract] (and MessageHeader or MessageBodyMember) in WCF services, only if you really need to interop with some 3rd party which expects the data in a certain format.
I think when I want to put something independent of message content, I will put it in the message header.
And if you want another party to read something from your message, it should be put in the header, because sometimes you may allow someone to read the message header not message body as it contains confidential contents.
You can think about it as difference between message data (MessageBodyMember) and message metadata (MessageHeader). There is plenty of build in standardized headers provided by WCF which deals with addressing, security, reliable messaging, etc. In default WCF implementation it is related only to SOAP.
There is also general rule that in complex messaging architecture there can be intermediaries who read metadata and use them to some processing and message routing (they can even add additional metadata) but they should never interfere with message body (data). In case of security they can even not be able to read message body or some metadata (headers).
In case of WCF you are able to set different security requirements (none, signed, signed and encrypted) for each message header and for whole message body (WCF doesn't support separate security requirements for different body parts). That can also lead to some decision about using body member or header.
For example if you decide to make some custom authentication, or transferring some client information in each message you will probably create custom header for that but real data payload related to the operation will be part of message body.