ClickOnce-toepassingen maken die door anderen kunnen worden geïmplementeerd

Niet alle ontwikkelaars die ClickOnce-implementaties maken, zijn van plan om de toepassingen zelf te implementeren. Veel van hen verpakken hun toepassing door ClickOnce te gebruiken en vervolgens de bestanden aan een klant te geven, zoals een grote onderneming. De klant wordt degene die verantwoordelijk is voor het hosten van de toepassing op het netwerk. In dit onderwerp worden enkele van de problemen besproken die inherent zijn aan dergelijke implementaties in versies van .NET Framework vóór versie 3.5. Vervolgens wordt een nieuwe oplossing beschreven die wordt geleverd met behulp van de nieuwe functie 'use manifest for trust' in .NET Framework 3.5. Ten slotte eindigt het met aanbevolen strategieën voor het maken van ClickOnce-implementaties voor klanten die nog steeds oudere versies van .NET Framework gebruiken.

Problemen met het maken van implementaties voor klanten

Er treden verschillende problemen op wanneer u van plan bent een implementatie aan een klant te leveren. Het eerste probleem betreft ondertekening van code. Om een ClickOnce-implementatie over een netwerk te implementeren, moeten zowel het distributiemanifest als het toepassingsmanifest zijn ondertekend met een digitaal certificaat. Hiermee wordt de vraag gesteld of het certificaat van de ontwikkelaar of het certificaat van de klant moet worden gebruikt bij het ondertekenen van de manifesten.

De vraag welk certificaat moet worden gebruikt, is essentieel, omdat de identiteit van een ClickOnce-toepassing is gebaseerd op de digitale handtekening van het implementatiemanifest. Als de ontwikkelaar het implementatiemanifest ondertekent, kan dit leiden tot conflicten als de klant een groot bedrijf is en meerdere afdelingen van het bedrijf een aangepaste versie van de toepassing implementeert.

Stel dat Adventure Works een financiële afdeling en een personeelsafdeling heeft. Beide afdelingen geven een licentie voor een ClickOnce-toepassing van Microsoft Corporation die rapporten genereert van gegevens die zijn opgeslagen in een SQL-database. Microsoft levert elke afdeling een versie van de toepassing die is aangepast voor hun gegevens. Als de toepassingen zijn ondertekend met hetzelfde Authenticode-certificaat, treedt er een fout op bij een gebruiker die beide toepassingen probeert te gebruiken, omdat ClickOnce de tweede toepassing zou beschouwen als identiek aan de eerste. In dit geval kan de klant onvoorspelbare en ongewenste bijwerkingen ondervinden, waaronder het verlies van gegevens die lokaal door de toepassing zijn opgeslagen.

Een extra probleem met betrekking tot ondertekening van programmacode is het deploymentProvider element in het implementatiemanifest, waarmee ClickOnce wordt aangegeven waar naar toepassingsupdates moet worden gezocht. Dit element moet worden toegevoegd aan het implementatiemanifest voordat u dit ondertekent. Als dit element later wordt toegevoegd, moet het implementatiemanifest opnieuw worden ondertekend.

Vereisen dat de klant het implementatiemanifest ondertekent

Eén oplossing voor dit probleem van niet-unieke implementaties is door de ontwikkelaar het toepassingsmanifest te laten ondertekenen en de klant het implementatiemanifest te ondertekenen. Hoewel deze aanpak werkt, worden er andere problemen geïntroduceerd. Omdat een Authenticode-certificaat een beveiligde asset moet blijven, kan de klant het certificaat niet alleen aan de ontwikkelaar geven om de implementatie te ondertekenen. Hoewel de klant het implementatiemanifest zelf kan ondertekenen met behulp van hulpprogramma's die vrij beschikbaar zijn met de .NET Framework SDK, is hiervoor mogelijk meer technische kennis vereist dan de klant wil of kan bieden. In dergelijke gevallen maakt de ontwikkelaar meestal een toepassing, website of ander mechanisme waarmee de klant zijn versie van de toepassing kan indienen voor ondertekening.

De impact van het aanmelden van klanten op ClickOnce-toepassingsbeveiliging

Zelfs als de ontwikkelaar en de klant ermee akkoord gaan dat de klant het toepassingsmanifest moet ondertekenen, veroorzaakt dit andere problemen die de identiteit van de toepassing omsluiten, met name omdat deze van toepassing is op de implementatie van vertrouwde toepassingen. (Zie het overzicht van de implementatie van vertrouwde toepassingen voor meer informatie over deze functie.) Stel dat Adventure Works de clientcomputers wil configureren, zodat elke toepassing die door Microsoft Corporation wordt geleverd met volledige vertrouwensrelatie wordt uitgevoerd. Als Adventure Works het implementatiemanifest ondertekent, gebruikt ClickOnce de beveiligingshandtekening van Adventure Work om het vertrouwensniveau van de toepassing te bepalen.

Klantimplementaties maken met behulp van toepassingsmanifest voor vertrouwen

ClickOnce in .NET Framework 3.5 bevat een nieuwe functie waarmee ontwikkelaars en klanten een nieuwe oplossing krijgen voor het scenario waarin de manifesten moeten worden ondertekend. Het ClickOnce-toepassingsmanifest ondersteunt een nieuw element met de naam <useManifestForTrust> waarmee een ontwikkelaar kan ondertekenen dat de digitale handtekening van het toepassingsmanifest moet worden gebruikt voor het nemen van beslissingen over vertrouwen. De ontwikkelaar maakt gebruik van ClickOnce-verpakkingshulpprogramma's, zoals Mage.exe, MageUI.exeen Visual Studio, om dit element op te nemen in het toepassingsmanifest en om zowel de naam van de uitgever als de naam van de toepassing in het manifest in te sluiten.

Bij gebruik <useManifestForTrust>hoeft het implementatiemanifest niet te worden ondertekend met een Authenticode-certificaat dat is uitgegeven door een certificeringsinstantie. In plaats daarvan kan het worden ondertekend met een zelfondertekend certificaat. Een zelfondertekend certificaat wordt gegenereerd door de klant of de ontwikkelaar met behulp van standaard .NET Framework SDK-hulpprogramma's en vervolgens toegepast op het implementatiemanifest met behulp van de standaard ClickOnce-implementatiehulpprogramma's. Zie MakeCert voor meer informatie.

Het gebruik van een zelfondertekend certificaat voor het implementatiemanifest biedt verschillende voordelen. Door de noodzaak voor de klant om een eigen Authenticode-certificaat te verkrijgen of te maken te elimineren, <useManifestForTrust> vereenvoudigt de implementatie voor de klant, terwijl de ontwikkelaar zijn eigen merkidentiteit op de toepassing kan behouden. Het resultaat is een set ondertekende implementaties die veiliger zijn en unieke toepassingsidentiteiten hebben. Dit elimineert het potentiële conflict dat kan optreden bij het implementeren van dezelfde toepassing voor meerdere klanten.

Zie Walkthrough voor stapsgewijze informatie over het maken van een ClickOnce-implementatie met <useManifestForTrust> ingeschakeld : Handmatig een ClickOnce-toepassing implementeren waarvoor geen herondertekening is vereist en waarin huisstijlgegevens behouden blijven.

Hoe toepassingsmanifest voor vertrouwen werkt tijdens runtime

Bekijk het volgende voorbeeld voor een beter begrip van het gebruik van het toepassingsmanifest voor vertrouwen tijdens runtime. Een ClickOnce-toepassing die is gericht op .NET Framework 3.5, wordt gemaakt door Microsoft. Het toepassingsmanifest maakt gebruik van het <useManifestForTrust> element en wordt ondertekend door Microsoft. Adventure Works ondertekent het implementatiemanifest met behulp van een zelfondertekend certificaat. Adventure Works-clients zijn geconfigureerd om alle toepassingen te vertrouwen die zijn ondertekend door Microsoft.

Wanneer een gebruiker op een koppeling naar het distributiemanifest klikt, installeert ClickOnce de toepassing op de computer van de gebruiker. De certificaat- en implementatiegegevens identificeren de toepassing uniek voor ClickOnce op de clientcomputer. Als de gebruiker dezelfde toepassing opnieuw probeert te installeren vanaf een andere locatie, kan ClickOnce deze identiteit gebruiken om te bepalen of de toepassing al op de client bestaat.

Vervolgens onderzoekt ClickOnce het Authenticode-certificaat dat wordt gebruikt om het toepassingsmanifest te ondertekenen. Dit bepaalt het vertrouwensniveau dat ClickOnce verleent. Aangezien Adventure Works de clients heeft geconfigureerd om alle toepassingen te vertrouwen die zijn ondertekend door Microsoft, wordt deze ClickOnce-toepassing volledig vertrouwd. Zie het overzicht van de implementatie van vertrouwde toepassingen voor meer informatie.

Klantimplementaties maken voor eerdere versies

Wat gebeurt er als een ontwikkelaar ClickOnce-toepassingen implementeert voor klanten die oudere versies van .NET Framework gebruiken? In de volgende secties vindt u een overzicht van verschillende aanbevolen oplossingen, samen met de voordelen en nadelen van elke oplossing.

Implementaties ondertekenen namens de klant

Een mogelijke implementatiestrategie is dat de ontwikkelaar een mechanisme voor het ondertekenen van implementaties namens hun klanten maakt met behulp van de eigen persoonlijke sleutel van de klant. Dit voorkomt dat de ontwikkelaar persoonlijke sleutels of meerdere implementatiepakketten moet beheren. De ontwikkelaar biedt alleen dezelfde implementatie voor elke klant. Het is aan de klant om deze aan te passen voor hun omgeving met behulp van de ondertekeningsservice.

Een nadeel van deze methode is de tijd en kosten die nodig zijn om deze te implementeren. Hoewel een dergelijke service kan worden gebouwd met behulp van de hulpprogramma's in de .NET Framework SDK, wordt er meer ontwikkeltijd toegevoegd aan de levenscyclus van het product.

Zoals eerder in dit onderwerp is opgemerkt, is een ander nadeel dat de versie van elke klant van de toepassing dezelfde toepassings-id heeft, wat kan leiden tot conflicten. Als dit een probleem is, kan de ontwikkelaar het veld Naam wijzigen dat wordt gebruikt bij het genereren van het implementatiemanifest om elke toepassing een unieke naam te geven. Hiermee maakt u een afzonderlijke identiteit voor elke versie van de toepassing en elimineert u mogelijke identiteitsconflicten. Dit veld komt overeen met het -Name argument voor Mage.exeen met het veld Naam op het tabblad Naam in MageUI.exe.

Stel dat de ontwikkelaar een toepassing met de naam Application1 heeft gemaakt. In plaats van één implementatie te maken met het veld Naam ingesteld op Application1, kan de ontwikkelaar verschillende implementaties maken met een klantspecifieke variatie op deze naam, zoals Application1-CustomerA, Application1-CustomerB, enzovoort.

Implementeren met behulp van een installatiepakket

Een tweede mogelijke implementatiestrategie is het genereren van een Microsoft Setup-project om de eerste implementatie van de ClickOnce-toepassing uit te voeren. Dit kan worden opgegeven in een van de verschillende indelingen: als een MSI-implementatie, als een uitvoerbaar installatiebestand (.EXE) of als een cabinetbestand (.cab) samen met een batchscript.

Met deze techniek zou de ontwikkelaar de klant een implementatie bieden die de toepassingsbestanden, het toepassingsmanifest en een implementatiemanifest bevat dat als sjabloon fungeert. De klant voert het installatieprogramma uit, waarmee deze wordt gevraagd om een implementatie-URL (de server- of bestandssharelocatie van waaruit gebruikers de ClickOnce-toepassing installeren) en een digitaal certificaat. De installatietoepassing kan er ook voor kiezen om extra ClickOnce-configuratieopties te vragen, zoals het interval voor updatecontrole. Zodra deze informatie is verzameld, zou het installatieprogramma het echte implementatiemanifest genereren, ondertekenen en de ClickOnce-toepassing publiceren naar de aangewezen serverlocatie.

Er zijn drie manieren waarop de klant het implementatiemanifest in deze situatie kan ondertekenen:

  1. De klant kan een geldig certificaat gebruiken dat is uitgegeven door een certificeringsinstantie (CA).

  2. Als variatie op deze benadering kan de klant ervoor kiezen om het implementatiemanifest te ondertekenen met een zelfondertekend certificaat. Het nadeel hiervan is dat de toepassing de woorden 'Onbekende uitgever' weergeeft wanneer de gebruiker wordt gevraagd of deze moet worden geïnstalleerd. Het voordeel is echter dat kleinere klanten geen tijd en geld hoeven te besteden aan een certificaat dat is uitgegeven door een certificeringsinstantie.

  3. Ten slotte kan de ontwikkelaar een eigen zelfondertekend certificaat opnemen in het installatiepakket. Dit introduceert de mogelijke problemen met de toepassingsidentiteit die eerder in dit onderwerp zijn besproken.

    Het nadeel van de implementatieprojectmethode is de tijd en kosten die nodig zijn om een aangepaste implementatietoepassing te bouwen.

Laat de klant implementatiemanifest genereren

Een derde mogelijke implementatiestrategie is het afleveren van alleen de toepassingsbestanden en het toepassingsmanifest aan de klant. In dit scenario is de klant verantwoordelijk voor het gebruik van de .NET Framework SDK om het implementatiemanifest te genereren en te ondertekenen.

Het nadeel van deze methode is dat de klant de .NET Framework SDK-hulpprogramma's moet installeren en een ontwikkelaar of systeembeheerder moet hebben die er ervaring mee heeft. Sommige klanten kunnen een oplossing eisen die weinig of geen technische inspanning vereist.

Verwante inhoud

  • Last updated on