Loading…
Tilbage

Profilbillede

IDWS krypterede svar, kan ikke udpakkes.

Brian Jessen

Vi har problemer med at pakke krypterede svar ud i java.

Problemet opstår når CXF forsørger at pakke service svar ud. SOAP headeren Security/EncryptedKey/KeyInfo ser ud som nedenfor.

Det får CXF til at lede konvolutten igennem efter nøglen med ID: _1d272b95-f9d9-45f9-a6d2-00a73eb7ea81 den findes ikke.

 

<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">

    <o:SecurityTokenReference b:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"

        xmlns:b="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd">

        <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_1d272b95-f9d9-45f9-a6d2-00a73eb7ea81</o:KeyIdentifier>

    </o:SecurityTokenReference>

</KeyInfo>

 

Vi ved at svaret er krypteret med public delen af vores FOCES certifikat, så hvis vi indsætter en intercepter der udskifter KeyInfo med et andet KeyInfo element der i stedet indeholder vores X509IssuerName og X509SerialNumber, så kan CXF fint pakke svaret ud.

Dette ser vi egentligt som lidt af et hack! 

Fra service udbyderen har vi fået at vide at det er standard at IDWS librariet der virker på den måde, og at de ikke kan udskifte KeyInfo da dette kommer fra NemLogin.

Det kan godt være at det er hardcoded i .NET librariet at det er deres foces certifikat der skal bruges, men man kan vel næppe forvente andre kan pakke svaret ud når der er ugyldig KeyInfo?

Det er også service udbyderen, der har henvist os til dette forum for at få hjælp, så det håber vi, vi kan få?

Hvor meldes sådan en fejl ind? Og hvad er proceduren for at få den rettet?

Hvis det ikke er en fejl, hører vi meget gerne tips på hvad vi gør forkert.

 

Nedenfor er lige svaret i sin helhed:

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"

    xmlns:a="http://www.w3.org/2005/08/addressing"

    xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

    <s:Header>

        <a:Action s:mustUnderstand="1" u:Id="_3">http://smdb.dst.dk/api/external/v1/ISecureTokenTest/WhoAmIResponse</a:Action>

        <a:RelatesTo u:Id="_4">urn:uuid:00128ee7-18a6-45b6-b82d-7ddd7576e75b</a:RelatesTo>

        <a:MessageID u:Id="_5">urn:uuid:8854b839-c099-4197-968d-9884524b9834</a:MessageID>

        <o:Security s:mustUnderstand="1"

            xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

            <u:Timestamp u:Id="uuid-a5d5d8f2-c421-4df7-b817-f7aeb972ee8d-2">

                <u:Created>2019-06-25T13:04:41.166Z</u:Created>

                <u:Expires>2019-06-25T13:09:41.166Z</u:Expires>

            </u:Timestamp>

            <o:BinarySecurityToken u:Id="uuid-c733ce82-b330-4702-9f3b-ff208b1ba4d4-26" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">                <!-- removed -->

            </o:BinarySecurityToken>

            <e:EncryptedKey Id="_0"

                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"

                        xmlns="http://www.w3.org/2000/09/xmldsig#"/>

                </e:EncryptionMethod>

                <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">

                    <o:SecurityTokenReference b:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"

                        xmlns:b="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd">

                        <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_1d272b95-f9d9-45f9-a6d2-00a73eb7ea81</o:KeyIdentifier>

                    </o:SecurityTokenReference>

                </KeyInfo>

                <e:CipherData>

                    <e:CipherValue>                        <!-- removed --></e:CipherValue>

                </e:CipherData>

                <e:ReferenceList>

                    <e:DataReference URI="#_2"/>

                    <e:DataReference URI="#_6"/>

                </e:ReferenceList>

            </e:EncryptedKey>

            <e:EncryptedData Id="_6" Type="http://www.w3.org/2001/04/xmlenc#Element"

                xmlns:e="http://www.w3.org/2001/04/xmlenc#">

                <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>

                <e:CipherData>

                    <e:CipherValue>                        <!-- removed --></e:CipherValue>

                </e:CipherData>

            </e:EncryptedData>

        </o:Security>

    </s:Header>

    <s:Body u:Id="_1">

        <e:EncryptedData Id="_2" Type="http://www.w3.org/2001/04/xmlenc#Content"

            xmlns:e="http://www.w3.org/2001/04/xmlenc#">

            <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>

            <e:CipherData>

                <e:CipherValue>                    <!-- removed --></e:CipherValue>

            </e:CipherData>

        </e:EncryptedData>

    </s:Body>

</s:Envelope>

 

Tak for hjælpen

Brian

Vi oplever præcis den samme udfording i forb. med en dst integration. Det er naturligvis ikke så mærkeligt eftersom vi nok har taget udgangspunkt i det samme java cxf eksempelkode, hentet fra digitaliser.dk.
Vores erfaring med cxf fra andre integrationer er, at det er et ret tolerent / lenient framework, men der mangler jo simpelthen oplysninger i responset om hvordan det skal dekrypteres. Jeg bliver lidt bekymret over den stilhed der er herinde - har du fået svar andetsteds eller er supporten gået tidligt på sommerferie? Hvis der er nogen der læser de her beskeder, så ville det være rigtig godt med et svar inden vi er tilbage fra sommerferie til August - vi kan ikke blive ved med at udskyde den integration.

Vi har forsøgt os med et andet hack (en interceptor der manuelt dekrypterer med javax.crypto), det er ærlig talt et værre hack end jeres Brian, eftersom cxf jo så stadig forsøger at parse responset og smider en exception.

Brian, hvis du ser denne besked, har du mulighed for at dele dit lidt bedre hack herinde? Bare en code snippet af din interceptor. Hvis du har hørt noget fra digitaliser.dk eller nets kunne du måske også lige paste det herind - vi er nok ikke de eneste der har udfordringen. 

tak for hjælpen og venlig hilsen

Jacob

Hej Jacob,

Tak for dit indlæg og din opbakning. Det er den eneste feedback jeg har fået, så vi er ikke nået længere. Hvis du har bud på andre steder jeg kan henvende mig, så sig til, så forsøger jeg. DST henviste os hertil, men her virker lidt øde.

Jeg har vedlagt den centrale del af vores interceptor hack

 

public void handleMessage(SoapMessage message) throws Fault {
try {
/**
* The KeyInfo returned from the service refers to a key sent in the request, this is not legal.
* As a temp. workaround replace the keyInfo with info to our certificate.
*/
InputStream is = message.getContent(InputStream.class);
Document doc = builder.parse(is);
xpath.setNamespaceContext(contextMap);
// Find current KeyInfo in the document, so we can replace it with our own KeyInfo.
Node keyInfoNode = (Node) xpath.evaluate("/Envelope/Header/Security/EncryptedKey/KeyInfo", doc.getDocumentElement(), XPathConstants.NODE);
Node parent = keyInfoNode.getParentNode();
Element newKeyInfoNode = createWorkingKeyInfo(doc);
parent.insertBefore(newKeyInfoNode, keyInfoNode);
keyInfoNode.getParentNode().removeChild(keyInfoNode);
Transformer transformer = TransformerFactory.newInstance().newTransformer();
StreamResult result = new StreamResult(new StringWriter());
DOMSource source = new DOMSource(doc);
transformer.transform(source, result);
InputStream modifiedInputStream = IOUtils.toInputStream(result.getWriter().toString());
message.setContent(InputStream.class, modifiedInputStream);
} catch (Exception e) {
e.printStackTrace();
}
}

/**
* Builds a keyinfo that refers to our foces certificates.
*/
private Element createWorkingKeyInfo(Document doc) {
Element newKeyInfo = doc.createElementNS("http://www.w3.org/2000/09/xmldsig#", "KeyInfo");
Element newTokenRef = doc.createElementNS("http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd", "SecurityTokenReference");
newKeyInfo.appendChild(newTokenRef);
Element x509Data = doc.createElementNS("http://www.w3.org/2000/09/xmldsig#", "X509Data");
newTokenRef.appendChild(x509Data);
Element x509IssuerSerial = doc.createElementNS("http://www.w3.org/2000/09/xmldsig#", "X509IssuerSerial");
// Foces certicates issuer
Element x509Issuer = doc.createElementNS("http://www.w3.org/2000/09/xmldsig#", "X509IssuerName");
x509Issuer.setTextContent("CN=AAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
// Foces certicates serial number
Element x509SerialNumber = doc.createElementNS("http://www.w3.org/2000/09/xmldsig#", "X509SerialNumber");
x509SerialNumber.setTextContent("" + 0xBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB);
x509IssuerSerial.appendChild(x509Issuer);
x509IssuerSerial.appendChild(x509SerialNumber);
x509Data.appendChild(x509IssuerSerial);
return newKeyInfo;
}

Erstat A'er og B'er med info fra det certificat I benytter.

Det er ikke den kode vi er mest stolte af. Det er et hack.

Jeg havde virkeligt håbet at dette forum kunne hjælpe os ud af dette hack

mvh

Brian 

Hej Brian

Tak for dit svar og dit fine hack, jeg skylder vist en fadøl. Jeg når ikke at se på det før til august, men jeg skal nok huske at opdatere herinde hvis jeg render ind i en bedre løsning. 

v.h. Jacob

Edit: Vi er netop rendt ind i endnu en komplikation i forbindelse med dette problem: I vores integration til danmarks statistiks stofmisbrugsdatabase (SMDB) er vi blevet bedt om at anvende et separat certifikat pr. kommune der indberetter. Det kan vi ikke implementere på en forsvarlig måde når responset er krypteret uden gyldig angivelse af hvilket certifikat der anvendes. Vi har en del kunder i systemet og de har så hver deres FOCES certifikat.
Det er muligt at vi kan identificere hvilket af de 50 kundecertifikater der skal anvendes udfra den eksisterende keyInfo? Måske er det et thumbprint af en art? Det lader til at være standard i windows verdenen at slå certifikater op på OS niveau vha. thumbprint.

Er det muligt at få et bud fra digitaliserings-styrelsen om hvordan vi forventes at identificere det korrekte certifikat?

ændret af Jacob Carstens (06.11.2019)