Azure AD Signing Key Rollover

Question

Azure-Anmeldeschlüssel rollen am 15. August 2015 über. Einige meiner Anwendungen sind nicht dafür eingerichtet, dies automatisch zu verarbeiten. Ich dachte, ich eine Lösung hatte die folgende Funktion in Global.asax verwendet

protected void RefreshValidationSettings() 
{ 
    string configPath = AppDomain.CurrentDomain.BaseDirectory + "\\" + "Web.config"; 
    string metadataAddress = ConfigurationManager.AppSettings["ida:FederationMetadataLocation"]; 
    ValidatingIssuerNameRegistry.WriteToConfig(metadataAddress, configPath); 
} 

Dies funktioniert im Debug auf meinem Desktop und neue Schlüssel heruntergeladen und geschrieben meine web.config.

Wenn ich die Seite laden, obwohl ich einen Zugang bekommen zu azur verweigert

Zugriff auf den Pfad ‚E: \ sitesroot \ 0 \ Web.config‘ verweigert wird.

ASP.NET ist nicht berechtigt, auf die angeforderte Ressource zuzugreifen. Berücksichtigen Sie das Gewähren von Zugriffsrechten für die Ressource auf die ASP.NET-Anforderungsidentität. ASP.NET verfügt über eine Basisprozessidentität (normalerweise {MASCHINE} \ ASPNET auf IIS 5 oder Netzwerkdienst auf IIS 6 und IIS 7 und die konfigurierte Anwendungspoolidentität auf IIS 7.5), die verwendet wird, wenn die Anwendung nicht die Identität annimmt. Wenn die Anwendung die Identität annimmt, ist die Identität der anonyme Benutzer (normalerweise IUSR_MACHINENAME) oder der authentifizierte Anforderungsbenutzer.

Um ASP.NET Zugriff auf eine Datei zu gewähren, klicken Sie mit der rechten Maustaste auf die Datei im Datei-Explorer, wählen Sie "Eigenschaften" und wählen Sie die Registerkarte Sicherheit. Klicken Sie auf "Hinzufügen", um den entsprechenden Benutzer oder die Gruppe hinzuzufügen. Markieren Sie das ASP.NET-Konto und aktivieren Sie die Kontrollkästchen für den gewünschten Zugriff.

Weirdly obwohl dies ein Vorschlag, meine microsoft

Answer 1

Dieser Blog-Eintrag Gespräche über dieses Thema im Detail gegeben war. Vielleicht könnte dies Ihnen helfen
https://blogs.msdn.microsoft.com/cie/2016/01/15/error-access-to-the-path-esitesroot0web-config-is-denied-when-storing-azure-ads-public-key-in-web-config-of-an-azure-cloud-services-application/

Answer 2

Die Anleitung, die Sie in der "Web applications protecting resources and created with Visual Studio 2012" section of the Signing Key Documentation darauf hingewiesen, gilt nur für Anwendungen, bei denen Sie die Web.config während der Laufzeit ändern können.

Azure Web-Apps fallen nicht in diese Kategorie. Neben dem Problem mit der Berechtigung, mit dem Sie konfrontiert werden, übernehmen Azure Web-Apps keine Garantie für die Persistenz der zugrunde liegenden VM. Das bedeutet, dass sich jede Laufzeitänderung im web.Config jederzeit rückgängig machen lässt.

Zum Zweck des Rollovers vom 15. August können Sie die Anwendung lokal ausführen und einfach die eingecheckten web.Config- und Azure Web App-Einstellungen Ihrer Anwendungen aktualisieren. Da die Metadaten bereits über den aktuellen Schlüssel und den Schlüssel verfügen, für den Azure AD am 15. installiert wird, werden die resultierenden web.Config/settings Sie für dieses spezielle Ereignis abdecken.

Um jedoch den automatischen Rollover ordnungsgemäß zu unterstützen, sollten Sie Ihre Anwendung auf einen neueren Stack migrieren, z. B. die Owin-Middleware.