Hi Team,
I am trying to send a SAML request to IdP server and want add signature of our SP certificate. My problem is i don’t have certificate in my application Directory.
So while sending request using below code ComponentSpace not putting certificate signature in SAML artifactResolveXml while sending request .
May i know how i can configure my application so that it will take certificate file from server based on subject name and put the signature using private key of the certificate files.
Also i can take response and decrypt based on IdP certificate public key.
Please also provide me the configuration file sample as well.
I am using below details to connect IdP server :-
Request Binding :- HTTP-Artifcat
API :- Low level API.
Certificate :- All certificate installed in server we have details but not files in my application.
Code to send Request :-
XmlElement artifactResponseXml = ArtifactResolver.SendRequestReceiveResponse(spArtifactResponderURL, artifactResolveXml);
spArtifactResponderURL :- IdP SOAP end point URL. Correct me if i am wrong.
artifactResolveXml :- XML request with private key Signature. but i am not able to get xml with signature because my SP certificate is not in application folder.
Thanks,
Pramod
Hi Pramod
You’re correct. The spArtifactResponderURL is the artifact resolution service URL at the IdP. It’s where you send the artifact resolve request over SOAP.
When you say you want to load the certificate by subject name, I assume the certificate is installed in the Windows certificate store.
The following code demonstrates loading the certificate from the certificate store and signing the artifact resolve request.
X509Store x509Store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
x509Store.Open(OpenFlags.ReadOnly);
X509Certificate2Collection x509CertificateCollection = x509Store.Certificates.Find(
X509FindType.FindBySubjectName, “subject-name-goes-here”, false);
if (x509CertificateCollection == null || x509CertificateCollection.Count == 0)
{
// Handle certificate not found.
}
X509Certificate2 x509Certificate = x509CertificateCollection[0];
x509Store.Close();
SAMLMessageSignature.Generate(artifactResolveXml, x509Certificate.PrivateKey, x509Certificate);
[quote][/quote]
Hi Pramod
You're correct. The spArtifactResponderURL is the artifact resolution service URL at the IdP. It's where you send the artifact resolve request over SOAP.
When you say you want to load the certificate by subject name, I assume the certificate is installed in the Windows certificate store.
The following code demonstrates loading the certificate from the certificate store and signing the artifact resolve request.
X509Store x509Store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
x509Store.Open(OpenFlags.ReadOnly);
X509Certificate2Collection x509CertificateCollection = x509Store.Certificates.Find(
X509FindType.FindBySubjectName, "subject-name-goes-here", false);
if (x509CertificateCollection == null || x509CertificateCollection.Count == 0)
{
// Handle certificate not found.
}
X509Certificate2 x509Certificate = x509CertificateCollection[0];
x509Store.Close();
SAMLMessageSignature.Generate(artifactResolveXml, x509Certificate.PrivateKey, x509Certificate);
You're correct. The spArtifactResponderURL is the artifact resolution service URL at the IdP. It's where you send the artifact resolve request over SOAP.
When you say you want to load the certificate by subject name, I assume the certificate is installed in the Windows certificate store.
The following code demonstrates loading the certificate from the certificate store and signing the artifact resolve request.
X509Store x509Store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
x509Store.Open(OpenFlags.ReadOnly);
X509Certificate2Collection x509CertificateCollection = x509Store.Certificates.Find(
X509FindType.FindBySubjectName, "subject-name-goes-here", false);
if (x509CertificateCollection == null || x509CertificateCollection.Count == 0)
{
// Handle certificate not found.
}
X509Certificate2 x509Certificate = x509CertificateCollection[0];
x509Store.Close();
SAMLMessageSignature.Generate(artifactResolveXml, x509Certificate.PrivateKey, x509Certificate);
Hi team,
Thanks for your reply. Is the certificate files are provided by the client (Service Provider certificate files) or we have to generate the certificate file and ask to install it in server ?
We have our server in cloud environment and there is no certificate files installed . I am not sure if client need to install or we have to generate the certificate file and give them to install it.
As per my understanding certificate (.pfx extension) should be provided by the client and it should contains private key. Client provided us a certificate (.cert) files which have only public key.
They not provided any .pfx file till now. Is it compulsory to install in server or we can just ask .pfx extension certificate file ?
Note :- My question is related to Service Provider Server not IdP provider server. IdP certificate file will be given by IdP team.
The IdP and SP should never exchange private keys (ie PFX files).
Private keys should always be kept secret to the organization owning the private key and never shared with external organizations.
As the SP you will sign the artifact resolve request using your private key (eg SP PFX file).
The IdP will verify the signature using your public key (eg SP CER file).
This is similar to the IdP signing the SAML response or SAML assertion using its private key (eg IdP PFX file) and the SP verifying the signature using the IdP’s public key (eg IdP CER file).
As for storing certificates, whether they include a private key or not, you have the following options.
1. Windows certificate store.
2. File system (PFX or CER file).
3. Base-64 string stored in SAML configuration (eg saml.config file).
[quote][/quote]
The IdP and SP should never exchange private keys (ie PFX files).
Private keys should always be kept secret to the organization owning the private key and never shared with external organizations.
As the SP you will sign the artifact resolve request using your private key (eg SP PFX file).
The IdP will verify the signature using your public key (eg SP CER file).
This is similar to the IdP signing the SAML response or SAML assertion using its private key (eg IdP PFX file) and the SP verifying the signature using the IdP's public key (eg IdP CER file).
As for storing certificates, whether they include a private key or not, you have the following options.
1. Windows certificate store.
2. File system (PFX or CER file).
3. Base-64 string stored in SAML configuration (eg saml.config file).
Private keys should always be kept secret to the organization owning the private key and never shared with external organizations.
As the SP you will sign the artifact resolve request using your private key (eg SP PFX file).
The IdP will verify the signature using your public key (eg SP CER file).
This is similar to the IdP signing the SAML response or SAML assertion using its private key (eg IdP PFX file) and the SP verifying the signature using the IdP's public key (eg IdP CER file).
As for storing certificates, whether they include a private key or not, you have the following options.
1. Windows certificate store.
2. File system (PFX or CER file).
3. Base-64 string stored in SAML configuration (eg saml.config file).
Hi Team,
we have purchase a cert file .pfx file for pivate key but when i tried to sign the signature it throws error. I am not sure what went wrong . Is it cert file issue or i miss something in code.
My code is :-
SAMLMessageSignature.Generate(artifactResolveXml, x509CertificateSP.PrivateKey, x509CertificateSP);
Error is in SP.log file
System.Security.Cryptography.Xml.SignedXml Information: 10 : [SignedMessage#021a11ca, Signing] Calculating signature with key RSACryptoServiceProvider#"te-600958fa-5361-42a5-80e2-45c64f62a85d" using signature description RSAPKCS1SHA256SignatureDescription, hash algorithm SHA256Cng, and asymmetric signature formatter RSAPKCS1SignatureFormatter.
ComponentSpace.SAML2 Verbose: 0 : 8952/3: 6/18/2018 5:42:45 PM: XML signature method: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256.
ComponentSpace.SAML2 Verbose: 0 : 8952/3: 6/18/2018 5:42:45 PM: XML digest method: http://www.w3.org/2001/04/xmlenc#sha256.
ComponentSpace.SAML2 Verbose: 0 : 8952/3: 6/18/2018 5:42:45 PM: Inclusive namespace prefix list: #default samlp saml ds xs xsi.
ComponentSpace.SAML2 Verbose: 0 : 8952/3: 6/18/2018 5:42:45 PM: XML element ID: _857fd20c-2856-4b3e-86ba-cc94f24a375f.
ComponentSpace.SAML2 Verbose: 0 : 8952/3: 6/18/2018 5:42:45 PM: The signing key type is RSACryptoServiceProvider.
ComponentSpace.SAML2 Verbose: 0 : 8952/3: 6/18/2018 5:42:45 PM: The signing key's associated cryptographic service provider, "Microsoft Enhanced Cryptographic Provider v1.0", doesn't support SHA-256 signatures.
ComponentSpace.SAML2 Verbose: 0 : 8952/3: 6/18/2018 5:42:45 PM: Exception: ComponentSpace.SAML2.Exceptions.SAMLSignatureException: Failed to generate the XML signature. ---> System.Security.Cryptography.CryptographicException: Invalid algorithm specified.
at System.Security.Cryptography.CryptographicException.ThrowCryptographicException(Int32 hr)
at System.Security.Cryptography.Utils.SignValue(SafeKeyHandle hKey, Int32 keyNumber, Int32 calgKey, Int32 calgHash, Byte[] hash, Int32 cbHash, ObjectHandleOnStack retSignature)
at System.Security.Cryptography.Utils.SignValue(SafeKeyHandle hKey, Int32 keyNumber, Int32 calgKey, Int32 calgHash, Byte[] hash)
at System.Security.Cryptography.RSACryptoServiceProvider.SignHash(Byte[] rgbHash, Int32 calgHash)
at System.Security.Cryptography.RSAPKCS1SignatureFormatter.CreateSignature(Byte[] rgbHash)
at System.Security.Cryptography.AsymmetricSignatureFormatter.CreateSignature(HashAlgorithm hash)
at System.Security.Cryptography.Xml.SignedXml.ComputeSignature()
at ComponentSpace.SAML2.Utility.XmlSignature.Generate(XmlElement xmlElement, String elementId, AsymmetricAlgorithm signingKey, KeyInfo keyInfo, SignedXml signedXml, String inclusiveNamespacesPrefixList, String digestMethod, String signatureMethod) in C:\Sandboxes\ComponentSpace\SAMLv20\Library\Utility\XmlSignature.cs:line 545
--- End of inner exception stack trace ---
[quote][/quote]
The IdP and SP should never exchange private keys (ie PFX files).
Private keys should always be kept secret to the organization owning the private key and never shared with external organizations.
As the SP you will sign the artifact resolve request using your private key (eg SP PFX file).
The IdP will verify the signature using your public key (eg SP CER file).
This is similar to the IdP signing the SAML response or SAML assertion using its private key (eg IdP PFX file) and the SP verifying the signature using the IdP's public key (eg IdP CER file).
As for storing certificates, whether they include a private key or not, you have the following options.
1. Windows certificate store.
2. File system (PFX or CER file).
3. Base-64 string stored in SAML configuration (eg saml.config file).
Private keys should always be kept secret to the organization owning the private key and never shared with external organizations.
As the SP you will sign the artifact resolve request using your private key (eg SP PFX file).
The IdP will verify the signature using your public key (eg SP CER file).
This is similar to the IdP signing the SAML response or SAML assertion using its private key (eg IdP PFX file) and the SP verifying the signature using the IdP's public key (eg IdP CER file).
As for storing certificates, whether they include a private key or not, you have the following options.
1. Windows certificate store.
2. File system (PFX or CER file).
3. Base-64 string stored in SAML configuration (eg saml.config file).
Full Error while try to get sign using ComponentSpace Jar
ComponentSpace.SAML2 Verbose: 0 : 2572/7: 6/18/2018 7:31:08 PM: Enabling support for SHA-256, SHA-384 and SHA-512 signatures.
ComponentSpace.SAML2 Verbose: 0 : 2572/7: 6/18/2018 7:31:08 PM: Generating an XML signature.
System.Security.Cryptography.Xml.SignedXml Information: 3 : [SignedMessage#03ff1264, BeginSignatureComputation] Beginning signature computation.
System.Security.Cryptography.Xml.SignedXml Information: 7 : [SignedMessage#03ff1264, NamespacePropagation] Propagating namespace xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol".
System.Security.Cryptography.Xml.SignedXml Information: 0 : [SignedMessage#03ff1264, BeginCanonicalization] Beginning canonicalization using "http://www.w3.org/2001/10/xml-exc-c14n#" (XmlDsigExcC14NTransform).
System.Security.Cryptography.Xml.SignedXml Verbose: 0 : [SignedMessage#03ff1264, BeginCanonicalization] Canonicalization transform is using resolver System.Xml.XmlSecureResolver and base URI "".
System.Security.Cryptography.Xml.SignedXml Verbose: 5 : [SignedMessage#03ff1264, CanonicalizedData] Output of canonicalization transform: http://www.w3.org/2000/09/xmldsig#"><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"><Reference URI="#_54ccab96-2d2e-4cbb-99a4-f309d498f6f5">http://www.w3.org/2000/09/xmldsig#enveloped-signature"><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="#default samlp saml ds xs xsi">ysHEAHsgTC6Ie63v0EH3CfIWh65u5Dw+jNZMcFfSBKQ=">http://www.w3.org/2001/04/xmlenc#sha256">ysHEAHsgTC6Ie63v0EH3CfIWh65u5Dw+jNZMcFfSBKQ=
System.Security.Cryptography.Xml.SignedXml Information: 10 : [SignedMessage#03ff1264, Signing] Calculating signature with key RSACryptoServiceProvider#"{51C8C619-89AD-4559-9789-17808E81201A}" using signature description RSAPKCS1SHA256SignatureDescription, hash algorithm SHA256CryptoServiceProvider, and asymmetric signature formatter RSAPKCS1SignatureFormatter.
ComponentSpace.SAML2 Verbose: 0 : 2572/7: 6/18/2018 7:31:08 PM: XML signature method: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256.
ComponentSpace.SAML2 Verbose: 0 : 2572/7: 6/18/2018 7:31:08 PM: XML digest method: http://www.w3.org/2001/04/xmlenc#sha256.
ComponentSpace.SAML2 Verbose: 0 : 2572/7: 6/18/2018 7:31:08 PM: Inclusive namespace prefix list: #default samlp saml ds xs xsi.
ComponentSpace.SAML2 Verbose: 0 : 2572/7: 6/18/2018 7:31:08 PM: XML element ID: _54ccab96-2d2e-4cbb-99a4-f309d498f6f5.
ComponentSpace.SAML2 Verbose: 0 : 2572/7: 6/18/2018 7:31:08 PM: The signing key type is RSACryptoServiceProvider.
ComponentSpace.SAML2 Verbose: 0 : 2572/7: 6/18/2018 7:31:08 PM: The signing key's associated cryptographic service provider, "Microsoft Enhanced Cryptographic Provider v1.0", doesn't support SHA-256 signatures.
ComponentSpace.SAML2 Verbose: 0 : 2572/7: 6/18/2018 7:31:08 PM: Exception: ComponentSpace.SAML2.Exceptions.SAMLSignatureException: Failed to generate the XML signature. ---> System.Security.Cryptography.CryptographicException: Invalid algorithm specified.
at System.Security.Cryptography.CryptographicException.ThrowCryptographicException(Int32 hr)
at System.Security.Cryptography.Utils.SignValue(SafeKeyHandle hKey, Int32 keyNumber, Int32 calgKey, Int32 calgHash, Byte[] hash, Int32 cbHash, ObjectHandleOnStack retSignature)
at System.Security.Cryptography.Utils.SignValue(SafeKeyHandle hKey, Int32 keyNumber, Int32 calgKey, Int32 calgHash, Byte[] hash)
at System.Security.Cryptography.RSACryptoServiceProvider.SignHash(Byte[] rgbHash, Int32 calgHash)
at System.Security.Cryptography.RSAPKCS1SignatureFormatter.CreateSignature(Byte[] rgbHash)
[quote][/quote]
The IdP and SP should never exchange private keys (ie PFX files).
Private keys should always be kept secret to the organization owning the private key and never shared with external organizations.
As the SP you will sign the artifact resolve request using your private key (eg SP PFX file).
The IdP will verify the signature using your public key (eg SP CER file).
This is similar to the IdP signing the SAML response or SAML assertion using its private key (eg IdP PFX file) and the SP verifying the signature using the IdP's public key (eg IdP CER file).
As for storing certificates, whether they include a private key or not, you have the following options.
1. Windows certificate store.
2. File system (PFX or CER file).
3. Base-64 string stored in SAML configuration (eg saml.config file).
Private keys should always be kept secret to the organization owning the private key and never shared with external organizations.
As the SP you will sign the artifact resolve request using your private key (eg SP PFX file).
The IdP will verify the signature using your public key (eg SP CER file).
This is similar to the IdP signing the SAML response or SAML assertion using its private key (eg IdP PFX file) and the SP verifying the signature using the IdP's public key (eg IdP CER file).
As for storing certificates, whether they include a private key or not, you have the following options.
1. Windows certificate store.
2. File system (PFX or CER file).
3. Base-64 string stored in SAML configuration (eg saml.config file).
I have also tested certutil -dump XXXX.pfx commend to know about cert. It given me below provider
Non-root Certificate
Cert Hash(sha1): 09b2858fb89cd5c4670a62380dc060ee5787a901
---------------- End Nesting Level 1 ----------------
Provider = Microsoft Enhanced Cryptographic Provider v1.0
Encryption test passed
CertUtil: -dump command completed successfully.
May i know to whom i need to contact to correct the provider ? Shall i need to contact cert file provided company ? or it's our responsibility to check the make it correct provider ? If cert provider can do that then we can ask them. Please provide possible option. Even if i can do that let me know how we can process ? We need to give our .pfx file to install in cloud environments as soon as possible.
You will need to update your PFX file to specify the correct cryptographic service provider associated with the private key.
Please refer to the following forum article which describes using openssl to update your PFX file.
https://www.componentspace.com/Forums/1578/SHA256-and-Converting-the-Cryptographic-Service-Provider-Type