Was passiert eigentlich, wenn Sie auf einer Power Pages-Website auf "Mit Microsoft anmelden" klicken? Dieser Leitfaden erklärt es mit einfachen Analogien und klaren Visualisierungen.
Die Kurzfassung: Ihr Portal bittet eine vertrauenswürdige Autorität (wie Microsoft), Ihre Identität zu überprüfen. Sie bestätigen es, und Sie sind drin. So einfach ist das.
Die drei Akteure
Bevor wir in die technischen Abläufe eintauchen, klären wir, wer beteiligt ist:
Sie (Der Benutzer)
Die Person, die sich anmelden möchte.
Power Pages (Ihr Portal)
Ihre Website. Sie muss wissen, wer Sie sind, bevor sie Sie hereinlässt.
Identity Provider (Der Türsteher)
Das vertrauenswürdige Unternehmen, das Ausweise überprüft. Gängige Beispiele:
- Microsoft Entra External ID
- Okta
Die zentrale Frage
Wie kann Ihr Portal darauf vertrauen, was Microsoft sagt?
Die Antwort: Digitale Signaturen. Wie ein fälschungssicheres Siegel auf einem Brief.
OAuth 2.0 / OpenID Connect Deep Dive
Gängige Identity Provider: Microsoft Entra External ID, Entra ID (Azure AD), Google, GitHub, Auth0, Okta (OIDC)
Protokoll-Ablauf: Authorization Code Flow mit PKCE (empfohlen) oder Hybrid Flow
Analogie aus dem echten Leben: Der Nachtclub mit Polizei-Verifizierung
Stellen Sie sich einen Nachtclub (Power Pages) vor, der keine eigenen Ausweise ausstellt. Stattdessen vertraut er der Polizeistation (Identity Provider), die Identität aller zu überprüfen.
- 1. Sie kommen am Club an und möchten hinein
- 2. Türsteher sagt: "Ich brauche einen Nachweis von der Polizeistation die Straße runter"
- 3. Sie gehen zur Polizeistation
- 4. Polizei überprüft Ihre Identität (prüft Ihren Pass) und gibt Ihnen ein gestempeltes Armband
- 5. Sie kehren mit dem Armband zum Club zurück
- 6. Türsteher prüft den Stempel (validiert, dass er echt ist) → "Sie dürfen rein!"
Warum das funktioniert: Der Club vertraut dem Stempel der Polizei. Die Polizei stempelt nur Armbänder für verifizierte Personen. Der Stempel kann nicht gefälscht werden (digitale Signatur). Das Armband läuft nach ein paar Stunden ab (Token-Ablauf).
Technischer Ablauf: Authorization Code Flow (Schritt für Schritt)
Phase 1: Benutzer initiiert Anmeldung
Schritt 1: Benutzer klickt auf "Mit Microsoft anmelden"-Button auf Power Pages
💡 Wie zum Nachtclub gehen
Phase 2: Autorisierungsanfrage
Schritt 2: Power Pages generiert eine Autorisierungsanfrage mit:
- •
client_id- Die ID Ihrer App - •
redirect_uri- Wohin nach der Anmeldung zurückgekehrt werden soll - •
scope- Welche Informationen Sie benötigen (openid, email, profile) - •
state- Zufallswert zur Verhinderung von CSRF-Angriffen - •
nonce- Zufallswert zur Verhinderung von Replay-Angriffen
💡 Wie der Türsteher, der eine Notiz schreibt: "Bitte verifizieren Sie diese Person und schicken Sie sie zurück"
Schritt 3: Browser leitet Benutzer zum Identity Provider weiter (z.B. Microsoft-Anmeldeseite)
💡 Wie zur Polizeistation gehen
Phase 3: Benutzer-Authentifizierung
Schritt 4: Benutzer gibt Benutzername und Passwort auf der Anmeldeseite des IdP ein
Schritt 5: IdP validiert die Anmeldedaten gegen seine Benutzerdatenbank
💡 Wie die Polizei, die Ihren Pass prüft
Phase 4: Authorization Code Austausch
Schritt 6: IdP generiert einen Authorization Code (kurzlebig, einmalig verwendbar)
Schritt 7: Browser leitet zurück zu Power Pages mit dem Code in der URL:
https://yoursite.powerappsportals.com/signin-oidc?code=abc123&state=xyz
💡 Wie eine temporäre Quittung von der Polizei bekommen - noch nicht der vollständige Ausweis
Schritt 8: Power Pages überprüft den state-Parameter (CSRF-Schutz)
Schritt 9: Power Pages macht eine Backend-Anfrage an den Token-Endpunkt des IdP:
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=abc123&
client_id=your-client-id&
client_secret=your-secret&
redirect_uri=https://yoursite.powerappsportals.com/signin-oidc💡 Wie der Club-Manager, der bei der Polizeistation anruft, um die Quittung zu verifizieren
Warum Backend? Das client_secret darf niemals dem Browser ausgesetzt werden!
Phase 5: Token-Validierung & Session-Erstellung
Schritt 10: IdP gibt Tokens zurück:
- • id_token (JWT) - Enthält Benutzeridentitäts-Claims
- • access_token - Für API-Aufrufe (optional in Power Pages)
- • refresh_token - Um neue Tokens ohne erneute Anmeldung zu erhalten (optional)
Schritt 11: Power Pages validiert das id_token:
- ✅ Signatur ist gültig (unter Verwendung des öffentlichen Schlüssels des IdP)
- ✅ Aussteller (
iss) stimmt mit erwartetem IdP überein - ✅ Zielgruppe (
aud) stimmt mit unserer client_id überein - ✅ Token ist nicht abgelaufen (
exp-Claim) - ✅ Nonce stimmt mit dem gesendeten überein
💡 Wie der Türsteher, der prüft, dass der Stempel echt und nicht abgelaufen ist
Schritt 12: Power Pages extrahiert Benutzer-Claims aus dem Token (E-Mail, Name, etc.)
Schritt 13: Power Pages erstellt oder aktualisiert Kontaktdatensatz in Dataverse
Schritt 14: Power Pages erstellt ein Session-Cookie
Schritt 15: Benutzer wird zur ursprünglich angeforderten Seite weitergeleitet
💡 Wie endlich mit Ihrem verifizierten Armband in den Club kommen
Phase 6: Nachfolgende Anfragen
Bei jedem Seitenaufruf: Power Pages prüft das Session-Cookie
Token abgelaufen? Refresh Token verwenden, um neue Tokens zu erhalten (falls konfiguriert)
Session abgelaufen? Benutzer muss sich erneut anmelden
Warum der Zwei-Schritt-Tanz? (Code → Tokens)
Das Problem: Wenn der IdP Tokens direkt in der Browser-URL (oder als POST an den Browser) senden würde, könnte bösartiges JavaScript auf der Seite sie stehlen.
Die Lösung: Der Authorization Code Flow trennt die Zuständigkeiten:
- Frontend: Browser sieht nur einen kurzlebigen, einmalig verwendbaren Authorization Code
- Backend: Power Pages Server tauscht den Code gegen Tokens unter Verwendung des Client Secret
- Ergebnis: Tokens berühren niemals den Browser, was Token-Diebstahl unmöglich macht
💡 Es ist, als würde man eine Quittung bei der Polizeistation bekommen, dann ruft der Club-Manager an, um zu verifizieren und die vollständigen Details privat zu erhalten.
Visuelles Flussdiagramm
(client_id, redirect_uri, scope, state, nonce) PP->>Browser: 7. HTTP 302 Redirect to IdP Browser->>IdP: 8. GET /authorize?params end rect rgb(200, 255, 220) Note over User,IdP: User Authentication Phase IdP->>Browser: 9. Show login page User->>Browser: 10. Enter username/password Browser->>IdP: 11. POST credentials IdP->>IdP: 12. Validate credentials end rect rgb(255, 255, 200) Note over Browser,PP: Authorization Code Exchange IdP->>Browser: 13. HTTP 302 with code Browser->>PP: 14. GET /signin-oidc?code=xyz&state=abc PP->>PP: 15. Verify state parameter PP->>IdP: 16. POST /token
(code, client_id, client_secret) IdP->>IdP: 17. Validate code & client IdP->>PP: 18. Return id_token + access_token end rect rgb(220, 200, 255) Note over PP: Token Validation & Session Creation PP->>PP: 19. Validate id_token signature PP->>PP: 20. Check iss, aud, exp, nonce PP->>PP: 21. Extract user claims PP->>PP: 22. Create/update user in Dataverse PP->>PP: 23. Create session cookie end PP->>Browser: 24. Set-Cookie + Redirect to original page Browser->>PP: 25. Request original page with cookie PP->>Browser: 26. Return protected content Browser->>User: 27. Display page
💡 Diagramm-Legende: Die farbigen Boxen gruppieren zusammenhängende Schritte. Die Nummern entsprechen der schrittweisen Erklärung oben.
Erforderliche Parameter
Diese Parameter müssen konfiguriert werden, damit die Authentifizierung funktioniert:
| Parameter | Beschreibung | Beispielwert |
|---|---|---|
| Provider NameERFORDERLICH | Der Text, der auf dem Anmelde-Button angezeigt wird, den Benutzer auf der Anmeldeseite sehen | "Mit Firmenkonto anmelden" "Mit Microsoft anmelden" |
| AuthorityERFORDERLICH | Die Autorisierungs-Endpunkt-URL des Identity Providers. Dies teilt Power Pages mit, wohin Benutzer zur Authentifizierung weitergeleitet werden sollen. | https://{tenant}.ciamlogin.com/ (Entra External ID)https://login.microsoftonline.com/{tenant-id}/ (Entra ID)https://accounts.google.com/ (Google) |
| Client IDERFORDERLICH | Die Anwendungs-ID (Client-ID) aus Ihrer IdP-App-Registrierung. Diese identifiziert Ihre Power Pages-Site eindeutig beim Identity Provider. | 12345678-90ab-cdef-1234-567890abcdef |
| Redirect URLERFORDERLICH | Die Power Pages Callback-URL, an die der IdP Benutzer nach der Authentifizierung sendet. Wird automatisch von Power Pages generiert. Verwenden Sie immer die Kopieren-Schaltfläche - niemals manuell eingeben! | https://yoursite.powerappsportals.com/signin-oidchttps://customdomain.com/signin-oidc |
| Metadata AddressERFORDERLICH | Die URL des OpenID Connect Discovery-Dokuments. Diese URL enthält alle Endpunkte, unterstützten Funktionen und öffentlichen Schlüssel zur Token-Validierung des IdP. Power Pages ruft dieses Dokument automatisch ab, um sich selbst zu konfigurieren. | https://{tenant}.ciamlogin.com/.well-known/openid-configurationhttps://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration |
| ScopeERFORDERLICH | Leerzeichengetrennte Liste der anzufordernden OAuth-Scopes. openid ist obligatorisch für OpenID Connect. Fügen Sie email hinzu, um die E-Mail-Adresse des Benutzers zu erhalten, profile für Vor- und Nachname. |
openid email (minimal)openid email profile (empfohlen) |
| Response TypeERFORDERLICH | Der OAuth-Flow-Typ. code id_token (Hybrid Flow) wird aus Sicherheitsgründen empfohlen - es liefert sowohl einen Authorization Code (für den Backend-Token-Austausch) als auch ein ID-Token (für sofortige Benutzerinformationen). |
code id_token (empfohlen)codeid_token |
| Client SecretERFORDERLICH* | Das Client Secret aus Ihrer IdP-App-Registrierung. Erforderlich, wenn Response Type code enthält. Dieses Secret beweist dem IdP, dass die Token-Austausch-Anfrage von Ihrer autorisierten Power Pages-Site kommt. Halten Sie dieses Secret sicher! |
*Nur erforderlich, wenn Response Type code enthält |
| Response ModeERFORDERLICH | Wie der IdP die Authentifizierungsantwort zurückgibt. form_post wird empfohlen - es sendet Tokens per HTTP POST (sicherer als URL-Fragmente). |
form_post (empfohlen)queryfragment |
Optionale / Erweiterte Parameter
Diese Parameter bieten zusätzliche Kontrolle, sind aber für die Basisauthentifizierung nicht erforderlich:
| Parameter | Beschreibung | Standard / Anwendungsfall |
|---|---|---|
| External LogoutOPTIONAL | Föderierte Abmeldung aktivieren. Bei Ein meldet die Abmeldung von Power Pages den Benutzer auch vom IdP ab (und allen anderen Apps, die diesen IdP verwenden). Bei Aus erfolgt nur die Abmeldung von Power Pages - der Benutzer bleibt beim IdP angemeldet. | Aus (Standard) Einschalten für: Hochsicherheitsszenarien, die vollständige Abmeldung erfordern Ausschalten für: Benutzer, die in anderen Apps angemeldet bleiben müssen |
| Post Logout Redirect URLOPTIONAL | Wohin Benutzer nach der Abmeldung weitergeleitet werden. Muss in den erlaubten Abmelde-URLs des IdP konfiguriert sein. | https://yoursite.powerappsportals.com/ |
| RP Initiated LogoutOPTIONAL | Erlaubt der vertrauenden Partei (Power Pages), die Abmeldung beim IdP zu initiieren. Funktioniert nur, wenn External Logout eingeschaltet ist. | Aus (Standard) Erfordert: External Logout = Ein |
| Issuer FilterOPTIONAL | Wildcard-basierter Filter für Multi-Tenant-Szenarien. Verwenden Sie dies, wenn Sie Tokens von mehreren Azure AD-Tenants akzeptieren möchten. Das * passt auf jede Tenant-ID. |
https://sts.windows.net/*/Anwendungsfall: B2B-Portale, bei denen sich Benutzer verschiedener Unternehmen authentifizieren |
| Validate AudienceOPTIONAL | Zielgruppen-Validierung während der Token-Validierung aktivieren. Bei Ein überprüft Power Pages, ob der aud-Claim im Token mit einer Ihrer angegebenen Valid Audiences übereinstimmt. |
Aus (Standard) Produktionsempfehlung: Einschalten + Valid Audiences setzen |
| Valid AudiencesOPTIONAL | Kommagetrennte Liste erlaubter Zielgruppenwerte. Nur Tokens mit diesen Zielgruppen-Claims werden akzeptiert. Verhindert Token-Missbrauch über Anwendungen hinweg. | api://12345678-90ab-cdefapi://app1,api://app2Erfordert: Validate Audience = Ein |
| Validate IssuersOPTIONAL | Aussteller-Validierung während der Token-Validierung aktivieren. Bei Ein akzeptiert Power Pages nur Tokens von IdPs in Ihrer Valid Issuers-Liste. | Aus (Standard) Sicherheit: Verhindert Token-Replay von nicht autorisierten IdPs |
| Valid IssuersOPTIONAL | Kommagetrennte Liste erlaubter Aussteller-URLs. Nur Tokens von diesen Ausstellern werden akzeptiert. | https://sts.windows.net/{tenant1}/,https://sts.windows.net/{tenant2}/Erfordert: Validate Issuers = Ein |
| Registration Claims MappingOPTIONAL | Claims aus dem IdP-Token während der Benutzerregistrierung auf Dataverse-Kontaktfelder mappen. Format: contact_field=token_claim. Dies füllt automatisch Benutzerprofilfelder aus. |
firstname=given_name,lastname=family_nameUnterstützte Typen: Nur Text und Boolean |
| Login Claims MappingOPTIONAL | Claims aus dem IdP-Token bei jeder Anmeldung auf Dataverse-Kontaktfelder mappen. Verwenden Sie dies, um Kontaktdaten bei jeder Anmeldung mit IdP-Daten synchron zu halten. | firstname=given_name,lastname=family_nameTipp: Verwenden Sie das gleiche Mapping wie bei Registration für Konsistenz |
| Nonce LifetimeOPTIONAL | Wie lange (in Minuten) der Nonce-Wert gültig ist. Nonce verhindert Replay-Angriffe, indem sichergestellt wird, dass jede Authentifizierungsanfrage nur einmal verwendet werden kann. | 10 Minuten (Standard) Anpassen wenn: Benutzer in langsamen Netzwerken Timeouts erleben |
| Use Token LifetimeOPTIONAL | Power Pages Session-Lebensdauer an die IdP-Token-Ablaufzeit anpassen. Bei Ein wird das standardmäßige 8-Stunden-Session-Timeout überschrieben. Session endet, wenn Token abläuft (typischerweise 1 Stunde). | Aus (Standard = 8 Stunden) Einschalten für: Hochsicherheits-Portale, die häufige Re-Authentifizierung erfordern |
| Contact Mapping with EmailOPTIONAL | IdP-Identität automatisch mit Dataverse-Kontakt basierend auf E-Mail-Adressübereinstimmung verknüpfen. Ein: Wenn ein Kontakt mit übereinstimmender E-Mail existiert, IdP-Identität automatisch mit diesem Kontakt verknüpfen. Aus: Neuen Kontakt für jede neue IdP-Identität erstellen, auch wenn E-Mail mit bestehendem Kontakt übereinstimmt. |
Ein (Standard - empfohlen) Wichtig: Bei Aus kann derselbe Benutzer mehrere Kontakte erstellen, wenn er verschiedene IdPs verwendet |
OAuth/OIDC Schnellstart
Für 90% der OAuth/OIDC-Szenarien benötigen Sie nur die Erforderlichen Parameter:
- App im IdP registrieren (Entra External ID, Google, etc.)
- Die Redirect URL aus Power Pages kopieren → als Redirect URI im IdP einfügen
- Client ID und Client Secret vom IdP erhalten
- Die Metadata Address finden (normalerweise in der IdP-App-Übersicht oder im Endpunkte-Bereich)
- Scope auf
openid emailsetzen (oderopenid email profile, wenn Sie Vor-/Nachname benötigen) - Response Type auf
code id_tokenund Response Mode aufform_postsetzen - Im Inkognito-Modus testen!
OAuth/OIDC Do's und ❌ Don'ts
DO - OAuth Best Practices (Empfohlene Vorgehensweisen)
- ✅ Verwenden Sie
code id_tokenResponse Type - Hybrid Flow bietet beste Sicherheit und Benutzererfahrung - ✅ Fordern Sie immer
emailScope an - Erforderlich für Benutzeridentifikation und Kontakt-Mapping - ✅ Verwenden Sie die Kopieren-Schaltfläche für Redirect URL - Tippfehler in Redirect URLs verursachen 80% der OAuth-Fehler
- ✅ Überprüfen Sie, dass Metadata URL öffentlich zugänglich ist - Öffnen Sie sie im Browser ohne Authentifizierung
- ✅ Beginnen Sie mit minimalen Scopes -
openid emailist ausreichend, fügen Sieprofilenur bei Bedarf hinzu - ✅ Setzen Sie Client Secret Ablauf auf 6-12 Monate - Erzwingt Rotation ohne zu häufig zu sein
- ✅ Testen Sie Token Claims in jwt.io - Überprüfen Sie, dass E-Mail, Name, Gruppen wie erwartet ankommen
- ✅ Aktivieren Sie Diagnoseprotokollierung vor dem Testen - Power Pages → Einstellungen → Authentifizierung → Protokollierung aktivieren
- ✅ Testen Sie mit Nicht-Admin-Konten - Admin-Konten haben andere Token Claims
- ✅ Konfigurieren Sie Claims Mapping für Vorname/Nachname - Verbessert Benutzererfahrung auf der Profilseite
DON'T - OAuth Fallstricke
- ❌ Geben Sie Redirect URL nicht manuell ein - Ein falsches Zeichen = kryptischer "redirect_uri_mismatch" Fehler
- ❌ Vergessen Sie nicht den abschließenden Schrägstrich in Authority -
https://login.microsoftonline.com/{tenant-id}/(benötigt abschließenden /) - ❌ Teilen Sie Client Secrets nicht über mehrere Websites - Jede Power Pages-Website benötigt ihre eigene App-Registrierung
- ❌ Testen Sie nicht nur in Ihrem eigenen Browser - Testen Sie im Inkognito-Modus, verschiedenen Browsern, mobilen Geräten
- ❌ Verwenden Sie nicht Implicit Flow - Response Type
id_tokenallein ist veraltet, verwenden Siecode id_token - ❌ Fordern Sie keine unnötigen Scopes an - Mehr Scopes = mehr Zustimmungsaufforderungen für Benutzer = höhere Abbruchrate
- ❌ Ignorieren Sie Token-Ablauf nicht - Standard 1-Stunden-Token-Lebensdauer erfordert Session-Management-Strategie
- ❌ Vergessen Sie nicht Post Logout Redirect URL zu konfigurieren - Ohne diese sehen Benutzer die IdP-Abmeldeseite statt Ihrer Website
- ❌ Gehen Sie nicht davon aus, dass SSO = Single Sign-Out - SSO funktioniert, aber Single Sign-Out wird in Power Pages NICHT unterstützt
- ❌ Überspringen Sie nicht die Claims Mapping Validierung - Falsches Mapping = defekte Benutzerprofile
Top 5 OAuth/OIDC Konfigurationsfehler
1. Redirect URI Mismatch
Problem: URL in Power Pages stimmt nicht exakt mit URL in IdP-App-Registrierung überein (einschließlich abschließendem Schrägstrich, http vs. https, Groß-/Kleinschreibung)
Symptom: Fehler "redirect_uri_mismatch" oder "AADSTS50011: The redirect URI specified in the request does not match"
Lösung: Verwenden Sie die Kopieren-Schaltfläche in Power Pages, fügen Sie den EXAKTEN Wert in IdP ein. Überprüfen Sie abschließenden Schrägstrich, Protokoll (https) und Groß-/Kleinschreibung.
2. Fehlender oder falscher Scope
Problem: Scope enthält nicht openid (obligatorisch) oder email (erforderlich für Kontakt-Mapping)
Symptom: Authentifizierung funktioniert, aber Benutzer haben keine E-Mail-Adresse in Power Pages, Benachrichtigungen können nicht gesendet werden
Lösung: Setzen Sie Scope auf mindestens openid email. Fügen Sie profile hinzu, wenn Sie Vorname/Nachname benötigen.
3. Metadata URL nicht zugänglich
Problem: Metadata URL erfordert Authentifizierung oder befindet sich hinter Firewall/VPN
Symptom: "Unable to retrieve metadata" oder 404/401-Fehler während der Konfiguration
Lösung: Metadata URL muss öffentlich zugänglich sein. Testen Sie, indem Sie sie im Browser öffnen, ohne bei einem Konto angemeldet zu sein.
4. Abgelaufenes Client Secret
Problem: Client Secret ist abgelaufen (typischerweise nach 6-24 Monaten, abhängig von der Konfiguration)
Symptom: Authentifizierung funktionierte zuvor, stoppt plötzlich mit "invalid_client" oder "AADSTS7000222" Fehler
Lösung: Generieren Sie neues Client Secret im IdP, aktualisieren Sie es in Power Pages. Setzen Sie eine Kalender-Erinnerung 30 Tage vor dem nächsten Ablauf.
5. Falscher Response Mode
Problem: Verwendung von query oder fragment Response Mode mit code id_token Response Type
Symptom: Tokens erscheinen in der Browser-URL-Leiste (Sicherheitsrisiko) oder Fehler über Response Mode Mismatch
Lösung: Verwenden Sie immer form_post Response Mode - es ist die sicherste Option für Power Pages.
OAuth/OIDC Best Practices
Für Identity Provider Administratoren (Entra External ID, Google, Auth0)
App-Registrierungs-Setup
- Eine App-Registrierung pro Power Pages-Website - Isoliert Konfiguration, erleichtert Fehlerbehebung, bessere Sicherheit
- Verwenden Sie beschreibende App-Namen - "Power Pages Production Customer Portal" nicht "App1"
- Dokumentieren Sie alle Einstellungen - Screenshots der App-Registrierungseinstellungen erstellen, in Projektdokumentation speichern
- Konfigurieren Sie mehrere Besitzer - Verlassen Sie sich nicht auf eine einzelne Person für Secret-Rotation
Secret-Verwaltung
- Setzen Sie 6-Monats-Ablauf für Client Secrets - Balance zwischen Sicherheit (Rotation) und operativem Aufwand
- Verwenden Sie beschreibende Secret-Namen mit Ablaufdatum - "Prod Secret (Expires Dec 2025)" nicht "Secret 1"
- Erstellen Sie ZWEI Secrets mit gestaffeltem Ablauf - Ermöglicht Rotation ohne Ausfallzeit (Power Pages auf Secret 2 aktualisieren, dann Secret 1 rotieren)
- Setzen Sie Kalender-Erinnerungen 30 Tage vor Ablauf - Verhindert Notfall-"Authentifizierung ist ausgefallen"-Vorfälle
Claims & Token Konfiguration
- Fügen Sie immer E-Mail-Claim hinzu - Wesentlich für Power Pages Kontakt-Mapping
- Konfigurieren Sie optionale Claims für Profildaten - Aktivieren Sie given_name, family_name in Token-Konfiguration
- Testen Sie Tokens in jwt.io - Dekodieren Sie ID Tokens, um Claims zu überprüfen, bevor Sie in Power Pages testen
- Konfigurieren Sie Gruppen-Claims für Rollen-Mapping - Verwenden Sie Gruppen, um automatisch Power Pages-Rollen zuzuweisen
- Behalten Sie Token-Lebensdauer bei Standard 1 Stunde - Nicht verlängern, um Sicherheitsrisiken zu vermeiden
Für Power Pages Administratoren
Konfiguration & Testen
- Testen Sie immer im Inkognito-/Privat-Modus - Erfasst Cookie- und Cache-Probleme
- Aktivieren Sie Diagnoseprotokollierung VOR dem Testen - Protokolle zeigen exakte OAuth-Fehler mit Fehlercodes
- Testen Sie mit Nicht-Admin-Konten - Admin-Tokens haben andere Claims, nicht repräsentativ für Endbenutzer
- Testen Sie auf verschiedenen Geräten - Desktop Chrome, mobile Safari, Edge - OAuth verhält sich unterschiedlich
- Überprüfen Sie, dass E-Mail-Claim im Kontaktdatensatz ankommt - Kontaktdatensatz nach erster Anmeldung prüfen
Claims Mapping
- Konfigurieren Sie Registration Claims Mapping -
firstname=given_name,lastname=family_name - Verwenden Sie das gleiche Mapping für Login Claims Mapping - Hält Kontaktdaten bei jeder Anmeldung mit IdP synchron
- Mappen Sie keine Felder, die Benutzer nicht ändern können - Mapping von Berufsbezeichnung, wenn Benutzer sie nicht aktualisieren können, führt zu Verwirrung
- Testen Sie Claims Mapping mit echtem Benutzerkonto - Überprüfen Sie, dass gemappte Felder korrekt im Kontaktdatensatz erscheinen
Session-Verwaltung
- Verstehen Sie Standard-8-Stunden-Session - Power Pages Session != Token-Ablauf (Token läuft nach 1 Stunde ab, Session läuft weiter)
- Erwägen Sie Use Token Lifetime für Hochsicherheits-Portale - Erzwingt erneute Authentifizierung, wenn Token abläuft
- Testen Sie Session-Ablauf-Verhalten - Was passiert nach 8 Stunden? Erhält der Benutzer eine klare Fehlermeldung?
- Klären Sie Benutzer über IdP-Session vs. Power Pages-Session auf - Abmelden vom Portal meldet nicht vom IdP ab
Für Berater & Entwickler
Fehlerbehebungs-Workflow
- Schritt 1: Redirect URL überprüfen - 80% der OAuth-Probleme sind Redirect URL Mismatch
- Schritt 2: Metadata URL Erreichbarkeit prüfen - Im Browser öffnen, sollte JSON ohne Authentifizierung zurückgeben
- Schritt 3: Client ID und Secret überprüfen - Aus IdP kopieren und einfügen, nicht auf Gedächtnis verlassen
- Schritt 4: Scope-Konfiguration prüfen - Muss mindestens
openidenthalten - Schritt 5: Power Pages Diagnoseprotokolle prüfen - Nach spezifischen Fehlercodes suchen (AADSTS*, invalid_client, etc.)
- Schritt 6: Browser DevTools Network-Tab verwenden - OAuth-Flow beobachten: Autorisierungsanfrage → Redirect → Token-Austausch
Häufige Fehlercodes
- AADSTS50011 - Redirect URI mismatch → Exakte URL in IdP vs. Power Pages prüfen
- AADSTS7000222 - Invalid client secret → Neues Secret generieren, Power Pages aktualisieren
- AADSTS50105 - User not assigned to app → Benutzer zur App-Zuweisung in IdP hinzufügen
- invalid_request - Missing required parameter → Scope, Client ID, Response Type prüfen
- unauthorized_client - Client not authorized → App-Registrierungseinstellungen, Zustimmungsanforderungen prüfen
Projekt-Auslieferung
- Screenshot von JEDEM funktionierenden Konfigurationsbildschirm - Client ID, Authority, Scopes, Claims Mapping
- Client Secret Rotationsprozess dokumentieren - Wer macht es, wie oft, was ist der Prozess
- Fehler-Runbook erstellen - Während des Testens aufgetretene Fehler mit Lösungen dokumentieren
- Benutzerdokumentation bereitstellen - Erklären, warum Benutzer zustimmen müssen, wie Abmeldung funktioniert, Session-Timeout
Single Sign-On (SSO) mit OAuth/OpenID Connect
Schnelle Antwort: Ja! OAuth 2.0 und OpenID Connect ermöglichen SSO über mehrere Anwendungen hinweg.
Wie SSO funktioniert
Die Konzert-Armband-Analogie
Stellen Sie sich ein Musikfestival mit mehreren Bühnen (Anwendungen) vor:
- Eingangstor prüft Ihr Ticket und gibt Ihnen ein Armband
- Bühne 1 (App 1) sieht Ihr Armband → "Sie sind drin!"
- Bühne 2 (App 2) sieht dasselbe Armband → "Sie sind auch hier drin!"
- Kein erneutes Zeigen des Tickets an jeder Bühne erforderlich
Dieses Armband = Ihr Access Token vom Identity Provider.
Was Power Pages unterstützt
- ✅ Single Sign-In - Einmal anmelden, auf mehrere Power Pages-Sites zugreifen (wenn sie denselben IdP verwenden)
- ✅ Anwendungsübergreifendes SSO - Funktioniert mit anderen Apps, die denselben Identity Provider verwenden
- ✅ Front-Channel Sign-Out - Meldet Sie sowohl von Power Pages ALS AUCH vom IdP ab
Was Power Pages nicht unterstützt
- ❌ Single Sign-Out - Das Abmelden von einer App meldet Sie nicht automatisch von allen Apps ab
- ❌ Provider-übergreifendes SSO - Sitzungen können nicht zwischen Google- und Microsoft-Anmeldungen geteilt werden
Reale SSO-Szenarien
Szenario 1: Mitarbeiterportal + Intranet
Setup: Beide verwenden Microsoft Entra External ID
Ergebnis:
- ✅ Mitarbeiter meldet sich bei SharePoint an → Erhält Token von Entra External ID
- ✅ Mitarbeiter besucht Power Pages-Portal → Derselbe Token funktioniert!
- ✅ Keine zweite Anmeldung erforderlich ✅
Szenario 2: Kundenportal + Support-App
Setup: Beide verwenden Okta
Ergebnis:
- ✅ Kunde meldet sich bei Support-App an → Erhält Okta-Token
- ✅ Kunde klickt auf Link zum Power Pages-Portal → Automatisch angemeldet!
- ✅ Nahtlose Erfahrung ✅
Was bricht SSO?
- ❌ Unterschiedliche Identity Provider - Portal verwendet Google, App verwendet Microsoft (Sitzungen werden nicht geteilt)
- ❌ Token abgelaufen - Token halten typischerweise 1 Stunde, dann müssen Sie sich erneut authentifizieren
- ❌ Unterschiedliche Domains - Cookies überschreiten keine Domain-Grenzen (verwenden Sie wenn möglich dieselbe Parent-Domain)
- ❌ Inkognito-/Privater Modus - Keine Cookies = kein SSO
SSO einrichten
Schritt 1: Überall denselben Identity Provider verwenden
- • Alle Apps → Microsoft Entra External ID, ODER
- • Alle Apps → Okta, ODER
- • Alle Apps → Google
Schritt 2: Apps im IdP konfigurieren
- • Jede App registrieren (Power Pages, SharePoint, Custom Apps)
- • Denselben Tenant/Organisation verwenden
- • Korrekte Redirect-URLs für jede App konfigurieren
Schritt 3: Den Flow testen
- • Bei App 1 anmelden → Token erhalten
- • App 2 im selben Browser öffnen → Sollte automatisch anmelden
- • Prüfen: Keine zweite Passwort-Abfrage = SSO funktioniert! ✅
SSO Token-Lebensdauer
| Token-Typ | Typische Lebensdauer | Was danach passiert |
|---|---|---|
| ID Token | 1 Stunde | Muss erneuert werden (normalerweise stillschweigend) |
| Access Token | 1 Stunde | Muss mit Refresh Token erneuert werden |
| Refresh Token | 90 Tage (Microsoft) | Erneute Anmeldung erforderlich |
| Power Pages Session | 8 Stunden (konfigurierbar) | Weiterleitung zur Anmeldeseite |
Pro-Tipp: Stillschweigende Token-Erneuerung
OAuth/OpenID Connect-Provider können Token stillschweigend im Hintergrund erneuern, indem sie Refresh Tokens verwenden. Das bedeutet:
- ✅ Die Sitzung des Benutzers bleibt aktiv ohne erneute Anmeldung
- ✅ Geschieht automatisch bevor der Token abläuft
- ✅ Der Benutzer bemerkt nichts ✅
Power Pages macht dies automatisch. Sie müssen nichts Besonderes konfigurieren.
Wenn SSO nicht funktioniert
Problem: "Ich habe mich bei App A angemeldet, muss mich aber trotzdem bei Power Pages anmelden"
Checkliste:
- ☐ Derselbe Identity Provider? (Beide müssen Entra External ID verwenden, nicht ein Entra + ein Google)
- ☐ Derselbe Tenant? (Beide müssen im selben Entra External ID-Tenant sein)
- ☐ Derselbe Browser? (SSO funktioniert nicht über verschiedene Browser hinweg)
- ☐ Cookies aktiviert? (SSO benötigt Cookies)
- ☐ Token noch gültig? (Prüfen, ob abgelaufen)
SSO Best Practices
- ✅ Halten Sie es einfach - Ein IdP für alle Apps (keine Mischung aus Google + Microsoft + Okta)
- ✅ Kommunizieren Sie Sitzungslimits - Informieren Sie Benutzer: "Sitzung läuft in 8 Stunden ab"
- ✅ Implementieren Sie "Angemeldet bleiben" - Längerer Refresh Token = weniger erneute Anmeldungen
- ✅ Testen Sie über Apps hinweg - Stellen Sie sicher, dass SSO vor dem Launch tatsächlich funktioniert
- ✅ Dokumentieren Sie den Flow - Damit der Support weiß, was zu erwarten ist
SAML 2.0 Deep Dive
Häufige Identity Provider: Okta, Microsoft Entra ID (Enterprise Apps), Azure AD B2C (mit Custom Policies), Ping Identity, OneLogin, Shibboleth
Protokoll-Flow: SP-initiierter SAML-Flow (Power Pages leitet Benutzer zur Authentifizierung zum IdP weiter)
Reale Analogie: Das Botschafts-Visa-System
Stellen Sie sich vor, Sie möchten in ein fremdes Land (Power Pages) einreisen, das ein Visum erfordert. Sie können nicht einfach auftauchen - Sie benötigen einen Nachweis von der Botschaft Ihres Heimatlandes (Identity Provider), dass Sie berechtigt sind.
- 1. Sie kommen an der Grenze an (Power Pages-Anmeldeseite)
- 2. Grenzbeamter sagt: "Sie benötigen ein Visum von Ihrer Botschaft" und gibt Ihnen ein offizielles Formular (SAML Request)
- 3. Sie bringen das Formular zu Ihrer Botschaft (IdP-Anmeldeseite)
- 4. Botschaftspersonal überprüft Ihre Identität (prüft Ihren Reisepass, stellt Sicherheitsfragen)
- 5. Botschaft stempelt Ihr Visums-Antragsformular (SAML Assertion) mit einem offiziellen Siegel
- 6. Sie kehren mit dem gestempelten Formular zur Grenze zurück
- 7. Grenzbeamter überprüft das Botschaftssiegel (XML-Signatur-Validierung), prüft ob es authentisch ist → "Willkommen!"
Warum dies funktioniert: Der Grenzbeamte vertraut dem Botschaftssiegel (beide haben sich vorher auf Sicherheitszertifikate geeinigt). Das Botschaftssiegel ist manipulationssicher (digitale XML-Signatur). Das Visum hat eine Ablaufzeit (NotOnOrAfter). Das Visum gilt für diese spezifische Person (NameID stimmt überein).
Technischer Flow: SP-initiiertes SAML 2.0 (Schritt für Schritt)
Phase 1: Benutzer initiiert Anmeldung (Service Provider Initiated)
Schritt 1: Benutzer klickt auf "Mit Okta anmelden" (oder Ihrem SAML-Provider) in Power Pages
💡 Wie das Ankommen am Grenzkontrollpunkt
Phase 2: SAML Authentication Request (AuthnRequest)
Schritt 2: Power Pages generiert einen SAML AuthnRequest (XML-Dokument) mit folgendem Inhalt:
- •
Issuer- Service Provider Realm (Ihre Site-Kennung) - •
AssertionConsumerServiceURL- Wohin die Antwort gesendet werden soll - •
ID- Eindeutige Request-ID (verhindert Replay-Angriffe) - •
IssueInstant- Zeitstempel der Request-Erstellung
Beispiel SAML Request:
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="_abcd1234"
Version="2.0"
IssueInstant="2025-11-06T10:30:00Z"
Destination="https://idp.example.com/saml/sso"
AssertionConsumerServiceURL="https://yoursite.powerappsportals.com/signin-saml2">
<saml:Issuer>https://yoursite.powerappsportals.com/</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
</samlp:AuthnRequest>💡 Wie der Grenzbeamte, der Ihnen ein offizielles Formular gibt, das Sie zur Botschaft bringen sollen
Schritt 3: Power Pages kodiert den XML-Request (Base64), komprimiert ihn optional (Deflate) und leitet den Browser zum IdP weiter:
https://idp.example.com/saml/sso?SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdC...
💡 Wie der Weg zur Botschaft mit dem Formular
Phase 3: Benutzer-Authentifizierung beim IdP
Schritt 4: IdP dekodiert und validiert den SAML Request
- ✅ Prüft, ob Issuer ein bekannter Service Provider ist
- ✅ Validiert, dass IssueInstant nicht zu alt ist
- ✅ Prüft, ob AssertionConsumerServiceURL registriert ist
Schritt 5: IdP zeigt dem Benutzer die Anmeldeseite
Schritt 6: Benutzer gibt Anmeldedaten ein (Benutzername/Passwort, MFA, etc.)
Schritt 7: IdP validiert die Anmeldedaten
💡 Wie das Botschaftspersonal, das Ihren Reisepass prüft und Sicherheitsfragen stellt
Phase 4: SAML Response (Assertion)-Generierung
Schritt 8: IdP erstellt eine SAML Assertion (XML) mit folgendem Inhalt:
- •
Issuer- EntityID des IdP - •
Subject/NameID- Eindeutige Benutzerkennung (E-Mail, UPN, etc.) - •
Conditions- Audience (muss Service Provider Realm entsprechen), NotBefore, NotOnOrAfter-Zeitstempel - •
AttributeStatement- Benutzer-Claims (E-Mail, Vorname, Nachname, Rollen) - •
AuthnStatement- Wann/wie sich der Benutzer authentifiziert hat
Beispiel SAML Assertion:
<saml:Assertion ID="_xyz5678" IssueInstant="2025-11-06T10:31:00Z">
<saml:Issuer>https://idp.example.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="email">john.doe@company.com</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore="2025-11-06T10:30:00Z" NotOnOrAfter="2025-11-06T11:31:00Z">
<saml:AudienceRestriction>
<saml:Audience>https://yoursite.powerappsportals.com/</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AttributeStatement>
<saml:Attribute Name="email"><saml:AttributeValue>john.doe@company.com</saml:AttributeValue></saml:Attribute>
<saml:Attribute Name="firstname"><saml:AttributeValue>John</saml:AttributeValue></saml:Attribute>
</saml:AttributeStatement>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
</saml:Assertion>Schritt 9: IdP signiert die XML-Assertion mit seinem privaten Schlüssel (X.509-Zertifikat)
💡 Wie die Botschaft, die das Visums-Formular stempelt und versiegelt
Phase 5: POST Assertion zurück zum Service Provider
Schritt 10: IdP Base64-kodiert die signierte SAML Response
Schritt 11: IdP sendet ein sich automatisch absendendes HTML-Formular an den Browser (HTTP POST Binding):
<form method="POST" action="https://yoursite.powerappsportals.com/signin-saml2">
<input type="hidden" name="SAMLResponse" value="PD94bWwgdmVyc2lvbj0iMS4w..." />
<input type="submit" value="Continue" />
</form>
<script>document.forms[0].submit();</script>Schritt 12: Browser sendet automatisch POST an die Power Pages ACS-URL
💡 Wie die Rückkehr zur Grenze mit dem gestempelten Visum
Phase 6: Assertion-Validierung & Session-Erstellung
Schritt 13: Power Pages dekodiert die SAML Response
Schritt 14: Power Pages validiert die Assertion:
- ✅ Signatur gültig: Verwendet den öffentlichen Schlüssel des IdP (aus Metadata), um die XML-Signatur zu verifizieren
- ✅ Issuer stimmt überein: Assertion Issuer = Authentication Type (entityID)
- ✅ Audience stimmt überein: Audience = Service Provider Realm
- ✅ Nicht abgelaufen: Aktuelle Zeit zwischen NotBefore und NotOnOrAfter
- ✅ Nicht wiederholt verwendet: Assertion-ID wurde noch nicht verwendet (im Cache gespeichert)
💡 Wie der Grenzbeamte prüft: Botschaftssiegel authentisch? Visum für dieses Land? Nicht abgelaufen? Noch nicht verwendet?
Schritt 15: Benutzer-Attribute aus AttributeStatement extrahieren (E-Mail, Name, etc.)
Schritt 16: Kontakt-Datensatz in Dataverse mit NameID und Attributen erstellen oder aktualisieren
Schritt 17: Power Pages Session-Cookie erstellen
Schritt 18: Benutzer zur ursprünglich angeforderten Seite weiterleiten
💡 Wie schließlich die Erlaubnis zu erhalten, die Grenze zu überqueren
Wichtige SAML-Unterschiede zu OAuth/OIDC
1. XML statt JSON: SAML verwendet ausführliche XML-Dokumente. OAuth/OIDC verwendet kompakte JSON-Token.
2. Signaturen auf XML: SAML signiert die gesamte XML-Assertion. OAuth signiert JWT-Token mit einfacherer Base64-Kodierung.
3. Kein Backend-Token-Austausch: SAML-Assertion wird direkt per POST an den Browser gesendet (aber sie ist signiert, daher trotzdem sicher). OAuth hat einen Backend Code-for-Tokens-Austausch.
4. Zertifikat-basiertes Vertrauen: SAML erfordert den vorherigen Austausch von X.509-Zertifikaten. OAuth verwendet Metadata Discovery-URLs.
5. Enterprise-fokussiert: SAML ist älter (2005) und verbreitet in Enterprise/B2B-Szenarien. OAuth/OIDC ist neuer (2012/2014) und moderner.
Visuelles Flow-Diagramm
(Service Provider) participant IdP as Identity Provider
(Okta/Entra ID) User->>Browser: 1. Navigate to portal Browser->>PP: 2. Request protected page PP->>Browser: 3. Redirect to login page rect rgb(200, 220, 255) Note over User,Browser: User initiates login User->>Browser: 4. Click "Sign in with Okta" end rect rgb(255, 220, 200) Note over PP,IdP: SAML Authentication Request (AuthnRequest) Browser->>PP: 5. POST /signin-saml2 PP->>PP: 6. Generate SAML AuthnRequest XML
(Issuer, ACS URL, ID, Timestamp) PP->>Browser: 7. HTTP 302 Redirect with encoded SAML Request Browser->>IdP: 8. GET /sso?SAMLRequest=... end rect rgb(200, 255, 220) Note over User,IdP: User Authentication Phase IdP->>IdP: 9. Decode & validate SAML Request IdP->>Browser: 10. Show login page User->>Browser: 11. Enter username/password Browser->>IdP: 12. POST credentials IdP->>IdP: 13. Validate credentials end rect rgb(255, 255, 200) Note over IdP,PP: SAML Response (Assertion) Generation IdP->>IdP: 14. Create SAML Assertion XML
(Issuer, NameID, Attributes, Conditions) IdP->>IdP: 15. Sign XML with X.509 certificate IdP->>Browser: 16. Auto-submit HTML form with SAMLResponse Browser->>PP: 17. POST /signin-saml2 with SAMLResponse end rect rgb(220, 200, 255) Note over PP: Assertion Validation & Session Creation PP->>PP: 18. Decode SAML Response PP->>PP: 19. Validate XML signature (using IdP public key) PP->>PP: 20. Check Issuer, Audience, NotBefore, NotOnOrAfter PP->>PP: 21. Extract NameID & Attributes PP->>PP: 22. Create/update user in Dataverse PP->>PP: 23. Create session cookie end PP->>Browser: 24. Set-Cookie + Redirect to original page Browser->>PP: 25. Request original page with cookie PP->>Browser: 26. Return protected content Browser->>User: 27. Display page
💡 Diagramm-Legende: Beachten Sie, wie SAML XML (nicht JSON) verwendet und die gesamte Assertion signiert, anstatt einen Backend-Token-Austausch wie OAuth zu verwenden.
Erforderliche Parameter
Diese Parameter müssen konfiguriert werden, damit die SAML-Authentifizierung funktioniert:
| Parameter | Beschreibung | Beispielwert |
|---|---|---|
| Provider NameERFORDERLICH | Der Text, der auf dem Anmelde-Button angezeigt wird | "Mit Okta anmelden" "Mit Firmen-SSO anmelden" |
| Metadata AddressERFORDERLICH | Die SAML 2.0 Federation Metadata-Dokument-URL. Dieses XML-Dokument enthält alle SAML-Endpunkte, Zertifikate und unterstützten Features. Power Pages analysiert dies automatisch, um die SAML-Kommunikation zu konfigurieren. | https://login.microsoftonline.com/{tenant-id}/federationmetadata/2007-06/federationmetadata.xml (Entra ID)https://yourorg.okta.com/app/{app-id}/sso/saml/metadata (Okta) |
| Authentication TypeERFORDERLICH | Der entityID-Wert aus dem SAML-Metadata-Dokument. Dieser identifiziert den Identity Provider eindeutig. Sie finden diesen, indem Sie die Metadata Address-URL in einem Browser öffnen und den <entityID>-Tag-Wert aus dem root <EntityDescriptor>-Element kopieren. |
https://sts.windows.net/{tenant-id}/ (Entra ID)http://www.okta.com/{externalKey} (Okta) |
| Service Provider RealmERFORDERLICH | Die App-ID-URI aus Ihrer IdP-App-Registrierung. Diese identifiziert Ihre Power Pages-Site beim IdP (auch Audience in SAML-Begriffen genannt). Muss genau mit dem übereinstimmen, was Sie im IdP als SP Entity ID oder Audience konfiguriert haben. | https://yoursite.powerappsportals.com/api://{app-id} (bei Verwendung der automatisch generierten Entra ID-URI) |
| Assertion Consumer Service URLERFORDERLICH | Die Power Pages Callback-URL, an die der IdP SAML-Assertions nach der Authentifizierung sendet (auch ACS-URL genannt). Wird automatisch von Power Pages generiert. Bei Custom Domains diesen Wert aktualisieren. Muss mit der im IdP konfigurierten ACS-URL oder Reply-URL übereinstimmen. | https://yoursite.powerappsportals.com/signin-saml2https://customdomain.com/signin-saml2 |
Optionale / Erweiterte Parameter
| Parameter | Beschreibung | Standard / Anwendungsfall |
|---|---|---|
| Validate AudienceOPTIONAL | Aktiviert die Audience-Validierung während der SAML-Assertion-Validierung. Wenn aktiviert, prüft Power Pages, dass das Audience-Element in der SAML-Assertion einem Ihrer Valid Audiences-Werte entspricht. Dies verhindert Assertion Replay-Angriffe. |
Off (Standard) Produktions-Empfehlung: Für Sicherheit aktivieren |
| Valid AudiencesOPTIONAL | Kommagetrennte Liste erlaubter Audience-Werte. Nur SAML-Assertions mit diesen Audience-Werten werden akzeptiert. Sollte mit Ihrem Service Provider Realm übereinstimmen. | https://yoursite.powerappsportals.com/https://site1.powerappsportals.com/,https://site2.powerappsportals.com/Requires: Validate Audience = On |
| Contact Mapping with EmailOPTIONAL | Verknüpft IdP-Identität automatisch mit Dataverse-Kontakt basierend auf E-Mail-Adress-Übereinstimmung. On: Mit bestehendem Kontakt verknüpfen, wenn E-Mail übereinstimmt Off: Immer neuen Kontakt für jede neue SAML-Identität erstellen |
On (Standard - empfohlen) Wichtig: Stellen Sie sicher, dass der IdP den E-Mail-Claim in der SAML-Assertion sendet (NameID oder E-Mail-Attribut) |
So finden Sie die entityID (Authentication Type)
- Kopieren Sie die Metadata Address-URL von Ihrem IdP
- Fügen Sie sie in einen Webbrowser ein
- Sie sehen ein XML-Dokument
- Suchen Sie nach dem
<EntityDescriptor entityID="...">-Tag oben - Kopieren Sie den
entityID-Wert - das ist Ihr Authentication Type
Beispiel: In <EntityDescriptor entityID="https://sts.windows.net/abc123/"> ist die entityID https://sts.windows.net/abc123/
SAML 2.0 Empfehlungen und ❌ Fehler
EMPFOHLEN - SAML Best Practices
- ✅ Metadata-URL auf Erreichbarkeit prüfen - Im Browser öffnen: sollte XML ohne Authentifizierung zurückgeben
- ✅ entityID exakt aus der Metadata kopieren - Inklusive Protokoll (http vs. https), abschließendem Slash und Groß-/Kleinschreibung
- ✅ Service Provider Realm mit IdP-Konfiguration abgleichen - Muss exakt dem im IdP konfigurierten SP-Entity-ID entsprechen
- ✅ Name-ID-Format im IdP konfigurieren - Das Format „Persistent" oder „Email" funktioniert für Power Pages am besten
- ✅ E-Mail-Claim in der SAML-Assertion senden - Entweder als NameID oder als separaten E-Mail-Attribut-Claim
- ✅ Assertion mit SAML-Decoder-Tool testen - Browser-Extension verwenden, um SAML-Response zu decodieren und Claims zu prüfen
- ✅ „Validate Audience" in der Produktion aktivieren - Verhindert Assertion-Replay-Angriffe
- ✅ SHA-256-Signaturalgorithmus verwenden - SHA-1 ist veraltet und wird möglicherweise abgelehnt
- ✅ Assertion-Ablaufzeit angemessen konfigurieren - 5–10 Minuten ist typisch: nicht zu kurz (Clock Skew) und nicht zu lang (Sicherheit)
- ✅ Zertifikatserneuerungsprozess dokumentieren - SAML-Zertifikate laufen ab; Erneuerung rechtzeitig einplanen
VERMEIDEN - SAML-Fallstricke
- ❌ Service Provider Realm und ACS-URL nicht verwechseln - Sie dienen unterschiedlichen Zwecken (WER Sie sind vs. WOHIN die Antwort gesendet wird)
- ❌ Nicht denselben Wert für Realm und ACS-URL verwenden - Häufiger Fehler, verursacht Validierungsfehler
- ❌ entityID nicht manuell eintippen - Exakten Wert aus der Metadata-XML kopieren, inklusive Protokoll und abschließender Zeichen
- ❌ Claim-Regeln im IdP nicht vergessen zu konfigurieren - Power Pages benötigt mindestens den NameID-Claim (E-Mail)
- ❌ SHA-1-Signaturalgorithmus nicht verwenden - Veraltet, kann zu Sicherheitswarnungen oder Ablehnungen führen
- ❌ Zertifikatsablauf nicht ignorieren - SAML-Zertifikate laufen ab (typisch 1–3 Jahre); Erneuerungsprozess einplanen
- ❌ Nur SP-initiiertes Flow testen reicht nicht - Manche IdPs benötigen auch Konfiguration für IdP-initiiertes Flow
- ❌ SAML ≠ OAuth - Unterschiedliche Protokolle, unterschiedliche Konfiguration, unterschiedliche Fehlermeldungen
- ❌ Metadata-Validierung nicht überspringen - Prüfen, ob Metadata SingleSignOnService und Signaturzertifikat enthält
- ❌ Clock-Skew-Toleranz nicht vergessen - Sicherstellen, dass IdP und Power Pages-Server synchronisierte Zeit (NTP) haben
Top 5 SAML-Konfigurationsfehler
1. Verwechslung von Service Provider Realm und ACS-URL
Problem: Denselben Wert für beide Felder verwenden oder die Felder vertauschen
Symptom: SAML-Assertion-Validierungsfehler: „Audience mismatch" oder „Invalid destination"
Lösung: Service Provider Realm = WER Sie sind (Ihre SP-Entity-ID, meist Ihre Website-URL). ACS-URL = WOHIN die Antwort gesendet wird (Callback-Endpunkt mit /signin-saml2). Diese müssen verschieden sein!
2. Falsche entityID (Authentication Type)
Problem: entityID stimmt nicht mit dem Metadata-Dokument überein (Tippfehler, falsches Protokoll, fehlender abschließender Slash)
Symptom: Fehler „Unknown issuer" oder „Issuer mismatch"
Lösung: Metadata-URL im Browser öffnen, <EntityDescriptor entityID="..."> finden, EXAKTEN Wert kopieren. http vs. https und abschließenden Slash prüfen.
3. Fehlender E-Mail-Claim
Problem: IdP sendet keinen E-Mail-Claim in der SAML-Assertion oder sendet ihn in einem unerwarteten Format
Symptom: Benutzer können sich authentifizieren, aber der Kontaktdatensatz hat keine E-Mail-Adresse – oder Authentifizierung gelingt, Benutzer kann aber nicht zugeordnet werden
Lösung: IdP so konfigurieren, dass E-Mail als NameID (Format: EmailAddress oder Persistent) oder als separater http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress-Claim gesendet wird. Mit SAML-Decoder prüfen.
4. Metadata-URL nicht erreichbar
Problem: Metadata-URL erfordert Authentifizierung, liegt hinter einer Firewall oder gibt HTML statt XML zurück
Symptom: Fehler „Unable to retrieve metadata" oder „Invalid metadata document"
Lösung: Metadata muss eine öffentlich zugängliche URL sein, die gültiges XML zurückgibt. Im Browser ohne Authentifizierung testen. Bei On-Premises-IdPs sicherstellen, dass die URL aus dem Internet erreichbar ist.
5. Clock-Skew-Probleme
Problem: Zeitunterschied zwischen IdP-Server und Power Pages-Dienst führt zu Assertion-Validierungsfehlern
Symptom: Sporadische Fehler „Assertion expired" oder „Assertion not yet valid", besonders bei Benutzern in verschiedenen Zeitzonen
Lösung: Sicherstellen, dass der IdP-Server NTP zur Zeitsynchronisierung verwendet. Assertion-Gültigkeitszeitraum auf 5–10 Minuten konfigurieren (erlaubt etwas Clock Skew). Von verschiedenen Standorten/Zeitzonen testen.
SAML 2.0 Best Practices
Für Identity Provider-Administratoren (Okta, Entra ID, Ping)
SAML-Anwendungs-Setup
- Beschreibende App-Namen verwenden - "Power Pages Customer Portal (Production)" nicht "SAML App 1"
- Single Sign-On URL (ACS URL) korrekt konfigurieren - Muss mit
/signin-saml2enden - SP Entity ID auf Website-URL setzen -
https://yoursite.powerappsportals.com/oder benutzerdefinierte Domain verwenden - Name ID Format konfigurieren - "Persistent" oder "Email" Format für beste Kompatibilität verwenden
- Metadata öffentlich zugänglich machen - Power Pages muss Metadata ohne Authentifizierung abrufen können
Claim-Konfiguration
- E-Mail-Claim immer senden - Als NameID oder als
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddresssenden - Vorname und Nachname senden, falls verfügbar -
givenNameundsurnameAttributnamen verwenden - Erwägen Sie das Senden von Gruppenmitgliedschaften - Kann für Power Pages Rollenzuweisung verwendet werden
- Claims mit SAML-Decoder testen - Browser-Erweiterung oder Online-Tool verwenden, um SAML-Response zu dekodieren, überprüfen, dass alle erwarteten Claims ankommen
Zertifikat-Verwaltung
- SHA-256 Signaturalgorithmus verwenden - SHA-1 ist veraltet
- Kalender-Erinnerungen für Zertifikat-Ablauf setzen - Typischerweise 1-3 Jahre, 60 Tage vor Ablauf prüfen
- Zertifikate ohne Ausfallzeit rotieren - Neues Zertifikat neben altem konfigurieren, Metadata aktualisieren, dann altes entfernen
- Neues Zertifikat in Metadata vor Aktivierung veröffentlichen - Ermöglicht Power Pages, neues Zertifikat vorab zu cachen
Sicherheitseinstellungen
- Assertions signieren, nicht nur Responses - Sicherer, verhindert Assertion-Substitutions-Angriffe
- Assertion-Gültigkeit auf 5-10 Minuten setzen - Balance zwischen Zeitversatz-Toleranz und Sicherheit
- Nicht mit SHA-1 signieren - SHA-256 oder höher verwenden
- Audience-Einschränkung aktivieren - Begrenzt Assertion auf spezifischen SP (Ihre Power Pages-Website)
Für Power Pages Administratoren
Konfiguration & Testen
- Kopieren Sie Assertion Consumer Service URL aus Power Pages - Nicht manuell eingeben, Kopieren-Schaltfläche verwenden
- Überprüfen Sie, dass Service Provider Realm mit IdP-Konfiguration übereinstimmt - Muss exakt übereinstimmen (Groß-/Kleinschreibung, abschließender Schrägstrich relevant)
- Testen Sie Metadata URL vor der Konfiguration - Im Browser öffnen, sollte XML-Dokument zurückgeben
- Kopieren Sie entityID aus Metadata XML - Nicht raten, exakten Wert aus
<EntityDescriptor>kopieren - Aktivieren Sie Diagnoseprotokollierung vor dem Testen - SAML-Fehler sind ausführlich, Protokolle sind essenziell für Debugging
- Verwenden Sie SAML-Decoder-Browser-Erweiterung - SAML-Response dekodieren, um genau zu sehen, was IdP sendet
Fehlerbehebungs-Werkzeuge
- Browser-Erweiterung: SAML-tracer oder SAML DevTools - Erfasst und dekodiert SAML-Anfragen/-Antworten
- Online SAML-Decoder - samltool.com zum Dekodieren von Assertions
- Power Pages Diagnoseprotokolle - Enthält vollständige SAML-Assertion-Validierungsfehler
- IdP-Anmeldeprotokolle - Prüfen, ob Authentifizierung bei IdP erfolgreich ist, bevor SAML-Response gesendet wird
Produktionsbereitschaft
- Aktivieren Sie Validate Audience - Setzen Sie Valid Audiences auf Ihren Service Provider Realm Wert
- Dokumentieren Sie Zertifikat-Ablaufdatum - Zu Projektdokumentation hinzufügen, Kalender-Erinnerungen setzen
- Testen Sie aus mehreren Netzwerken - Unternehmens-VPN, Heiminternet, Mobil - Erreichbarkeit sicherstellen
- Überprüfen Sie, dass Contact Mapping with Email aktiviert ist - Verhindert doppelte Kontakterstellung
Für Berater & Entwickler
SAML Fehlerbehebungs-Checkliste
- Schritt 1: Metadata-Erreichbarkeit überprüfen - Metadata URL im Browser öffnen, sollte XML zurückgeben
- Schritt 2: entityID-Übereinstimmung prüfen - Authentication Type in Power Pages mit
<EntityDescriptor entityID>in Metadata vergleichen - Schritt 3: Service Provider Realm mit IdP abgleichen - Muss mit SP Entity ID übereinstimmen, die im IdP konfiguriert ist
- Schritt 4: ACS URL auf Korrektheit prüfen - Muss mit
/signin-saml2enden und mit IdP-Konfiguration übereinstimmen - Schritt 5: SAML-Decoder verwenden - SAML-Response erfassen, dekodieren, Claims überprüfen (E-Mail, Name, etc.)
- Schritt 6: Power Pages Diagnoseprotokolle prüfen - Nach spezifischen SAML-Validierungsfehlern suchen
- Schritt 7: Zertifikat-Gültigkeit überprüfen - Ablaufdatum prüfen, Signaturalgorithmus (sollte SHA-256+ sein)
Häufige SAML-Fehlermeldungen
- "Unknown issuer" → entityID (Authentication Type) stimmt nicht mit dem in Assertion überein
- "Audience mismatch" → Service Provider Realm stimmt nicht mit Audience in Assertion überein, oder Validate Audience ist Ein, aber Valid Audiences ist falsch
- "Invalid destination" → ACS URL in Assertion stimmt nicht mit konfigurierter Assertion Consumer Service URL überein
- "Assertion expired" → Zeitversatz zwischen IdP und Power Pages, oder Assertion-Gültigkeitsdauer zu kurz
- "Signature validation failed" → Zertifikat-Mismatch, abgelaufenes Zertifikat oder falscher Signaturalgorithmus
- "Missing NameID" → IdP sendet keinen NameID Claim, Claim-Regeln im IdP prüfen
Projekt-Dokumentation
- Screenshot der IdP SAML-Konfiguration - SP Entity ID, ACS URL, NameID-Format, Claim-Regeln
- Metadata URL und entityID speichern - Essenziell für Fehlerbehebung
- Zertifikat-Ablaufprozess dokumentieren - Wer erneuert, wie oft, Benachrichtigungsprozess
- SAML-Fehler-Runbook erstellen - Während des Testens aufgetretene Fehler mit Lösungen dokumentieren
- Benutzerdokumentation bereitstellen - SAML-Login-Flow erklären, was passiert, wenn Zertifikat abläuft, Support-Kontakt
Session-Sicherheit Deep Dive
Die entscheidende Frage: „Wenn der Session-Cookie der Schlüssel zum Zugang ist – kann ich ihn einfach kopieren und mich damit auf einem anderen Gerät authentifizieren?"
Die kurze Antwort
Technisch gesehen: Ja, man könnte den Cookie kopieren und damit Zugang erhalten.
In der Praxis: Power Pages implementiert Sicherheitsmaßnahmen, die das deutlich erschweren (aber nicht unmöglich machen).
Warum das wichtig ist
Session-Hijacking (Cookie-Diebstahl) ist ein reales Sicherheitsproblem. Erhält ein Angreifer Ihren Session-Cookie, kann er sich als Sie ausgeben, bis der Cookie abläuft.
Das Risiko: Ein Angreifer mit Ihrem Cookie braucht Ihr Passwort nicht. Er ist bereits „drin".
Sicherheitsmaßnahmen in Power Pages Session-Cookies
Power Pages Session-Cookies verfügen über folgende eingebaute Schutzmaßnahmen:
| Security-Flag | Funktion | Verhinderte Angriffart |
|---|---|---|
| HttpOnly ✅ | JavaScript kann den Cookie nicht auslesen | XSS-Angriffe zum Cookie-Diebstahl |
| Secure ✅ | Cookie wird nur über HTTPS übertragen | Netzwerkabhörangriffe auf unverschlüsselten Verbindungen |
| SameSite ✅ | Cookie wird nicht von anderen Domains gesendet | CSRF-Angriffe (Cross-Site Request Forgery) |
| Kurze Ablaufzeit ✅ | Cookie läuft nach 8 Stunden ab (typisch) | Begrenzt das Missbrauchsfenster bei Cookie-Diebstahl |
Was Power Pages NICHT prüft (standardmäßig)
- ❌ IP-Adresse – Cookie funktioniert von jeder IP-Adresse
- ❌ User Agent – Cookie funktioniert in jedem Browser
- ❌ Gerätefingerabdruck – Keine Gerätebindung
- ❌ Geolokalisierung – Keine Standortvalidierung
Das bedeutet: Erhält ein Angreifer Ihren Cookie, kann er ihn von einem anderen Gerät und Standort aus nutzen, bis er abläuft.
Reale Angriffsszenarien
Szenario 1: Malware auf dem Gerät des Nutzers
Angriff:
- 1. Angreifer installiert Malware auf dem Computer des Nutzers
- 2. Malware liest Browser-Cookies von der Festplatte
- 3. Malware sendet Cookies an den Server des Angreifers
- 4. Angreifer nutzt Cookie auf seinem Gerät → Vollzugriff bis zum Ablauf
Schutzmaßnahmen:
- ✅ Antivirensoftware (Verantwortung des Nutzers)
- ✅ Betriebssystem und Browser aktuell halten
- ✅ Kurzes Session-Timeout (Admin-Kontrolle)
- ✅ Nutzeraufklärung (keine gemeinsam genutzten Geräte)
Szenario 2: Netzwerkabhören (durch HTTPS abgemildert)
Angriff:
- 1. Nutzer im öffentlichen WLAN ohne HTTPS
- 2. Angreifer zeichnet Netzwerkverkehr auf
- 3. Angreifer extrahiert Session-Cookie
- 4. Angreifer gibt Cookie wieder ab → Session übernommen
Schutzmaßnahmen:
- ✅ Power Pages erzwingt HTTPS (eingebauter Schutz)
- ✅ Secure-Flag auf Cookies (verhindert Übertragung über HTTP)
- ⚠️ Weiterhin angreifbar, wenn Nutzer Zertifikatswarnungen ignoriert
Szenario 3: XSS-Angriff (durch HttpOnly abgemildert)
Angriff:
- 1. Angreifer findet Schwachstelle in eigenem Portal-Skript
- 2. Angreifer injiziert JavaScript:
document.cookie - 3. Skript versucht Session-Cookie auszulesen
- 4. HttpOnly-Flag blockiert den Zugriff ✅
Schutzmaßnahmen:
- ✅ HttpOnly-Flag (eingebaut in Power Pages)
- ✅ Content Security Policy (im Portal konfigurieren)
- ✅ Eingabevalidierung auf allen Formularen
- ✅ Regelmäßige Sicherheitsaudits des eigenen Codes
So minimieren Sie das Risiko
Für Power Pages Administratoren:
1. Kurze Session-Timeouts (z.B. 2-4 Stunden statt 8)
- • Auf Power Pages-Ebene konfiguriert
- • Balance zwischen Sicherheit und Benutzerfreundlichkeit
- • Begrenzt Schadensfenster, falls Cookie gestohlen wird
2. Conditional Access Policies (Entra External ID, erfordert Premium-Lizenz)
- ✅ Einschränkung nach IP-Bereich (z.B. nur Unternehmensnetzwerk)
- ✅ Verdächtige Standorte blockieren (z.B. Länder, in denen Sie nicht tätig sind)
- ✅ Konformes Gerät erforderlich
- ⚠️ Konfigurationskomplexität variiert je nach IdP
3. Session-Aktivität überwachen
- • Diagnoseprotokollierung in Power Pages aktivieren
- • Entra External ID Anmeldeprotokolle regelmäßig überprüfen
- • Nach ungewöhnlichen Mustern suchen (siehe Überwachungsabschnitt unten)
4. Web Application Firewall (WAF) verwenden
- • Azure Front Door oder ähnlich
- • Kann Session-Hijacking-Muster erkennen (z.B. gleiches Cookie von mehreren IPs)
- • Rate Limiting zur Verhinderung von Brute-Force
5. Benutzerdefinierte Session-Validierung implementieren
- • Power Pages Web API oder benutzerdefinierten Code verwenden
- • Auf verdächtiges Verhalten prüfen (z.B. schneller Seitenzugriff)
- • Re-Authentifizierung auslösen, falls erforderlich
Für Endbenutzer:
⚠️ Wichtig: Als Portal-Benutzer haben Sie KEINE Kontrolle über Session-Timeouts oder Sicherheitsrichtlinien. Diese werden vom Identity Provider Administrator und Power Pages Administrator gesteuert.
Was Sie tun KÖNNEN, um sich zu schützen:
- 🚫 Greifen Sie niemals auf sensible Portale auf gemeinsam genutzten/öffentlichen Computern zu
- 🚫 Bleiben Sie nicht unnötig angemeldet (melden Sie sich ab, wenn Sie fertig sind)
- ✅ Halten Sie Browser und OS aktuell (Sicherheitspatches)
- ✅ Verwenden Sie Antivirensoftware
- ✅ Seien Sie vorsichtig bei öffentlichem WLAN (verwenden Sie VPN, wenn möglich)
- ✅ Löschen Sie Browser-Cookies nach Verwendung gemeinsam genutzter Geräte
- ✅ Melden Sie verdächtige Anmelde-Benachrichtigungen sofort
Wenn Sie strengere Sicherheitsmaßnahmen benötigen, kontaktieren Sie Ihren Portal-Administrator.
Cookie-Diebstahl erkennen
Zu überwachende Warnsignale:
| Indikator | Was es bedeutet | Maßnahme |
|---|---|---|
| Gleicher Benutzer, verschiedene IPs gleichzeitig | Möglicher Cookie-Diebstahl | Abmeldung erzwingen, Re-Authentifizierung erforderlich |
| Anmeldung von unmöglichen Standorten | Kann nicht gleichzeitig in USA und China sein (5 Min. Abstand) | Session blockieren, Benutzer benachrichtigen |
| Schnelle Anfragen von einzelner Session | Automatisierter Angriff oder Daten-Scraping | Rate Limit, CAPTCHA oder blockieren |
| User Agent ändert sich plötzlich | Cookie in anderem Browser verwendet | Optional: Re-Authentifizierung bei hoher Sicherheit |
Realitäts-Check: Was Sie tatsächlich überwachen können
Out-of-the-Box (Keine zusätzlichen Tools):
Als Power Pages Administrator:
- ✅ Diagnoseprotokolle (nur Fehler und Ausfälle)
- ❌ KEINE IP-Adressen, User Agents oder Session-Details
- ❌ KEINE Echtzeit-Überwachungsfunktionen
Als Entra External ID Administrator:
- ✅ Anmeldeprotokolle (Azure Portal → Entra External ID → Überwachung → Anmeldeprotokolle)
- ✅ Zeigt: IP, Standort, Gerät, Browser, Erfolg/Fehler
- ⚠️ Erfasst nur LOGIN-Ereignisse, NICHT laufende Session-Aktivität
- ❌ Kann nicht erkennen, ob dasselbe Cookie gleichzeitig von mehreren IPs verwendet wird
Um die oben genannten Warnsignale tatsächlich zu erkennen, benötigen Sie:
| Tool | Was es tut | Kosten |
|---|---|---|
| Azure Application Insights | Power Pages Anfragen, IPs, Sessions verfolgen | Pay-per-use (~€2-5/GB aufgenommen) |
| Azure Monitor + Log Analytics | Anmeldeprotokolle + Power Pages Protokolle korrelieren | Pay-per-use (~€2,50/GB) |
| Microsoft Entra ID Protection | Automatische Risikoerkennung (unmögliches Reisen, etc.) | Premium P2 (~€8-10/Benutzer/Monat) |
| SIEM (z.B. Microsoft Sentinel) | Erweiterte Bedrohungserkennung, benutzerdefinierte Regeln | Enterprise-Preise (~€200+/Monat) |
Fazit: Die Warnsignale-Tabelle zeigt, was Sie überwachen sollten, aber deren Erkennung erfordert zusätzliche Tools und Budget. Für die meisten Power Pages-Implementierungen ist dieses Überwachungsniveau nur für Hochsicherheitsszenarien gerechtfertigt (Finanzdaten, Gesundheitswesen, Admin-Portale).
Was Sie ohne zusätzliche Tools tun können
Praktischer Ansatz für die meisten Projekte:
- 1. Entra External ID Anmeldeprotokolle aktivieren (kostenlos, immer aktiv)
- • Wöchentlich auf ungewöhnliche Anmeldemuster überprüfen
- • Nach Anmeldungen aus unerwarteten Ländern suchen
- • Fehlgeschlagene Anmeldeversuche prüfen (Brute-Force?)
- 2. Power Pages Diagnoseprotokollierung aktivieren (kostenlos)
- • Erfasst Authentifizierungsfehler
- • Hilft beim Debuggen von Anmeldeproblemen
- • Erfasst kein Session-Hijacking, zeigt aber Systemzustand
- 3. Conditional Access implementieren (Entra External ID, erfordert Premium-Lizenz)
- • Anmeldungen nach IP-Bereich einschränken (z.B. nur Unternehmensnetzwerk)
- • Hochrisiko-Länder blockieren
- • Gerätekonformität erforderlich
- • Prävention ist besser (und günstiger) als Erkennung!
- 4. Kurze Session-Timeouts (Power Pages Einstellung, kostenlos)
- • Von 8 Stunden auf 2-4 Stunden reduzieren
- • Begrenzt Schadensfenster, falls Cookie gestohlen wird
- • Keine zusätzlichen Tools erforderlich
- 5. Benutzerschulung (kostenlos!)
- • Benutzer auffordern, sich auf gemeinsam genutzten Geräten abzumelden
- • Vor Phishing-Versuchen warnen
- • Klaren Kontakt für "verdächtige Aktivität melden" bereitstellen
Session-Sicherheits-Vergleich
| Sicherheitsmaßnahme | Power Pages Standard | Zusätzlicher verfügbarer Schutz |
|---|---|---|
| HTTPS-Erzwingung | ✅ Immer aktiv | - |
| HttpOnly Cookies | ✅ Aktiviert | - |
| Secure Flag | ✅ Aktiviert | - |
| SameSite Attribut | ✅ Aktiviert | - |
| IP-Bindung | ❌ Nicht Standard | ⚠️ Über Conditional Access (Entra External ID) |
| Geräte-Bindung | ❌ Nicht verfügbar | ⚠️ Über Conditional Access (Entra External ID) |
| Geolokalisierungs-Prüfungen | ❌ Nicht Standard | ✅ Über Conditional Access (Entra External ID) |
| Zusätzliche Authentifizierungsfaktoren | ❌ Nicht eingebaut | ⚠️ Auf IdP-Ebene konfigurieren (komplexes Setup) |
Das Fazit
Session-Cookies SIND diebstahlgefährdet – das gilt für ALLE Webanwendungen, nicht nur für Power Pages.
Die Verteidigung besteht aus mehreren Schichten:
- 1. Basisschutz (HTTPS, HttpOnly, Secure-Flag) → Eingebaut ✅
- 2. Kurze Session-Timeouts → Begrenzt das Schadensfenster ✅
- 3. Conditional Access → Blockiert verdächtige Aktivitäten ⚠️ (Premium-Lizenz)
- 4. Monitoring & Alerts → Schnell erkennen und reagieren ⚠️ (Zusätzliche Tools erforderlich)
- 5. Benutzerschulung → Unachtsamkeit verhindern ✅ (Kostenlos!)
Keine einzelne Maßnahme ist perfekt – aber zusammen machen sie den Cookie-Diebstahl erheblich schwieriger und weniger lohnend.
Sollten Sie sich Sorgen machen?
Szenarien mit geringem Risiko:
- • Öffentliches Marketing-Portal (keine sensiblen Daten)
- • Internes Portal ausschließlich im Unternehmensnetzwerk
- • Kurze Sessions (2–4 Stunden) mit aktiviertem Conditional Access
Szenarien mit hohem Risiko:
- • Portal mit Finanztransaktionen
- • Zugang zu personenbezogenen Gesundheitsdaten
- • Administrative Funktionen (Benutzerverwaltung, Einstellungen)
- • Öffentlich zugänglich mit sensiblen Daten
Empfehlung: Setzen Sie bei Hochrisiko-Szenarien alle verfügbaren Schutzmaßnahmen ein (kurze Sessions + Conditional Access + Monitoring + WAF). Erwägen Sie zusätzliche Sicherheitsmaßnahmen wie Step-up-Authentifizierung für kritische Vorgänge.
Fazit
Authentifizierung in Power Pages sind im Grunde drei Freunde, die sich Nachrichten übergeben: Sie, Ihr Portal und Microsoft (oder Google, etc.).
Merken Sie sich diese 5 Dinge
- Verwenden Sie OAuth/OpenID Connect - Das ist der moderne Weg. SAML ist für Legacy-Systeme.
- Es geht um Vertrauen - Ihr Portal vertraut Microsofts digitaler Signatur, wie einem Passstempel.
- Sicherheit geschieht in Schritten - Mehrere Weiterleitungen = sicherer (kein Bug!)
- Token haben Ablaufdaten - Normalerweise 1 Stunde. Das ist normal.
- Prüfen Sie, ob Ihre URLs exakt übereinstimmen - Die meisten Auth-Fehler = falsche Redirect-URL
Power Pages Leute vereinigt euch! Lasst euch nicht von diesen Sidekick-Produkten besiegen 😜
Jetzt verstehen Sie, wie die Anmeldung funktioniert. Wenn etwas kaputt geht, wissen Sie, wo Sie suchen müssen.
Social Identity Providers (Schnelle Einrichtung für B2C)
Was sind Social Identity Providers?
Power Pages enthält 5 vorkonfigurierte OAuth 2.0-Provider für Consumer-Authentifizierungsszenarien. Dies sind vereinfachte, assistentenbasierte Alternativen zur generischen OAuth/OIDC-Einrichtung aus dem vorherigen Abschnitt.
Wichtige Einschränkung: Power Pages unterstützt keine anderen OAuth-Provider außer diesen fünf. Verwenden Sie für Custom Provider (wie Auth0, Okta oder Ihren eigenen OAuth-Server) stattdessen die generische OpenID Connect-Konfiguration.
Unterstützte Social Provider
Konfigurationsparameter
Social Identity Provider benötigen nur 2-3 Konfigurationswerte in Power Pages:
https://yoursite.powerappsportals.com/signin-{provider}Beispiele:
•
/signin-google•
/signin-facebook•
/signin-microsoftOptionale zusätzliche Einstellungen
Alle Social Provider teilen diese optionalen erweiterten Einstellungen (erweitern Sie "Zusätzliche Einstellungen" im Power Pages-Assistenten):
email,profile)Social OAuth vs. Generisches OAuth/OIDC
Wann sollten Social Identity Providers verwendet werden?
Verwenden Sie Social OAuth wenn:
Verwenden Sie stattdessen Generisches OAuth/OIDC wenn:
Social IdP Best Practices
Sicherheits- & Datenschutzüberlegungen
email, wenn E-Mail benötigt –profilenicht unnötig anfragen)Häufige Fallstricke mit Social IdPs
Multi-Provider-Setup-Strategie
Viele Portale bieten mehrere Social Login-Optionen an. Hier ist der empfohlene Ansatz: