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.
Grundlegend ist die Konfiguration hier ausreichend beschrieben. Da wir aber die did:ion Methode verwenden, werde ich kurz auf die Unterschiede (mit Angabe der entsprechenden Links) eingehen und auch das Setup für unseren eigenen Service Endpoint mit Domänen Verifizierung beschreiben.
Kein nativer AAD User als Service Account:
Hier wird ein AAD User namens VC Admin angelegt, welcher die entsprechende Berechtigungen im Key Vault erhält, um das Microsoft Entra Verified ID einzurichten.
Dies ist jedoch nicht unbedingt nötig und kann auch über einen personalisierten Admin mit der entsprechenden Berechtigung durchgeführt werden.
DID:ION Methode auswählen:
Hier unter 4 d did:ion wählen. Ist dieser Schritt abgeschlossen, steht das grundlegende Setup. Es muss zunächst weder eine App noch die DID registriert werden, da die did:ion Methode dies automatisch vornimmt.
Nach Abschluss des Setups werden im Key Vault automatisch die benötigten privaten Keys generiert, dazu später mehr.
Die Domain aus dem Schritt 4 b wird im Trust System DDO als Service Endpoint eingetragen. Unter dieser Domain wird unter dem Verzeichnis /.well-known/did.json der öffentliche Key abgefragt. Dieser öffentliche Key bildet mit den privaten Keys ein valides Key Pair.
Dieser öffentliche Key wird sowohl beim Issue-Vorgang als auch beim Presentation-Vorgang abgefragt, um private Signaturen des Issuers zu verifizieren. Hiermit wird sichergestellt, dass die VC wirklich von dem genannten Issuer stammt und die Domäne stimmt.
Für diese Domain Verification bietet sich eine statische App in Azure an. Diese dedizierte Ressource kann statische Webinhalte hosten z. B. unseren Public Key. Gleichzeitig können wir, sofern wir die Domäne besitzen, eine kostenlose Custom Domain mit Azure verwaltetem TLS Zertifikat hinterlegen.
VCs 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.
Der User, der das Setup ausführt, braucht weitreichende Berechtigungen in Azure über Ressourcen (Empfehlung: Owner), der Azure AD (Empfehlung: temporärer Global Admin über PIM) und eventuell über DevOps.
Hier wird das Anlegen der Static App über Azure Portal und 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.“
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 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 dediziert abgekapselt sein und nur noch die did-configuration.json enthalten, denn andere Dateien sind von der index.html ebenfalls zu erreichen.
Als Build Preset wählt man hier „HTML“.
Nach der Erstellung wird in Azure DevOps folgendes erzeugt: Es wird 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 bereitgestellten Variablen Gruppe bereitgestellt. Das erzeugte yml-File enthält die Pipeline Definition.
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 und ein Verzeichnis „.well-known“ welches unsere did-configuration.json enthält, die unseren öffentlichen Key beinhaltet. Die did-configuration.json-Datei erhält man nach did-configuration.json.
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.
.well-known und did-configuration.json
Das Verzeichnis wird ähnlich angelegt unter new und Folder.
Name .well-known und File name did-configuration.json
Die Zeichenreihenfolge des runtergeladenen did-configuration.json in das neu erstellte kopieren und mit Commit speichern.
Nun kann die Pipeline getriggert und in der 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.
URL:
Nun muss diese Seite noch unter der eingetragenen Trusted Domain aufrufbar sein. Dazu unter der statischen App auf „Custom domains“ wechseln und „Custom domain on other DNS“ auswählen.
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.
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 VCs auszustellen und zu überprüfen.
Damit durch das Microsoft Entra Verified ID Setup VCs ausgestellt werden können, muss zunächst das Aussehen und die enthaltenen Informationen (engl. Claims) definiert werden.
Wir verwenden die default Konfiguration nach:
https://learn.microsoft.com/en-us/azure/active-directory/verifiable-credentials/how-to-use-quickstart-verifiedemployee#create-a-verified-employee-credential
Dazu im Portal unter Verified ID:
Hier dann neue VCs erstellen:
Verified employee genügt:
Hier kann jetzt noch das Aussehen der Karte geändert werden, weiter unten werden die Standard Claims angezeigt:
Die Claims werden aus dem „JWT“ Token (JSON Web Token) gelesen.
Nun können Web Applikationen das Microsoft Entra Verified ID Setup nutzen, um VCs auszustellen. Egal, ob man nun die LinkedIn-Kompatiblität nutzen möchte oder nicht, bietet dieses Repository eine tolle Lösung. Es bietet nicht nur eine Integration für die LinkedIn Workplace Integration, sondern auch die Möglichkeit, VCs für die Microsoft Authenticator App auszustellen.
Das Setup und das Deployment sind hier beschrieben.
Überprüfen lässt sich die Funktionialität dann über die https://<your webapp url>/issue.
An dieser soll nochmal die Azure-Infrastruktur zusammengefasst und der Issuevorgang für die Microsoft Authenticator App allgemein dargestellt werden.
1. Der User ruft die erstellt Azure Web App auf im Pfad „issue“ auf.
Er wird dazu aufgefordert, sich bei der eigenen Enterprise Application anzumelden (App Registrierung + Enterprise Application im gleichem Tenant).
Bei der App Registration wird mithilfe der Redirect URL wieder auf die Web App im Verzeichnis „signin-oidc“ weitergeleitet. Durch Zugriff auf das self signed Zertifikat über den Key Vault, erhält die Web App Zugriff auf das „JWT“ Token des eingeloggten Users. Dieses enthält alle benötigten Claims (Ich habe die eingebetteten Texte hier ins Deutsch übersetzt).
2. Nach drücken des Button „Erhalte dein Arbeitsnachweis“ nutzt die privilegierte System Managed Identity die „VerifiableCredential.Create.IssueRequest“ Permission.
Beim Post Request an die Azure AD Verifiable Credential API wird dieser Request mit dem privaten Key „vcSigningKey-x“ vom Service Prinzipal der Microsoft Application „Verifiable Credentials Service Request” signiert.
Nun wird der QR-Code angezeigt, der alle Daten für die VC Request erhält. Mit der Micr. Auth. App kann dieser Request gescannt werden und runtergeladen werden.
Jetzt wird mithilfe des öffentlichen Keys durch did:ION-Abfrage des Sevice Endpoints die Signatur und Domain überprüft. Ist das erfolgreich erhält man seine VC Request.
3. Nun kann man mithilfe des ‘Hinzufügen’-Buttons die eigentlich VC anfragen.
Auch diese wird wieder bei der Azure AD Verifiable Credential API angefragt. Die VC wird auch mit dem privaten „vcSigningKey-x“ signiert, aber diesmal vom Service Prinzipal der Microsoft Application „Verifiable Credentials Service”. Letztlich wird die VC im Wallet der Microsoft Auth. App gespeichert.
Der log analytics Workspace dient einzig dem auditieren des Einsatzes des privaten Keys. Am Issue Vorgang selbst ist er nicht beteiligt.
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
