NemLogin STS snitflade-beskrivelse

27-03-2015 14:12:38

The purpose of this document is to describe how service providers and web service consumers can test the integration to the Security Token Service from here on named STS in the Nemlog-in integration test environment.

The audience is it-technicians who is going to perform the technical integration and testing and it is assumed that the reader already have knowledge about OIO Identity-based Web Services.

Filer og referencer

Titel	Type
NemLog-in2 - STS.doc	doc

Læsevejledning til snitfladebeskrivelsen

Thomas Gundel

08. april 2015, 9:09

Bemærk at snitfladebeskrivelsen dækker hele NemLog-in STS, hvor systemer i grunddataprogrammet kun skal anvende en mindre delmængde.

Det drejer sig specifikt om afsnit 4.5.3 og 4.5.4, som viser et eksempel på, hvordan en systembruger kan requeste et token hos NemLog-in ved brug af WS-Trust protokollen og få et svar retur indeholdende et SAML token.

De vigtigste ting at være opmærksom på i integrationen med NemLog-in systembruger STS er flg.:

SOAP kaldet skal signeres med klientens FOCES/VOCES certifikat, der på forhånd er registreret i NemLog-in. Signaturen skal dække både headere og body.
Klienten kan kun få udstedt et token, hvis serviceudbyderen på forhånd har tildelt klienten adgang i NemLog-in (med mindre udbyderen har sat servicen op til fri adgang).
Klientens certifikat skal indlejres som et <BinarySecurityToken> i SOAP headeren.
Der skal medsendes korrekte SOAP headere i requestet dvs.:

<wsa:Action wsu:Id="action">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</wsa:Action>
<wsa:MessageID wsu:Id="msgid">uuid:1234...</wsa:MessageID>
<wsa:To wsu:Id="to">https://signature.sts.nemlog-in.dk/</wsa:To>

Body skal indeholde et WS-Trust RequestSecurityToken element, hvor:

Request type er sat til "Issue" dvs. <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
AppliesTo indeholde EntityID på den web service, som der ønskes udstedt et security token til.

Det modtagne SAML token fra NemLog-in vil være Audience restricted til den specifikke web service, der blev angivet i requestet, og kan kun bruges mod denne.
Det modtagne SAML token vil være et holder-of-key token, som refererer til klientens certifikat. Klienten kan derfor kun anvende tokenet mod en web service ved samtidig at bevise kendskab til sin private nøgle - i praksis ved at signere web service kaldet eller benytte nøglen til klientautentificeret TLS.

Bemærk at snitfladebeskrivelsen dækker hele NemLog-in STS, hvor
 systemer i grunddataprogrammet kun skal anvende en mindre delmængde.
Det drejer sig specifikt om afsnit 4.5.3 og 4.5.4, som viser et
 eksempel på, hvordan en systembruger kan requeste et token hos
 NemLog-in ved brug af WS-Trust protokollen og få et svar retur
 indeholdende et SAML token.
De vigtigste ting at være opmærksom på i integrationen med NemLog-in
 systembruger STS er flg.:
<ul>
 <li>SOAP kaldet skal signeres med klientens FOCES/VOCES certifikat,
 der på forhånd er registreret i NemLog-in. Signaturen skal dække
 både headere og body.</li>
 <li>Klienten kan kun få udstedt et token, hvis serviceudbyderen på
 forhånd har tildelt klienten adgang i NemLog-in (med mindre
 udbyderen har sat servicen op til fri adgang).</li>
 <li>Klientens certifikat skal indlejres som et
 <BinarySecurityToken> i SOAP headeren.</li>
 <li>Der skal medsendes korrekte SOAP headere i requestet dvs.:</li>
 <ul>
 <li><wsa:Action wsu:Id="action">http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</wsa:Action></li>
 <li><wsa:MessageID wsu:Id="msgid">uuid:1234...</wsa:MessageID></li>
 <li><wsa:To wsu:Id="to">https://signature.sts.nemlog-in.dk/</wsa:To></li></ul>
 <li>Body skal indeholde et WS-Trust RequestSecurityToken element, hvor:</li>
 <ul>
 <li>Request type er sat til "Issue" dvs. <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType></li>
 <li>AppliesTo indeholde EntityID på den web service, som der ønskes
 udstedt et security token til.</li></ul>
 <li>Det modtagne SAML token fra NemLog-in vil være Audience restricted
 til den specifikke web service, der blev angivet i requestet, og kan
 kun bruges mod denne.</li>
 <li>Det modtagne SAML token vil være et holder-of-key token, som
 refererer til klientens certifikat. Klienten kan derfor kun anvende
 tokenet mod en web service ved samtidig at bevise kendskab til sin
 private nøgle - i praksis ved at signere web service kaldet eller
 benytte nøglen til klientautentificeret TLS.</li></ul>

Log ind for at besvare