Nachdem wir im ersten Teil die Vorteile der VCs erörtert haben, zeige ich in diesem Beitrag eine mögliche Konfiguration und erläutere, welche Azure-Komponenten benötigt werden.
Der User, der das Setup ausführt braucht weitreichende Berechtigungen in Azure über Ressourcen (Empfehlung: Owner), der Entra ID (Empfehlung: temporärer Global Admin über PIM) und eventuell über DevOps.
Grundlegend ist die Konfiguration hier ausreichend beschrieben: Tutorial – Quick setup of your tenant for Microsoft Entra Verified ID – Microsoft Entra Verified ID | Microsoft Learn.
Wir nutzen das Advanced setup, um einen besseren Einblick in die Konfiguration in von Entra Verified ID zu erhalten. Dies umfasst die Bereitstellung des Signatur/Verify Key Pairs, die Registrierung der did und die Domänenverifikation.
Zunächst wird ein Key Vault benötigt, wie hier beschrieben: https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-configure-tenant#create-a-key-vault
Wichtig ist hier, dass man die beiden Microsoft Applications (Service Principals) „Verifiable Credentials Service“ und „Verifiable Credentials Service Request“ mit entsprechenden Key-Berechtigungen ausstattet. Zusätzlich benötigt der User, welcher Verified ID aufsetzt die Berechtigung zum Erstellen von Keys. Die Microsoft Application „Verifiable Credentials Service Admin“ nimmt diese User-Identität an, um das Signatur/Verify Key Pairs anzulegen.
Ist dies abgeschlossen, kann dieser mit dem ersten Schritt „Configure organization settings“ in Verified ID Setup gestartet werden (siehe hier Setting – configure organization settings).
Um über die did:web-Methode nun die DID zu registrieren, muss das did.json öffentlich gehostet werden. Nach diesem Schritt kann dann noch der Domänenbesitz bestätigt werden, indem ebenfalls ein Dokument „did-configuration.json“ gehostet wird z. B. did.provectus.de/.well-known/did-configuration.json. Dies entspricht der Vorgabe des Decentralized Identity Foundation: Well Known DID Configuration (identity.foundation)
Im Advanced Setup ist das Schritt 2 und 3.
Beide Schritte können technisch mit einer Azure static App realisiert werden.
Hier wird das Anlegen der Static App über Azure Portal und die Code-Bereitstellung über Azure DevOps mithilfe einer Pipeline (Sprache im Portal Englisch) gezeigt. Alternativ kann das Deployment auch mithilfe von Visual Studio bereitgestellt werden (Azure Static Web Apps – Visual Studio Marketplace).
Der auszuführende User muss dafür die entsprechenden Azure-Berechtigungen und DevOps besitzen.
Hinweis:
Stellen Sie sicher, dass der verwendete Branch nicht geschützt ist und dass Sie über ausreichende Berechtigungen zum Ausgeben eines push-Befehls verfügen. Navigieren Sie zur Überprüfung zu Ihrem DevOps-Repository, wechseln Sie zu Repos ->Branches, und wählen Sie Weitere Optionen aus. Wählen Sie als Nächstes Ihren Branch und dann Branchrichtlinien aus, um sicherzustellen, dass die erforderlichen Richtlinien nicht aktiviert sind. (https://learn.microsoft.com/de-de/azure/static-web-apps/get-started-portal?tabs=vanilla-javascript&pivots=azure-devops#create-a-static-web-app)
Im Portal nach „stat“ suchen und Static Web Apps auswählen.
Dort auf Create:
Gewünschte Subskription, Ressourcengruppe, Name und Region eingeben. Ich verwende den kostenlosen Free Types, da hier keine hohen Performance Ansprüche zu erwarten sind.
Wichtig ist hier der Parameter „app_location“ hier muss in unserem Fall das index.html abliegen. Das ist also das html Stammverzeichnis. Lässt man es leer wird das Stammverzeichnis des Repositorys verwendet und dort muss das index.html File abgelegt werden.
Der Pfad sollte möglichst ein dedizierter abgekapselter sein welcher wirklich nur noch die did-configuration.json enthält, denn andere Dateien sind relativ von der index.html ebenfalls zu erreichen.
Als Build Preset wählt man hier „HTML“.
Nach der Erstellung wird in Azure DevOps PAT für die Static App erzeugt. Damit kann die PAT auf Azure DevOps zugreifen (Repository und Pipelines).
Zusätzlich eine Pipeline, welche das eigentliche Code Deployment vornimmt. Zugriff auf die statische App aus Azure DevOps zu Azure erhält man über das „azure_static_web_apps_api_token“. Dieses wird wiederum aus einer variablen Gruppe bereitgestellt. Das erzeugte yml-File enthält die Pipeline-Definition.
Ich empfehle, den Trigger noch umzuschreiben, da es sich hier um eine hochstatische App handelt, sind Code Updates nicht zu erwarten und bei jedem automatischen Trigger werden Azure DevOps Agent/Runner Minuten konsumiert.
Von
trigger:
branches:
include:
- main
Zu
trigger: trigger: -none
Dafür bei dem yml-File “Edit” anklicken und mit „Commit“ speichern.
Nun kann die Pipeline nur noch manuell gestartet werden.
Jetzt benötigen wir noch eine index.html ein Verzeichnis „.well-known“ welches zunächst unsere did.json enthält.
index.html
Im entsprechendem Verzeichnis (hier Stammverzeichnis) auf New und File auswählen.
Name index.html
Und mit Commit speichern.
Der Inhalt der index.html ist egal, wird die Seite angesurft hat diese keinen Titel und Inhalt.
Für das Setup „Register decentralized ID“ benötigen wir zunächst die did.json. Diese erhalten wir im in Punkt 4 von Setup – Register decentralized ID innerhalb des Azure Portals.
Den Inhalt der did.json kopieren und das Verzeichnis .well-known in DevOps anlegen.
Das Verzeichnis wird angelegt unter new und Folder.
Name .well-known und File name did.json
Danach den kopierten Inhalt in die did.json einfügen. Zum Editieren auf „Edit“ drücken:
Nochmals bestätigen:
Nun kann die Pipeline getriggert werden und statischen App der Code bereitgestellt werden.
Nun kann man im Portal zur statischen App wechseln.
Jede statische App besitzt eine FQDN in der Form „<zufälliger Name>.azuerstaticapps.net“ Hiermit kann verifiziert werden ob das did-configuration.json über „https://<zufälliger Name>.azuerstaticapps.net/.well-known.did-configuration.json“ abrufbar ist. Zusätzlich muss hier noch die custom domain angepasst werden, passend zur Domäne aus Schritt 1 des Setups hier „did.provectus.de“.
Dazu unter der Statischen App auf „Custom domains“ wechseln und „Custom domain on other DNS“
Hier die trusted domain eintragen z. B. did.provectus.de und auf Next drücken.
Nun wird der Eintrag angezeigt der im DNS Domain System eingetragen werden muss. Es handelt sich um einen CNAME für die Zone provectus.de, der auf den default Domainname der statischen App zeigt. Damit wird bewiesen, dass man auch wirklich im Besitz der Domäne ist.
Wird die Trusted Domain entsprechend aufgelöst gelingt die Validation und die Custom Domain ist für diese statische App angelegt.
Nun sollte die did-configuration.json auch über die trusted domain aufrufbar sein.
Die did.provectus.dewell-known.did.json sollte wie folgt ausschauen:
Nun kann das Setup mit „Verify domain ownership“ abgeschlossen werden. Dazu muss Analog ein did-configuration.json im .well-known Verzeichnis der Static App hochgeladen werden, siehe hierzu Verify domain ownership.
Den Inhalt der did-configuration.json kopieren und die Datei wieder über DevOps der Static App bereitstellen.
Nun muss diese Seite noch unter der eingetragenen Trusted Domain aufrufbar sein.
Nun kann auch über den Microsoft Entra Verified ID die Domain verifiziert werden (Schritt 5 Verify DID Domain)
Das wäre das Grundsetup mit Domain Verification. Potenziell können nun Applikationen dieses Setup nutzen um VC auszustellen und zu überprüfen. Folgend wird eine VC gezeigt, die ohne und mit Domain Verification ausgestellt wird.
VC ohne verifizierte Domains sollten nicht dem Wallet hinzugefügt werden. Erst durch eine Verifikation weißt eine Organisation nach, dass sie diese DID auch besitzt.
Damit durch das Microsoft Entra Verified ID Setup VCs ausgestellt werden kann muss zunächst das Aussehen und die enthaltenen Informationen (engl. Claims) definiert werden.
Wir verwenden die default Konfiguration nach:
Dazu im Portal unter Verified ID
Hier dann neue VC erstellen:
Verified employee genügt:
Hier kann jetzt noch das Aussehen der Karte geändert werden, weitere unten werden die Standard Claims angezeigt:
Die Claims werden aus dem „JWT“ Token (JSON Web Token) gelesen.
Dieses Setup kann von allen Web Apps genutzt werden, um im Namen der Organisation Verifiable Credentials auszustellen. Dafür müsste initial diese App registriert werden innerhalb der Entra ID App Registrierung für VC Ausstellung und eine eigene App gehostet werden.
Alternativ können durch ein VC Preview Feature VCs durch die My Account Seite (My Account (microsoft.com) )bereitgestellt werden.
Eine App Registrierung und Hosting für dafür nicht benötigt.
Dafür innerhalb der Verified ID die gerade erstellte Arbeitsnachweis VC ausstellen.
Unter „Issue a credential“ kann zunächst ausgewählt, welche Entra ID User sich Arbeitsnachweise ausstellen können und ob die Ausstellung über My Account erfolgen kann.
Die Änderung mit „Save übernehmen:
Nach wenigen Minuten sollte der User nun sich unter My Account (microsoft.com) ein VC ausstellen lassen können.
Mit einer Wallet App z. B. dem „Microsoft Authenticator“ kann der QR-Code gescannt werden:
Eine Demo Seite gibt es unter Proseware.com. Diese App vertraut den Arbeitsnachweis ausgestellt von unserer did.
Der Workflow einer VC Ausstellung ist hier beschrieben. https://learn.microsoft.com/en-us/entra/verified-id/introduction-to-verifiable-credentials-architecture#flow-1-verifiable-credential-issuance
Dieses Setup kann verwendet werden, um bei LinkedIn Arbeitsnachweise auszustellen. Leider ist dieses Feature noch in Preview und es muss ein Forms ausgefüllt werden Setting up LinkedIn workplace verification – Microsoft Entra Verified ID | Microsoft Learn
Dafür ist auch ein Forms auszufüllen. Sobald diese Funktion allgemein verfügbar ist wird in einem dritten Teil der Arbeitsplatz Nachweis per VC aufgezeigt.
Im nächsten Teil 3 zeige ich, wie die vorhandene Infrastruktur bei LinkedIn genutzt werden kann, um den Arbeitsplatznachweis einzurichten und aktiv zu nutzen.
Wir sind für SIE da.
Auch für Ihre Herausforderung bieten wir die passende Lösung. Zögern Sie nicht uns zu kontaktieren. Wir unterstützen Sie gerne.
FLORIAN RZYTKI | Head of Sales
