Page History

...

Seal.NET indeholder nogle IEndPointBehavior-klasser som kan benyttes af WCF service referencesservices genereret ud fra WSDL. Disse er beskrevet længere nede under afsnittet EndpointBehaviors.

Klienter

Saml2SosiStsClient

...

Disse MessageHeaders bruges til at indsætte relevant data i headeren for på et request, som er lavet med en klient genereret ud fra en WCF service reference.

...

Klienteksempler

En klient til en WebService af typen Den Gode Webservice benyttes som enhver anden webservice.
I Visual Studio tilføjes en Service-Reference til den pågældende WSDL. Herefter genereres en proxy indeholdende alle datatyper for webservicen.
Det er også muligt at benytte WCF svcutil tool hvis Visual Studio ikke er tilstrækkelig.
Herefter kan der WebService af typen Den Gode Webservice benyttes som enhver anden webservice.
I Visual Studio tilføjes en Service-Reference til den pågældende WSDL. Herefter genereres en proxy indeholdende alle datatyper for webservicen.
Det er også muligt at benytte WCF svcutil tool hvis Visual Studio ikke er tilstrækkelig.

Opstarts-eksempel med kald til NTS

Når man har generet sin klient ud fra den WSDL som tilhører den service man gerne vil snakke med (i dette tilfælde NTS), så er man klar til at begynde at bruge Seal.Net til at lave et kald til servicen.

Først et "bare-bones" eksempel på et kald til NTS:

private static Task<invokeResponse> CallNts(IdCard idc) // invokeResponse-typen kommer fra klienten der er genereret ud fra WSDL
{
	// NtsWSProviderClient er klienten generet ud fra WSDL
    var client = new NtsWSProviderClient(new BasicHttpBinding(), new EndpointAddress("http://test1.ekstern-test.nspop.dk:8080/nts/service"));
    client.Endpoint.EndpointBehaviors.Add(new SealEndpointBehavior()); // SealEndpointBehavior er beskrevet under afsnittet 'EndpointsBehaviors'

    var dgwsHeader = new Header // Header-type som er generet ud fra NTS WSDL. Gennem denne sættes DGWS-specifikke detaljer.
    {
        SecurityLevel = 4,
        SecurityLevelSpecified = true,
        Linking = new Linking { MessageID = Guid.NewGuid().ToString("D") }
    };

    using (new OperationContextScope(client.InnerChannel))
    {
        // Tilføjer security og DGWS header til request
        OperationContext.Current.OutgoingMessageHeaders.Add(IdCardHeader(idc));
        OperationContext.Current.OutgoingMessageHeaders.Add(XmlHeader(dgwsHeader));
        return client.invokeAsync("test");
    }
}

Header typen findes også i Seal.NET som en selvstændig type. Det er den samme type som bliver genereret ud fra service WSDL, da alle WSDL bruger den samme header, da den er specificieret af DGWS standarden. Så om man bruger Header fra Seal.NET, eller Header fra den kode der er generet ud fra WSDL, giver det samme i det request der sendes afsted.

Her skal man være opmærksom på at den WSDL man genererer sin WSDL ud fra, måske indeholder Header og Security (der findes WSDL'er med sikkerhed som vil have disse headers, og tilsvarende WSDL'er uden sikkerhed, hvor disse headers ikke vil være tilstede. Den samme service kan uden problemer have begge udgaver). Hvis den gør det, så vil det sidste kald "client.invokeAsync" ikke blot kræve body af SOAP-beskeden (rettere sagt, den værdi man ønsker at sende - her "test"), men også Security og Header typen. Hvis dette er tilfældet, bør man omskrive sin kode til ovenstående. Hvorfor og hvordan, er beskrevet i afsnittet 'Fejlfinding' under 'Invalid ID-kort ved kald til service'.

Afhængig af hvilken service man gerne vil sende requests til, kan der være brug for mere konfiguration af sin klient, som kan gøres vha. CustomBinding og EndpointsBehaviors:

private static Task<invokeResponse> CallNts(IdCard idCard)
{
    var binding = new CustomBinding(); // Med en CustomBinding kan der styres flere ting, f.eks. hvilken udgave af SOAP man ønsker at bruge
    binding.Elements.Add(new TextMessageEncodingBindingElement(MessageVersion.Soap11WSAddressingAugust2004, Encoding.UTF8));
    binding.Elements.Add(new HttpTransportBindingElement())

    var client = new NSTWsProvider.NtsWSProviderClient(binding, new EndpointAddress("https://test1-cnsp.ekstern-test.nspop.dk:8443/nts/service"))
    client.Endpoint.EndpointBehaviors.Add(new SealEndpointBehavior());
    client.Endpoint.EndpointBehaviors.Add(new ViaBehavior(new Uri("http://test1.ekstern-test.nspop.dk:8080/sosigw/proxy/soap-request"))) // Kald via SOSI-GW

    var dgwsHeader = new Header
    {
        SecurityLevel = 4,
        SecurityLevelSpecified = true,
        Linking = new Linking { MessageID = Guid.NewGuid().ToString("D") }
    }
    
    using (new OperationContextScope(client.InnerChannel))
    {
        // Adding seal-security and dgws-header soap header
        OperationContext.Current.OutgoingMessageHeaders.Add(IdCardHeader(idCard));
        OperationContext.Current.OutgoingMessageHeaders.Add(XmlHeader(dgwsHeader))
        return client.invokeAsync("test");
    }
}

Begge kodeeksempler indgår i tests i Seal.NET kodebasen i (bl.a.) klasserne 'SosiGWTest' og 'NemIdAssertionTest'.

Specificikke eksempler for forskellige scenarier

Der kan være flere klient-scenarier:

1. Føderalt: Et ID-kort der oprettes lokalt valideres via et kald til en STS, som returnerer et kort der er digitalt underskrevet. Dette kort benyttes til fremtidige kald af webservices. Service Udbyderen skal nu kun autentificere STS'en.
2. NemId:Hvis en bruger allerede er logget på et system via NemLogin, kan dette login benyttes til at kalde en webservice. Til NemLogin er associeret en SAML token. Denne token skal veksles til et DGWS ID kort. Når ID kortet er modtaget, benyttes det til fremtidige kald.
3. SOSI Gateway: Benyttes bl.a. til at cache ID kort, så en session kan håndteres af SOSI Gateway.
4. MitID: MitID omvekslinger.
5. OIOSAML: Kald til STS for at få tokens til eksterne systemer, f.eks. til Sikker Browser Opstart (SBO).

...

Denne fejl ses hvis man anvender en klient der er genereret ud fra WSDL som specificerer security og Security (som indeholder det signerede ID-kort). Problemet opstår fordi klienten laver om på namespaces i assertion i ID-kortet, som gør signaturen invalid.

...

Hvis der findes en udgave af WSDL som ikke specificerer security Security og ID-kortHeader, kan man undgå null. Alternativt kan man selv lave et overload der ikke tager argumenterne, og selv sætter null i metoden.

...