EntraID

Secret Management und vor allem der Austausch solcher sicherheitsrelevanten Artefakten ist ein schwieriges Thema welches meiner Erfahrung nach auch häufig ziemlich Stiefmütterlich behandelt wird. Gerade in Version Control Systems (VCS) wie zum Beispiel Git findet man viel zu oft ein Secret, welches in einer Applikation für die Single Sign On Anbindung via OpenID Connect (OIDC) verwendet wird. Auch der Austausch von Secrets mit Partner oder Lieferanten erfolgt gerne mal über unsichere Kanäle wie Email, bei dem die Verschlüsselung nicht durchgängig sichergestellt ist. Microsoft Entra ID bietet nebst dem klassischen Secret und einem Zertifikat, welches als asymmetrischer Schlüssel verwendet wird, die Möglichkeit dem OIDC Token eines fremden Identity Providers (IdP) zu vertrauen. Letzteres ist sehr interessant, da es einerseits die Gefahr von leaked Secrets mitigiert und andererseits der Fall nicht eintreffen kann, dass ein Secret oder Zertifikat abläuft und dadurch der Service gestört ist. Zudem ist es, einmal eingerichtet, frei von jeglichem Wartungsaufwand. ...

Microsoft Entra ID bietet mit External Identities die Möglichkeit andere Entra ID Tenants, Social Logins wie auch externe SAML2/WS-Fed Identity Provider anzubinden. Im B2B (Business to Business) Umfeld ist letzteres sehr interessant um mit anderen Firmen gemeinsam an Ressourcen arbeiten zu können, ohne deren Identitäten pflegen zu müssen. Dadurch, dass die andere Firma sich an ihrem eigenen Identity Provider anmeldet gibt es auch für sie einige Vorteile wie zum Beispiel Single Sign On und die Hoheit über die Mover-Joiner-Leaver Prozesse zu behalten....

Neulich kam eine Anfrage vom PowerApps Team zu mir, mit der Bitte den Admin Consent für den Wrap einer ihrer Apps zu erteilen. Das Wrap Feature in Power Apps ermöglicht es eine native App aus einer Canvas-App zu erstellen, welche dann über Microsoft Intune, Microsoft App Center, Google Play Store und Apple Business Manager verteilt werden kann. Da ich die App Registrations und deren API Permissions mit Infrastructure as Code (IaC) erstelle und gleich anschliessend jeweils den Admin Consent erteile, war ich etwas verwundert über die Anfrage....

Gerade in grösseren Umgebungen kann es schnell mal vorkommen, dass ein Account in mehr als 150 (SAML Limit) bzw. 200 (JWT Limit) Gruppen Mitglied ist. Aufgrund des HTTP Header Limits wird der Groups Claim von Microsoft Entra ID speziell behandelt: Configure group claims for applications by using Azure Active Directory – Microsoft Entra | Microsoft Learn. Wenn das Limit überschritten wird, schickt Microsoft Entra ID anstelle der Liste einen Link zum Graph API über den, mit den entsprechenden Berechtigungen, die Gruppenmitgliedschaften abgefragt werden können. Nun hat nicht jede Applikation die Möglichkeit diesen API Aufruf durchzuführen. Lange Zeit war es nur bei SAML Assertions möglich die Gruppen, welche im Claim erscheinen sollen, zu filtern. Dies hat sich im Laufe des Jahres 2023 geändert und dieser Beitrag zeigt auf, wie die Gruppen nun auch für OIDC/OAuth2 Tokens gefiltert werden können. Eine Alternative wäre die Gruppen der Applikation zuweisen und den Groups Claim auf Groups assigned to the application zu stellen. Damit würden nur noch die entsprechend zugewisenen Gruppen im Claim erscheinen, jedoch bedeutet dies ein händisches Verwalten der Gruppenzuweisung. ...