September 2023
Autor:in des Beitrags
Antonio
Consultant
Projects – Cloud
Veröffentlicht am
21.09.2023 von Antonio
Aktualisiert am
21.09.2023 von Antonia
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter
Bereitstellung der Infrastruktur

Microsoft Entra Verified ID

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. 

Microsoft Entra Verified ID mit DID:ION

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.

Unterschiede:

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.

TRUSTED DOMAIN

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.

Konfiguration

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.

Anlegen der statischen App für die Trusted Domain Verifizierung

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.

DevOps laut Azure:

„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.

Konfiguration Verifiable Credential

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.

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.

Issuer Web App

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.

Issuevorgang und Zusammenfassung

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

Sie möchteN mehr infos?

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

+49 89 71040920

florian@provectus.de

Zum Kontaktformular

Das könnte dich auch interessieren

Whitepaper

Whitepaper – KI-ready

In unserem Whitepaper erhalten Sie einen Überblick über die Herausforderungen, welche die Künstlicher Intelligenz mit sich bringt.
Weiterlesen
Blogbeitrag

Bereitstellung Elastic Stack und Anbindung der NetScaler Syslogs

In diesem Teil steht der Elastic Stack auf dem Plan – Kibana, Elasticsearch und Logstash stehen in den Startlöchern.
Weiterlesen
Blogbeitrag

Virtual Workplace Evolution

Wir sind dabei und freuen uns auf den spannenden Austausch zur Transformation von IT Workplaces.
Weiterlesen
Blogbeitrag

KI-Nutzungsrichtlinie: So nutzen Sie KI sicher und compliant

Erfahren Sie, wie Sie eine KI-Nutzungsrichtlinie erstellen können, und Ihre Daten und die Daten Ihrer Kunden zu schützen.
Weiterlesen
Blogbeitrag

Voraussetzungen für den effizienten Einsatz von KI im Unternehmen

Erhalten Sie einen Überblick über die wichtigsten Voraussetzungen, die Sie erfüllen müssen, um KI in Ihrem Unternehmen einzuführen.
Weiterlesen
Echt Ich

Echt Ich Katharina

In ECHT ICH erfahrt ihr mehr über Katharina, ihren Arbeitsalltag, ihre Hobbys und warum sie bei Provectus “ECHT Sie” sein kann.
Weiterlesen
Blogbeitrag

New Teams VDI

Mit der neuen Teams-Version hat sich nicht nur das Design geändert, sondern auch die Installationsroutine. Wir klären auf!
Weiterlesen
Blogbeitrag

KI statt Excel

Entdecken Sie die Vorteile von cloud-basierten Datenbanken und KI-gestützten Datenflüssen für die Automatisierung Ihrer Geschäftsprozesse.
Weiterlesen
Blogbeitrag

KI im Unternehmen einführen: Muss es denn gleich Microsoft 365 Copilot sein?

In diesem Beitrag erhalten Sie von uns einige Orientierungshilfen, damit Sie eine KI-Strategie für Ihr Unternehmen entwickeln können.
Weiterlesen
Blogbeitrag

Verfahren für Single Sign-on

Julian Sperling erläutert alle Kernkonzepte des SSO mit Entra ID und zeigt, wann man sie benötigt.
Weiterlesen
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter