I have SAML Response and Metadata URL provided by Client (Identity Provider). How I (Service Provider) Can decrypt the SAML Response
Below is the SAML Response
<samlp:Response ID="_17222aef-2970-44d1-aae6-1c25187c4319" Version="2.0" IssueInstant="2017-06-29T10:23:12.036Z" Destination="https://ssotest-1246771484.ap-south-1.elb.amazonaws.com/ssotest/index.html" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
InResponseTo="a351b3fi19a2024838868e374da59j6" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://yyy.xxx.com/adfs/zzz/trust</Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
</samlp:Status>
<EncryptedAssertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<e:EncryptedKey xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
</e:EncryptionMethod>
<KeyInfo>
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509IssuerSerial>
<ds:X509IssuerName>CN=apollo, OU=R&D, O=RM5 Software Oy, L=Helsinki, S=Uusimaa, C=FI</ds:X509IssuerName>
<ds:X509SerialNumber>1357039681</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</KeyInfo>
<e:CipherData>
<e:CipherValue>f6yX7d1FF4eHtj79WRxJ/xga3qhUASk79sTHWDfKW/bHbIGL+UVwBIdQIh21AMbLN/1cgiVCps7UBAoaipew7JQCq1EYQR/ipFO7Wcmoqs5V1h/KwBgNdhT/L/TqAacIz9QoRPkNhxsDAKMvdj9wwPZhYHGvqC1cFgrMZjMS4r1VlF2qh2TgQVgv9PjA234dZfNLTUmu1WNRjs30mtcZAZtnwB8A6sUwQsJCSfKfXoTcEAYrD2Am+9FQdHBnrZ3HwtH1gkbe0pAYtEPqX+yzRm7wtsMLj9F4+PoE1Ax3Ju3kpPiV5u1au1CCJG8CzuxbswFII4npKlwjuKm9y7A8YA==</e:CipherValue>
</e:CipherData>
</e:EncryptedKey>
</KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>ACrn2shusd+psIv2ITQHz8rsc1JVUk0pCspUt1r4vJVdgP3M9+5Lm8b5lBlY3WeDti3LhCGaHAK+VKkugls5HpHppwZ+WQF5NKJIEpxGw0N8RDdzD5tZp+iF2v+1oCsuX6r72r9sXSaL3hoZ7xpoNnspUvhIj5A2bxUt1/l5I+i1CQYbeoX9ATbOCGJ3mEuHotEy6ZAOlrLUISUGLUFWY6MnrYuArYPuMndcZF7a3OwsRA6H2Y4Rgx7gKqmGJz7hUD0tL7VTyn5p6WVaSaNudfjjDadF3VI2DJDPShLUDXhejFEcKN6twaSK4uUltpxmWqGb9mb/RB4+aCbN22tqwQptJOpqE72e7Bm+EbdSMoR0y9fwoAzuKq3X4JSJhN4oBH7FQIimmHxgd/+6m7bRJbbrEnRqu4ndEZJ9f17dKg23ToVB5fERjzvtQh2nOP9laPTGQJCYu5eJ322DXs6Cj1cf7D9s6sqPam5emyFMHnEb61O3PiT4RZ5j5t9VQe8xs9IFiL0LcAr+a0e2mN7Wa3w/9O1PLmiub752757P2JmQm+Gkx/XQqe4GknxEiOC/cHV4C5fTW5e8tGns3dgpvkS9/Pxk8EdYWTfK87ZRrslG5ZkBQSNA3+fpw1yMdYF9HQFpfWLgFpbhLi1Srn+f86dM+pRuXG6kKwnuzzkB6Kq6Rokc3eHs2h1c9YGFfQLhD8BPsjnUM3Hd4t/8kVOP4Oybd1pN/50HoMdv4QD52a8UaWs9h31tH7ikdbBf2gRnOJ5a/hKddVBX+J54xlT1fx8XcTLJUHGh8E5YdrgsN1iQEEvXkp4B/jwiw9qd78+SIZx+8I2Yty9Ng2LnyAdskHg3jZfXGZD3UjYjsLjE6zSXr4Bq6s2qURUBBIAqBmTsWmA4kok6KkTrPwaTba4Ynuu1AZPZRPtSYfde9u8WH4RFBSXYOps/2x9opHrxyH3L45p1g3RjMsJyEbbO4oS4XwjSHeTZLN329jFHNuqLxCmbfA9CdTUjFsUi9bMPC0Cu0L7SmTiu/PJLaBTeKv60v1xYwcKAjTOwj0fNeIs3edH9adBco5C5Nv9OTds1IOK7udw7p50ZZ7jupk0KdWCTopxrKLU4Y3SFFA5gxMu4L0tLLzSjDVDqHUl3SlQe9MLmOB0grAZZcNbDLFJH8JPPrDkw8uOvjVSJSOwgxpJL6+UqvPHm/sHGsqhUbVUd/mkxBVcvI/hbHq1Mbnxf98/2rdPvKzJBDlwqOH+o2HTujc0cl+xhTuI9tiKgtzGSSKsNQR3fJi1nIdJdViYEeDgtCJAjhTCBiToLQYijxgzoFxdgAeP8artw3Jw8qCgeFgeq9q5p3i/Xq3tlgWltMkVKdpnc/LyIlvdOjpKs4STkcoqXa02Tm9EkJwLNvyzcvBJ0LUY93vi+Wqdy/BlCFsJpma8wbvqsXGnSrdgAYVlsB8vKJTxgnyxGY1aEP2zGqH7pCmYgVKm1tjG6DGVjGaO5rKdjYmCH35gZ3LCgkJ7BvOpv+SrEBpBIMjYl9d4Gda1jMD+YL4bH9loGb8v2MKGXK9eK1qCPlKIZ2JW1QSQ7J0pJF4M0pK1pkm1FoElZICmVDlHWK1BHoyHKvC8kGwWMntGYwOCLWpXEoRx2e+T7WIZ/+OJ7fAVfMG7fv+i1JiwXILylLO2FjE4YVrtPx4npiUlSEgxky0NvRlqiLn5j+0fnK19qZE07B3Anq7oVY7181sDEhHz7gZJRcgpGtrWg1Ai311ITiMbnbolXN0zg2svH1u7dtB1+X71sX5icKL/lQHSuyxa6JxP4iWYXu2/9jgpEmiLCadMCRq53eshwIjcbY1+kCpS1+ODCCsAnkFhi9dCoAaRHR3JQYdt21mfOomhbPrCaUpWgW2UnzUYiiNP0+EiyORgpru8jLGLQgG1h9+AMWzIu5cyuA3Q8uR084WnDidpOSKMV1I/s83n641/uSDyCJ+v5M2tjr4BJyrO0Fx4ulgeu0VPrdvPhMzzq6l/KV1LXZI995KMjY4mEFOtHxwXZO+YxIKAxdeSWUaBFPG32dInwyHzODml9K6m79pCYDtQpO3x/Jt7XqeAD92deY9qFA0Gz3uQizQas7S+qLdsMd6qea0a9vkkJnOtZd0P848+LCi7LdL9VkEEZp44txpq19AUlqf8Ocmn99PqFeZ7RV4nKaTMh21uD0kb8TmlFotIMO/K5bPiNA0mQ7+60EBLe9soXijqg50/qPVdoP1xiQq4nD1KYX5Ks7qQw2ukcATvYiQX8WRP25IQyMAdc6zkqxB7eqMIYIX6phElb+0uwfpGTzyZ4PRozR4ns3q2Y99MSDdDgauJ3duantpFIW72o4UpiAwuxR4Fzc86OwKAIK6WjfJNytBmHSMvFax3dV6QJZhUvLOd+Sn0iT6dH8rgERQ9ek4+4hZkHvsraOTxh7/Bi16++aJZrsEf1YyKx+M9NjJNW6mtKRIKkoQCPDgjuk3GE6h/KjUhaR/Vf5QYyYXyZDnqu9S72elP4yPyrYwVQsMkCH7s4ld+xTpuevN90AjxkP8JjNlU8dzOTWsmRuCdT+IpuUB2KWxG8POWTXKfpnn7D512br8Fw2Dmi8nUuQb5Qlug20vDYKuCJuX2mVJhtYFEoHoZjeDmPKznL6hzpdVbU93K8BNog1ssJFYrYdKsbclzuHJN/x4IPb7PSNM9rsa2VOcCHeWz0KcCmhXG4Dd5cqYo7QBORytG2lFvimudlgEGKRWMU7F7cb7StQsQHIiPuM4Zoai7szWuWPauZ0xRcyO2IHvjrWn0RnQE53pXwb3BodUfNdWsSYnCxXmu7SXT7VZeeWQoIWRCzqKJ8eAQ7w/lrHw8iGgUEBgZjKFma3POCQEEdIA8ZNytX+/uP1L1PYHsmgi5yOwgcrNgth2ok84Yl0DESSvJYCfRwZiqNY/N2VIMO/lmWqRQvep05h/iNbEnXbPcE5O+fObFKgltfS/6ob8rMxt0so/Uwq90wTCR/4VUii+CcFvgkZSrsemlB6kSrIxAYrSptz4hsgKwrcMV2tQX4i5VRsmMTxPgD8WgfaHcbqpEJR/L0MW+/8E1QuUtKmmktUWeY3HgHyjoi4yylPNBUmf1w5qeGzwduluWrOLeYjiFRVyTMdEWe2k+2OIuoLsKG9zj+cZYybC9vBM90T1SBJrPPyIpYpUxJHQ2WScaSr1NkfwZwYeTQhUO1tCHPeVMOMEatXLUneeTa5IgWWZL5V1eCCqrr1Plqbbpoy9mUUjHAtorNNPVQfstK16GPesq2irRnZTtgmUyBFvl9TQ6fZnFT3RwglM/Z/KZHrNaloc525lDnHWlrK9ZDB5q72krF3oD1xsaN/14dLsCnNABgbQcT53x519zBHDe0fb25aUoanKyEd1Kj8iAnb0QQQJzRWK9XPr6fuU8x19Dmqr+4Z89b9YDJJJf0OyZJ49ETGXGrV6PEGvrilAmRQo2KWIdxxWxASpzBYUYtrKqSwsvUsGX48HwIwaZbqYp7QNknHRGXBgK+arP3B4NRqloqgjsmwyQDyzkV9OShYbJdGc4vR0RDMwGR2MIkhTi/Tr8QV42lsIPxhOuizJhyKOeabsdIzhLjcQ0YHVg+KawrdbDV7Cag5cdwDM00ez2Ej/JLUHWJ6/Dp1r6LpGSdUWlz/goChgUC//WXrqV7VKyfqDn4HOXx4B7MExYQ6wjgcfxHLF1eQWItE2ggtM5IvlgcgA6hir2IY0ENOK0KcISd3mBkInamA85ehRK+SZaMFvwsQCfMrI5iEfpiMGYvINHtXbFKlwYLf0V0wQynVqksCs9T+667US+8I2+NcHSPeBJpaWY5gAsPlpN8L9LeO8g0pKPEfalayK+FTSaGCxRvMQOhIabXxiF3M9eNTXM41K0IEdIqUDc9WLTbEdIXxvzCCnvJmgKRQr1qkFlSVpP7SgM+tR5+x+6keFp3GHYAYbvGZipkYdAvIHnYIG7rL8Pux+fKWZ0yF5ScGJBGq+uCM91IgWNCnWA1ukp+vO4A2RW5Kjbpei611sjgZ7CJKjj2Wbz6cRj8D4ahlpLAm6ybhxNTxipLNSBOU7SMl9MltDPZ3lzQHssW2vThYLeKXezJ7JSwlAKC1u4x9GwpoQiZsqoQoMqHqzcgGYKNfyktp8sRrtsIBXhnq7hX2eiwDXTFCjQGqvdC8topw1vGrtGU9HsYgdyZR0iVo2lJ+Cifp7JtaDE6mYYkqMUtn2REubl6hpaLnfRzlRv2GTCBGXz04Z/TbY9llhHVpOMsdbD6WpIBH4euFA3No5EplHlaG54bjrpOYWr6A5xx5GU26wvlu7JlAV+YrXfmAFmsocbjTiiM45ah</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
How encryption scenario works in SAML: identity provider encrypts some elements of the SAML response with service provider's public key. The service provider decrypts using the private key that corresponds to the public key used to encrypt. In other words, the service provider needs to own a keypair - private key and public key - for this use case to work.
Assuming you have the private key for decryption, you just need to decide on the implementation approach. Rolling your own is technically possible but unlikely to succeed. For .NET we recommend either Sustainsys or ITFoxtec, both are OSS and support decryption.
Related
I have followed the Microsoft documentation to encrypt the Assertions, but it gives me some error.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/connect-with-saml-service-providers#enable-encrypted-assertions-optional
MetaData:
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://samltestapp2.azurewebsites.net">
<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration=" urn:oasis:names:tc:SAML:2.0:protocol">
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
<AssertionConsumerService index="0" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://samltestapp2.azurewebsites.net/SP/AssertionConsumer"/>
<KeyDescriptor use="encryption">
<KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>MIIDODCCAiCgAwIBAgIQEaP5fKYAQ6VBxbBPDi/IVDANBgkqhkiG9w0BAQsFADAv MS0wKwYDVQQDDCRlbmNyeXB0aW9uLm9kZmxkZW1vNS5vbm1pY3Jvc29mdC5jb20w HhcNMjEwMTE5MDQ0NDQzWhcNMjIwMTE5MDQ1NDQzWjAvMS0wKwYDVQQDDCRlbmNy eXB0aW9uLm9kZmxkZW1vNS5vbm1pY3Jvc29mdC5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQClIee7OMFzTsZ3eDdTpDJOB0qsZCiGug3DtOoBrZsY pG6SNI1z7hPWiMJBJWaGrSPF/FcKS/RaOZi+G/Ht7RR+4qTzY2toqD7R7HYL8fyg lNx9d0n2RDRlgIHo9vtopw9fZaiEsvY3DiWWed9EvhQPyn9ewiZBWDLIlyOFT6oo jTiz6/xMneI96l8A7IQ+TAQbH2oUTaDTHksehmeVk3ExeWvgmfTzE812kzRMmWeP awlLJrCtRUu+NvxfDcmbv7bzxRfyDmM8gw7MIqELkIG4rNfFn0VvDnA7+oECm2DQ LKZgJZkAHJ+UWbKGj39CqOy6vkjA20pPtlhob5hp2qv1AgMBAAGjUDBOMA4GA1Ud DwEB/wQEAwIHgDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwHQYDVR0O BBYEFC1rpD8SwvSUXRvLJY072Vtf21LfMA0GCSqGSIb3DQEBCwUAA4IBAQBmD7MU vVXyX7nZ3h1rvhQUI4ryd3DUNdWZA2frdPm8xx6WQfEJKlYLKsRErcaCFXc9CGFK 2Ijfb9D0NxYo9JNJd9c2j2sDgZyxud5zn9xmSb3VZ42E+9y8NQz+UCYl6xlRIwwh vIdRpsVhmcXjcpW9Sos2kZ5wOnnROp6VwYTKSVDJyJYXPEz8is7Hhv5a7gsDW2pO GQAZXKxuH10IIpudxBszdwRGt3O945hyGsJNySljvvwoPiBwtZbSQbjpzmMGkFU9 BetAjN25+kSa8CNjv2wbLbs4boY/SmVTxMDHQpZ6k9fdms2Rdidl0o6BKKtjdkeE fH/F9XGJ2EbQKNwD</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
</SPSSODescriptor>
</EntityDescriptor>
Relying party file:
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignInSAML" />
<UserJourneyBehaviors>
<JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="xxxxxxxxxxxxxx" DeveloperMode="true" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
<ScriptExecution>Allow</ScriptExecution>
</UserJourneyBehaviors>
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="PartnerEntity">{Settings:MetadataURL}</Item>
<Item Key="ResponsesSigned">false</Item>
<Item Key="WantsEncryptedAssertions">true</Item>
<Item Key="IdpInitiatedProfileEnabled">true</Item>
</Metadata>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="surname" />
<OutputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="sub"/>
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
Saml2AssertionIssuer:
<TechnicalProfile Id="Saml2AssertionIssuer">
<DisplayName>Token Issuer</DisplayName>
<Protocol Name="SAML2"/>
<OutputTokenFormat>SAML2</OutputTokenFormat>
<Metadata>
<!-- The issuer contains the policy name; it should be the same name as configured in the relying party application. B2C_1A_signup_signin_SAML is used below. -->
<Item Key="IssuerUri">{Settings:SignupSignInSAMLIssuerURI}</Item>
</Metadata>
<CryptographicKeys>
<Key Id="MetadataSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
<Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
<Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlIdpCert"/>
<Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SamlIdpCertEnc"/>
</CryptographicKeys>
<InputClaims/>
<OutputClaims/>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer"/>
</TechnicalProfile>
I am getting the below error. It is working properly without encryption, but if I enable the encryption getting that issue. Can someone suggest me a way to resolve this error.
Thanks #Saravana. WantsSignedAssertion indicates whether the technical profile requires all incoming assertions to be signed and SAML Response Assertion elements received by the relying party application must be signed. B2C requires both, the message and the assertion to be signed. If only assertion is signed, then it fails, and B2C does not accept it.
Please verify with the SAML decoder tool and see if both the assertion and the message are signed or not.
Please let us know if you need more help.
Reference:- https://github.com/azure-ad-b2c/saml-sp/blob/master/saml-rp-spec.md
I'm trying to decrypt a Web.config section that was encrypted with RSA from an external Powershell script. The section goes:
<connectionStrings configProtectionProvider="RsaProtectedConfigurationProvider">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>.......</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
<CipherData>
<CipherValue>.......</CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>
The code goes:
[xml]$x = Get-Content "$Path\Web.config"
$Prov = New-Object System.Configuration.RsaProtectedConfigurationProvider
$Prov.Decrypt($x.configuration.connectionStrings.EncryptedData)
It's executed via remote Powershell on the server where the config is. The account is an admin, so local machine keys should be available. And I'm getting an error:
Value cannot be null. Parameter name: keyName
An identical, modulo provider name, fragment works for DPAPI encrypted sections. The key name is right there in the section. What am I missing here?
Update: when the Web code does it, it calls Initialize() on the provider first. I've mimicked the parameters on that Initialize call. They come from machine. config.
$nv = New-Object System.Collections.Specialized.NameValueCollection
$nv.Add("description", "Uses RsaCryptoServiceProvider to encrypt and decrypt")
$nv.Add("keyContainerName", "NetFrameworkConfigurationKey")
$nv.Add("cspProviderName", "")
$nv.Add("useMachineContainer", "true")
$nv.Add("useOAEP", "false")
$Prov.Initialize("RsaProtectedConfigurationProvider", $nv)
Now I'm getting a different error: "Bad data".
Update 2: tried siccing aspnet_regiis on that file, got the same "Bad data" error. But the site itself seems up and running and database aware. Maybe the connectionString section is damaged after all, and the site takes it elsewhere.
I"m not sure about doing it via Powershell but here's what I do manually via code-behind on a web page. There might be a clue in here. I can delete this answer if it doesn't help.
protected void btnEncryptConnStrings_Click(object sender, EventArgs e)
{
// Open web.config file as a configuration object to get information.
Configuration objConfigFile = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
// Work with the <connectionStrings> section.
ConfigurationSection connectionStrings = objConfigFile.GetSection("connectionStrings");
if(connectionStrings != null)
{
// Only encrypt the section if it is not already protected.
if(!connectionStrings.SectionInformation.IsProtected)
{
// Encrypt the <connectionStrings> section using the
// DataProtectionConfigurationProvider provider (see notes at top of file).
connectionStrings.SectionInformation.ProtectSection("RsaProtectedConfigurationProvider"); // alt: DataProtectionConfigurationProvider
objConfigFile.Save();
// other stuff.
}
}
}
I have to decode an XML encrypted document. The relevant part is:
<Master_key>
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" />
<KeyInfo>
<ds:KeyName>TK</ds:KeyName>
<ds:RetrievalMethod URI="#TK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey" />
</KeyInfo>
<CipherData>
<xenc:CipherValue>73CEFD0CE530C157C275152964EFBC322D26C2E356A3F3079E026FB2B6B562BD810043066300924078472229583118A8</xenc:CipherValue>
<xenc:FingerPrint>739E0E8490EACBCB2EA11D4A5DBEFBAE888B092E</xenc:FingerPrint>
</CipherData>
</Master_key>
The Master_Key is an encrypted element. aes256-cbc is used for encryption. The AES256 key is a session key and defined at the begin of the XML:
<Security>
<Transport_key Id="TK">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo>
<ds:RetrievalMethod URI="#PKC" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey" />
</KeyInfo>
<CipherData>
<xenc:CipherValue>968A0AFA54DAD4081FC264C90CD5F1341AD8274F130F5E9E8DC397B9FE3B7EC00FC72DD8C8A22B6E8A606B7693B80882777972D61316FD280A64D166DD0DA08748D285A2D4236DC92153C7A3ECF77580F380BE1A4E8B5E688BDB090A92B5C0CF3C1D90E00E73B4B50940195587DECB1ECF686B51C3C566D0BC36EA5EC0E87C32827EFFCDD3B5A91AF9AD0A0594527E43395CB6CC44653F60F9792505598709FE2C5F1BD21BAA8B6C9C02ADE354B7E8717BE999A11B6422F6C67B0D7A13C96051658C2B0315812DD772321E9820FEE73843C76869F65FE6327253A5BDD1255EF4DEA9B5A17DB54A5B7AEEA1DB4BEA018301E2CAB04B79A3EF81A419DB2B837404</xenc:CipherValue>
<xenc:FingerPrint>1F1862AFB4CC212C18439F12C1C3E6B615E70F65</xenc:FingerPrint>
</CipherData>
<CarriedKeyName>TK</CarriedKeyName>
</Transport_key>
</Security>
It is itself encrypted with rsa-1_5, based on a public key, for which the decrypter must have the private key.
I have to decrypt the content. Although I know the private key, I have no idea at the moment how to do that. In particular I'm wondering why the ciphered value
73CEFD0CE530C157C275152964EFBC322D26C2E356A3F3079E026FB2B6B562BD810043066300924078472229583118A8
is 48 Bytes long. Shouldn't it be a multiple of 32 Bytes, because AES256 uses a blocklength of 256bits=32bytes.
I would appreciate any help...
I am working on ADFS authentication using IDP page of ADFS.
I am able to redirect to IDP page successfully and also able to redirect back to my application successfully after getting authenticated.
Here I am getting below error message after returning back to my application:
No valid key mapping found for securityToken:
'System.IdentityModel.Tokens.X509SecurityToken' and issuer
I have added below code in web.config file to decrypt claims information.
<authority name="http://idp.neuronetics.com/adfs/services/trust">
<keys>
<add thumbprint="1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234"/>
</keys>`enter code here
<validIssuers>
<add name="http://adfsServiceDomain/adfs/services/trust" />
</validIssuers>
</authority>
I have reviewed many articles related to this. Most of the articles suggest to verify the thumbprint of token signing certificate of ADFS.
I have double checked and the thumbprint is perfect.
Anyone have any idea regarding this issue ?
Please advise.
Please let me know if you have any concern or query or if you need more information.
Since you are using WIF rather than OWIN, you can pretty much override the default issuer registry and provide your own one that gives you much more control over what issuers are accepted.
Overriding the issuer registry involves providing a class that inherits from the IssuerNameRegistry
public class CustomIssuerNameRegistry : IssuerNameRegistry
{
public override string GetIssuerName( SecurityToken securityToken )
{
X509SecurityToken x509Token = securityToken as X509SecurityToken;
if ( x509Token != null &&
x509Token.Certificate != null
)
{
// this is where you validate the certificate programatically
// for example, you can verify the thumbprint against
// a list of accepted thumprints
// return a string, the name of the issuer to indicate
// succesfull validation
return "issuer name";
}
throw new SecurityTokenException( "Untrusted issuer." );
}
and registering the issuer registry in the WIF pipeline in web.config
<system.identityModel>
<identityConfiguration>
<issuerNameRegistry type="Namespace.CustomIssuerNameRegistry, AssemblyName" />
</identityConfiguration>
</system.identityModel>
This approach lets you debug incoming token's certificate thoroughly.
This is the service callout policy:
<ServiceCallout name="GeoCodeClient">
<Request clearPayload="false" variable="GeocodingRequest" />
<Response>GeocodingResponse</Response>
<Timeout>30000</Timeout>
<HTTPTargetConnection>
<URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
</HTTPTargetConnection>
</ServiceCallout>
Let us say I have to access a resource that is username/password protected. How do I add that basic authorization to this policy to enable me to do that?
In our project a KeyValueMaps are used to store the basic auth info at org level. The authorisation information is retrieved using the KeyValueMap policy and added as the basic auth header to the request message.
See if this approach works for you.
To add Basic Authentication header for your service callout, you can use an 'AssignMessage' policy that sets the 'Authorization' header in the 'GeocodingRequest' as follows:
<AssignMessage enabled="true" continueOnError="true" async="false" name="AssignAuthorizationHeaderPolicy">
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
<AssignTo createNew="true" transport="http" type="request">GeocodingRequest</AssignTo>
<Add>
<Headers>
<Header name="Authorization">Basic YourAuthenticationHeader</Header>
</Headers>
</Add>
</AssignMessage>
Once you have created this policy, you will need to attach it in the request flow before the serviceCallout in the proxy.xml as flows:
<Step>
<FaultRules/>
<Name>AssignAuthorizationHeaderPolicy</Name>
</Step>
<Step>
<FaultRules/>
<Name>GeoCodeClient</Name>
</Step>
to add to what's already been said, if you need base64 encoding (and you probably will if you're using Basic Authorization), you'll need to do script callout. For instance, you can use the following Python:
import base64
if (client_secret is not None):
data = client_id + ":" + client_secret
header_value = base64.b64encode(data)
header_value = "Basic " + header_value
flow.setVariable("request.header.Authorization", header_value)
JS will be a little trickier since you need to include appropriate libraries, but I'm sure SO has plenty of more examples to follow for that.
Using Key Value Map to store sensitive data in a secure way
Step 1)Use below API to Create/Update the key Value maphttps://api.enterprise.apigee.com/v1/o/{orgname}/environments/{env}/keyvaluemaps Body:-{
"entry" : [ {
"name" : "basic_auth_system1",
"value" : "Basic XXXXXXXXXXX"
} ],
"name" : "system1_credentials"
}
Step 2) Policy used to lookup The key Value map
<KeyValueMapOperations enabled="true" continueOnError="false" async="false" name="keymap_get_credentials" mapIdentifier="system1_credentials">
<DisplayName>keymap_get_credentials</DisplayName>
<FaultRules/>
<Properties/>
<ExpiryTimeInSecs>-1</ExpiryTimeInSecs>
<Get assignTo="basic_auth_system1">
<Key>
<Parameter>basic_auth_system1</Parameter>
</Key>
</Get>
<Scope>environment</Scope>
</KeyValueMapOperations>