Digitaliseringsstyrelsen

Transkript

1 NemLog-in INTERNAL USE

2 Indholdsfortegnelse 1 NEMLOG-IN-LØSNINGER GØRES SIKRERE TJENESTEUDBYDERE SKAL FORBEREDE DERES LØSNINGER HVIS LØSNINGEN IKKE FORBEREDES VEJLEDNING VEDR. SECURITY TOKEN SERVICE ÆNDRINGER FOR WSP OG WSC REQUEST RESPONSE Page 2 of 7

3 1 NemLog-in-løsninger gøres sikrere NemLog-in og alle tilknyttede komponenter kommer fremover til at benytte en ny og mere sikker krypteringsalgoritme end den hidtil anvendte. I juni 2018 overgår NemLog-in til udelukkende at benytte signering vha. SHA-256-kryptering, og dermed udfases brugen af SHA-1. Den nye kryptering er væsentligt sværere at bryde og dermed sikrere at benytte. 1.1 Tjenesteudbydere skal forberede deres løsninger I forbindelse med overgangen fra SHA-1 til SHA-256, skal integrationer mellem NemLog-in og de tilknyttede systemer opgraderes, og det nye setup skal testes. Skiftet kræver handling fra alle tjenesteudbydere, alt efter hvilke komponenter, der benyttes. Der findes en vejledning for hver af de fire komponenter; WebSSO (login) Signeringstjenesten AttributeQuery Security Token Service. Vejledningerne kan findes her Nærværende dokument drejer sig udelukkende om Security Token Service. 1.2 Hvis løsningen ikke forberedes Efter produktionsdatoen vil NemLog-in afvise at tage imod kald, der ikke er signeret med SHA-256. Såfremt en specifik løsning ikke skiftes til SHA-256-opsætning, vil det betyde at løsningen vil være utilgængelig. Der vil ikke være nogen mulighed for at få det til at virke med SHA-1. Det er derfor vigtigt at alle løsninger klargøres til SHA-256-overgangen Page 3 of 7

4 2 Vejledning vedr. Security Token Service I SecurityToken servicen kan man i dag ligesom i NemLog-in signere med SHA-1 og SHA-256. Der vil fremadrettet kun være mulighed for at benytte sig af SHA-256. Når der sendes et request mod SecurityToken servicen defineres en parameter SignatureMethod og Digest Algorithm, som kan være henholdsvis: - SHA-1: (udfases) - SHA-256: (understøttes) Bemærk: SHA-256 kan ikke testes i produktion før idriftsættelse af ny løsning i juni. Security Token servicen har tre forskellige flows Bootstrap token case, Local Token Case og Signature Token Case uanset hvilket scenarie, skal det være for SignatureMethod og Digest Algorithm opdateres på både request og assertion. Se eventuelt afsnit om XML struktur for signatur på hhv response og assertion. 2.1 Ændringer for WSP og WSC SecurityToken servicen har tre forskellige scenarier som i forbindelse med SHA-1 udfasningen skal håndteres ens, så hvad end der er tale om LocalToken, SignatureToken eller BoostrapToken servicen er følgende handlinger påkræver for hhv WebServiceConsumeren (WSC) og WebServiceProvideren (WSP) WSC Page 4 of 7

5 1. Når der sendes et request mod NemLog-ins Security Token Service kræver det for WSC'en at requested er signeret med SHA I responsen fra STS servicen bliver signeringen ligeledes foretaget med SHA-256 fra STS'en fra tidligere SHA-1 WSP 1. Når WSP'en modtager et token fra WSC'en som er et videresendt token fra STS'en skal WSP'en ligeledes validere signeringen med SHA Request I requested mod SecurityToken Servicen, vil der ligeledes være behov for at opgradere SignatureMethod og DigestMethod Algorithm fra SHA-1 til SHA-256. Eksempel på request: <S11:Envelope xmlns:s11=" xmlns:xs=" xmlns=" xmlns:wsa=" xmlns:xsi=" xmlns:wsse=" xmlns:wsu=" 1.0.xsd" xmlns:ds=" xmlns:wst=" xmlns:wst14=" xmlns:saml2="urn:oasis:names:tc:saml:2.0:assertion" xmlns:wsp=" <S11:Header> <wsa:action wsu:id="action"> <wsa:messageid wsu:id="msgid">uuid:a7f6356c ea f34dad76c79e</wsa:messageid> <wsa:to wsu:id="to"> <wsse:security S11:mustUnderstand="1"> <wsu:timestamp wsu:id="sec-ts"> <wsu:created> t11:20:40z</wsu:created> <wsu:expires> t11:20:40z</wsu:expires> </wsu:timestamp> <wsse:binarysecuritytoken wsu:id="sec-binsectoken" ValueType=" EncodingType=" security- 1.0#Base64Binary">MIIGGTCCBQGgTVDI0MDggU3lzdGVtdGVzdCBYSVggQ0EwHhcNMTUwMTIzMTYxNjU0WhcNM TgwMTIzMTYxNjIwWjCBhzELMAkGA1UEBhMCREsxITAfBgNVBAoMGE5OSVQgQS9TIC8vIENWUjoyMTA5MzEwNjFVM CAGA1UEBRMZQ1ZSOjIxMDkzMTA2LUZJRDoyNzIzMTE4NDAxBgNVBAMMKktGT0JTLVRFU1QtRk9DRVMtMTEzIChmd W5rdGlvbnNjZXJ0aWZpa2F0KTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJarAe5ElKRRs0iGnwd7L JO8yJmnnPDH+taZMfaHPh6hQNr5hazR/oqOaGqsCWl1e8kutr9iM54TVpmWjI2c7shlLX12LOxstArg69TR121hm etxofrrrahjmjumoohq8ozv9zu/teh/slbjlcuxracxpgeppg6cmtryxsinenyekvuujj/uswascw7kdcqeix6nw XWTU6rGIOnDA+o+/hIY/sDigHEhRY0UUVM3uGzosZblKoQxI9SQYosOgnOJ9L0WWaZUhz80xg7iL+ca4MZrozfIa Page 5 of 7

6 rvz/nsuuuyairjwzhb4coljjqm9z1ant/banekzil4q7sjjdmwasbhxw6ccaweaaaocasowgglgma4ga1uddweb/ wqeawidudcblwyikwybbquhaqeegyowgycwpayikwybbquhmaggmgh0dha6ly9vy3nwlnn5c3rlbxrlc3qxos50c nvzddi0mdguy29tl3jlc3bvbmrlcjbhbggrbgefbqcwaoy7ahr0cdovl2yuywlhlnn5c3rlbxrlc3qxos50cnvzd DI0MDguY29tL3N5c3RlbXRlc3QxOS1jYS5jZXIwggEgBgNVHSAEggEXMIIBEzCCAQ8GDSsGAQQBgfRRAgQGBAIwg f0wlwyikwybbquhagewi2h0dha6ly93d3cudhj1c3qynda4lmnvbs9yzxbvc2l0b3j5mihjbggrbgefbqccajcbv DAMFgVEYW5JRDADAgEBGoGrRGFuSUQgdGVzdCBjZXJ0aWZpa2F0ZXIgZnJhIGRlbm5lIENBIHVkc3RlZGVzIHVuZ GVyIE9JRCAxLjMuNi4xLjQuMS4zMTMxMy4yLjQuNi40LjIuIERhbklEIHRlc3QgY2VydGlmaWNhdGVzIGZyb20gd GhpcyBDQSBhcmUgaXNzdWVkIHVuZGVyIE9JRCAxLjMuNi4xLjQuMS4zMTMxMy4yLjQuNi40LjIuMIGqBgNVHR8Eg aiwgz8wpka6odignmh0dha6ly9jcmwuc3lzdgvtdgvzdde5lnrydxn0mjqwoc5jb20vc3lzdgvtdgvzdde5lmnyb DBfoF2gW6RZMFcxCzAJBgNVBAYTAkRLMRIwEAYDVQQKDAlUUlVTVDI0MDgxJDAiBgNVBAMMG1RSVVNUMjQwOCBTe XN0ZW10ZXN0IFhJWCBDQTEOMAwGA1UEAwwFQ1JMMjMwHwYDVR0jBBgwFoAUzAJVDOSBdK8gVNURFFeckVI4f6AwH QYDVR0OBBYEFDe5B+3zZskjDTpTwXgN77oScjF8MAkGA1UdEwQCMAAwDQYJKoZIhvcNAQELBQADggEBAADI9LYGb WQazb9oEN/aY3xq4Zfa9GyP8GBl5UhjFjU9G0tI6/Cu43japIQXkKHzMibi8raXNZRJGGWX3qUvXQA3IwZl4Eayy M+k4SKw/8crDXvf5Sk1/XEFr3WeD4otxks/pOns1SmQIxfRtso4dHMmI4D7pXFqJTTML2Be/bT6zTU8XNE8V6MpY eqrdyr4u95hb/mm0/gmz3vojarqdx7o9wsn597wnwz9cvqbee7ewyezyvfenkckr1w4piyj0y5li2bxunw9cj5dm WPhO75dccGFh4/5Mfjfc0d14rq1icJHKgAnsZPA82MPsYApcqeTQdDx5OtD2LUD1FbA4xs=</wsse:BinarySecu ritytoken> <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" /> <SignatureMethod Algorithm=" /> <Reference URI="#action"> <DigestValue>NrdtWxaigbkMffHPgKCAMndq0hRMvsKQSkNelmS5cAE=</DigestValue> <Reference URI="#msgid"> <DigestMethod Algorithm=" /> <DigestValue>vq2eSo4J3NfMLOBaVkeMrnKXy4prgEmdFzW3C0g2Nc8=</DigestValue> <Reference URI="#to"> <DigestValue>VRjscE+sMXYwGdFXLwczBVCnXdPBwx7vm800+bGCrQw=</DigestValue> <Reference URI="#sec-ts"> <DigestMethod Algorithm=" /> <DigestValue>PEwlGc6wEjc916mWb2SAtOBXDOFrHc+bQ5U7CXwFiOg=</DigestValue> <Reference URI="#sec-binsectoken"> <DigestValue>9NL4QNnzLoV0/GS3x1UXiHAy9VBPrPMfjy427V7q9Mw=</DigestValue> <Reference URI="#body"> Page 6 of 7

7 <DigestValue>O62w4zPn/JGiVVGie1CTviWOs7ibQ6U2scjRuJUT2RU=</DigestValue> </SignedInfo> <SignatureValue>HCryZP5aQKL9/yzmJ/sZ2lhjJUxhuTURxogb7lMJL3X6ZWgIC6LUX/Ia+++6BM+Qam2Xhn8A 8mYWopm9WMwNbRkjMpwFx6Tg3SpSI7neVFCX+keEYHq2e3iBqlKmdr6YSI2Y2J+htGZoWWk7z6+9TQszjT+8GSvl 9Bfyw8nmO2Nip1yyHT3choSlVk67UybQ1iJCxJUwNxFBLiyRFgr38spp34hT2McdQq7ZTzrv8kfYi6YUFxD2u/i/ hce105v2+c5g59wjvp7p6v2rr+eagomu6+e4l0s+kwhlwinkukmcl+t9odzmakga7egr0njh+hfp+0upbihhb6pb x00ugq==</signaturevalue> <KeyInfo> <o:securitytokenreference xmlns:o=" <o:reference URI="#sec-binsectoken" /> </o:securitytokenreference> </KeyInfo> </Signature> </wsse:security> </S11:Header> <S11:Body wsu:id="body"> <wst:requestsecuritytoken Context="urn:uuid:1f6b54b8-88f a87-b5bb00a78b4f"> <wst:requesttype> <wsp:appliesto> <wsa:endpointreference> <wsa:address> </wsa:endpointreference> </wsp:appliesto> </wst:requestsecuritytoken> </S11:Body> </S11:Envelope> 2.3 Response For responses vil den response og assertion for alle tre scenarier fremadrettet ligeledes være signeret med SHA Page 7 of 7