September 2023
Autor:in des Beitrags
Antonio
Consultant
Projects – Cloud
Veröffentlicht am
21.09.2023 von Antonio
Aktualisiert am
25.06.2024 von Antonio
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. 

Konfiguration

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.

Key Vault Konfiguration

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

Did Registrierung & Verify domain ownership

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.

Azure Static Site

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:

Jetzt kann mit Punkt 5 Verify domain ownership aus dem Setup weiterverfahren werden.

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.

Konfiguration der Verifiable Credential

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:

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

Issuer Web App

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.

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

Blogbeitrag

Supportende für Windows 10

Supportende für Windows 10 wir zeigen auf, welche Optionen zur Verfügung stehen um Sicherheits- und Compliance-Risiken zu vermeiden.
Weiterlesen
Blogbeitrag

Virtual Workplace Evolution 2025

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

Whitepaper – KI in der Praxis

Lesen Sie, wie innovative Unternehmen KI nutzen, um Routineaufgaben zu automatisieren um neue Maßstäbe in Effizienz und Produktivität zu setzen.
Weiterlesen
Blogbeitrag

KI Ready Nürtingen

Erfahren Sie im Fachvortrag, wie Unternehmen datenschutzkonforme KI-Chatbots – effizient, kostengünstig und EU-konform mit Microsoft Cloud entwickeln.
Weiterlesen
Blogbeitrag

Supportende für Microsoft Office 2016 und 2019

Unternehmen, die aktuell Office 2016 oder Office 2019 einsetzen, sollten sich auf das bevorstehende Supportende vorbereiten und rechtzeitig die nächsten Schritte einleiten.
Weiterlesen
Blogbeitrag

Supportende für Skype for Business 2015 und 2019

Durch das Supportende für Skype for Business 2015 und 2019 sind Unternehmen Sicherheits- und Compliancerisiken ausgesetzt – Handeln Sie Jetzt um Risiken zu vermeiden.
Weiterlesen
Blogbeitrag

NetScaler: Neues Verhalten bei Pooled-Lizenzablauf 

Seit Version 14.1 Build 38.x führt das Ablaufen einer Pooled Lizenz direkt zur Deaktivierung des NetScalers – ohne Grace Period und mit Risiko von Konfigurationsverlust.
Weiterlesen
Echt Ich

Echt Ich Luisa

In ECHT ICH erfahrt ihr mehr über Luisa, ihren Arbeitsalltag, ihre Hobbys und warum sie bei Provectus „ECHT SIE“ sein kann.
Weiterlesen
Whitepaper

Whitepaper – eDialogPRO

Regulatorische Anforderungen von FinVermV und MiFID II effizient umsetzen und gleichzeitig das Kundenerlebnis verbessern – praxisnahe Lösungen und innovative Ansätze
Weiterlesen
Blogbeitrag

Supportende für Microsoft Exchange 2016 & 2019

Durch das Supportende für Exchange Server 2016 und 2019 sind Unternehmen Sicherheits- und Compliancerisiken ausgesetzt. Unser Experte erklärt, was nun zu tun ist.
Weiterlesen
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter