Bezpečnostní rámec: Autorizace | Zmírnění rizik

Produkt/služba	Článek
Hranice důvěryhodnosti počítače	Ujistěte se, že jsou správné seznamy ACL nakonfigurované tak, aby omezovaly neoprávněný přístup k datům v zařízení. Ujistěte se, že je citlivý obsah aplikace specifický pro uživatele uložený v adresáři profilů uživatelů. Ujistěte se, že nasazené aplikace běží s nejnižšími oprávněními.
Webová aplikace	Vynucení pořadí sekvenčních kroků při zpracování toků obchodní logiky Implementujte mechanismus omezování rychlosti, aby se zabránilo výčtu. Ujistěte se, že je zavedená správná autorizace a že se dodržuje princip nejnižších oprávnění. Obchodní logika a rozhodnutí o autorizaci přístupu k prostředkům by neměly být založené na parametrech příchozích požadavků. Ujistěte se, že obsah a prostředky nejsou vyčíslitelné ani přístupné prostřednictvím vynuceného procházení.
Databáze	Ujistěte se, že se k databázovému serveru používají nejméně privilegované účty. Implementujte zabezpečení na úrovni řádků, abyste zabránili klientům v přístupu k datům jednotlivých uživatelů. Role správce systému by měla obsahovat pouze platné nezbytné uživatele.
Cloudová brána IoT	Připojení ke cloudové bráně pomocí nejméně privilegovaných tokenů
Azure Event Hub	Použití klíče SAS jen pro odesílání oprávnění pro generování tokenů zařízení Nepoužívejte přístupové tokeny, které poskytují přímý přístup k centru událostí. Připojení k centru událostí pomocí klíčů SAS, které mají minimální požadovaná oprávnění
Azure Document DB	Použití tokenů prostředků k připojení ke službě Azure Cosmos DB, kdykoli je to možné
Hranice důvěryhodnosti Azure	Povolení jemně odstupňované správy přístupu k předplatnému Azure pomocí Azure RBAC
Hranice důvěryhodnosti Service Fabric	Omezení přístupu klienta k operacím clusteru pomocí Azure RBAC
Dynamics CRM	Modelování zabezpečení a použití zabezpečení na úrovni polí v případě potřeby
Portál Dynamics CRM	Při modelování zabezpečení účtů portálu mějte na paměti, že se model zabezpečení portálu liší od zbytku CRM.
Azure Storage	Udělení jemně odstupňovaného oprávnění pro řadu entit ve službě Azure Table Storage Povolení řízení přístupu na základě role Azure (Azure RBAC) k účtu úložiště Azure pomocí Azure Resource Manageru
Mobilní klient	Implementace implicitní detekce jailbreaku nebo rootingu
WCF	Slabý odkaz na třídu ve WCF Wcf-Implement Authorization Control
Webové rozhraní API	Implementace správného mechanismu autorizace ve webovém rozhraní API ASP.NET
Zařízení IoT	Provedení kontrol autorizace v zařízení, pokud podporuje různé akce, které vyžadují různé úrovně oprávnění
IoT Field Gateway	Provádění kontrol autorizace ve službě Field Gateway, pokud podporuje různé akce, které vyžadují různé úrovně oprávnění

Ujistěte se, že jsou správné seznamy ACL nakonfigurované tak, aby omezovaly neoprávněný přístup k datům v zařízení.

Nadpis	Detaily
Součást	Hranice důvěryhodnosti počítače
Fáze SDL	Nasazení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Ujistěte se, že jsou správné seznamy ACL nakonfigurované tak, aby omezovaly neoprávněný přístup k datům v zařízení.

Ujistěte se, že je citlivý obsah aplikace specifický pro uživatele uložený v adresáři profilů uživatelů.

Nadpis	Detaily
Součást	Hranice důvěryhodnosti počítače
Fáze SDL	Nasazení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Ujistěte se, že je citlivý obsah aplikace specifický pro uživatele uložený v adresáři profilů uživatelů. Tím zabráníte více uživatelům počítače v přístupu k datům jednotlivých uživatelů.

Ujistěte se, že nasazené aplikace běží s nejnižšími oprávněními.

Nadpis	Detaily
Součást	Hranice důvěryhodnosti počítače
Fáze SDL	Nasazení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Ujistěte se, že nasazená aplikace běží s nejnižšími oprávněními.

Vynucení pořadí sekvenčních kroků při zpracování toků obchodní logiky

Nadpis	Detaily
Součást	Webová aplikace
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Aby bylo možné ověřit, že tuto fázi prošel skutečný uživatel, kterého chcete vynutit, aby zpracovávala pouze toky obchodní logiky v sekvenčním pořadí kroků, přičemž všechny kroky zpracovávané v reálném čase a nezpracovávají se mimo pořadí, přeskočeny kroky, zpracovávané kroky od jiného uživatele nebo příliš rychle odeslané transakce.

Implementujte mechanismus omezování rychlosti, aby se zabránilo výčtu.

Nadpis	Detaily
Součást	Webová aplikace
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Ujistěte se, že citlivé identifikátory jsou náhodné. Implementujte ovládací prvek CAPTCHA na anonymních stránkách. Ujistěte se, že by chyba a výjimka neměly odhalit konkrétní data.

Ujistěte se, že je zavedená správná autorizace a že se dodržuje princip nejnižších oprávnění.

Nadpis	Detaily
Součást	Webová aplikace
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Princip znamená poskytnutí uživatelského účtu pouze těm oprávněním, která jsou pro uživatele nezbytná. Například zálohovací uživatel nemusí instalovat software: proto má uživatel zálohy práva pouze ke spouštění aplikací souvisejících se zálohováním a zálohováním. Všechna další oprávnění, například instalace nového softwaru, jsou blokovaná. Princip platí také pro uživatele osobního počítače, který obvykle pracuje v normálním uživatelském účtu, a otevře privilegovaný účet chráněný heslem (tj. superuživatel) pouze tehdy, když to situace naprosto vyžaduje. Tento princip lze použít také u webových aplikací. Místo výhradně v závislosti na metodách ověřování na základě role pomocí relací chceme uživatelům přiřadit oprávnění prostřednictvím systému ověřování založeného na databázi. Pořád používáme relace, abychom zjistili, jestli byl uživatel přihlášen správně, jenom teď místo toho, abychom ho přiřadili s konkrétní rolí, kterou mu přiřadíme s oprávněními k ověření, které akce má v systému privilegované. Velkou kladou této metody je také to, že vždy, když musí být uživateli přiřazeno méně oprávnění, vaše změny se použijí průběžně, protože přiřazování nezávisí na relaci, která jinak musela vypršet jako první.

Obchodní logika a rozhodnutí o autorizaci přístupu k prostředkům by neměly být založené na parametrech příchozích požadavků.

Nadpis	Detaily
Součást	Webová aplikace
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Kdykoli kontrolujete, jestli je uživatel omezen na kontrolu určitých dat, měla by být zpracována omezení přístupu na straně serveru. ID uživatele by mělo být uloženo uvnitř proměnné relace při přihlášení a mělo by se použít k načtení uživatelských dat z databáze.

Příklad

SELECT data 
FROM personaldata 
WHERE userID=:id < - session var 

Možný útočník teď nemůže zfalšovat a změnit operaci aplikace, protože identifikátor pro načtení dat se zpracovává na straně serveru.

Ujistěte se, že obsah a prostředky nejsou vyčíslitelné ani přístupné prostřednictvím vynuceného procházení.

Nadpis	Detaily
Součást	Webová aplikace
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Citlivé statické a konfigurační soubory by se neměly uchovávat ve webovém kořenovém adresáři. Pro obsah, který nemusí být veřejný, je třeba použít správné řízení přístupu nebo odebrat samotný obsah. Vynucené procházení se obvykle kombinuje s technikami hrubou silou ke shromažďování informací tím, že se pokusíte získat přístup k co nejvíce adresÁM URL pro výčet adresářů a souborů na serveru. Útočníci můžou zkontrolovat všechny varianty běžně existujících souborů. Hledání souborů hesel by například zahrnovalo soubory včetně psswd.txt, password.htm, password.dat a dalších variant. Aby se to zmírnit, měly by být zahrnuty možnosti detekce pokusů o hrubou silou.

Ujistěte se, že se k databázovému serveru používají nejméně privilegované účty.

Nadpis	Detaily
Součást	Databáze
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	Hierarchie oprávnění SQL, zabezpečitelné sql
Kroky	Účty s nejnižšími oprávněními by se měly použít k připojení k databázi. Přihlášení aplikace by mělo být v databázi omezeno a mělo by se spouštět jenom vybrané uložené procedury. Přihlášení aplikace by nemělo mít přímý přístup k tabulce.

Implementujte zabezpečení na úrovni řádků, abyste zabránili klientům v přístupu k datům jednotlivých uživatelů.

Nadpis	Detaily
Součást	Databáze
Fáze SDL	Sestavení
Použitelné technologie	Sql Azure, OnPrem
Atributy	Verze SQL – V12, verze SQL – MsSQL2016
Odkazy	Zabezpečení na úrovni řádků SQL Serveru (RLS)
Kroky	Zabezpečení na úrovni řádku umožňuje řízení přístupu k řádkům v databázové tabulce na základě charakteristiky uživatele spouštějícího dotaz (například členství ve skupině nebo kontext spuštění). Zabezpečení na úrovni řádků (RLS) zjednodušuje návrh a kódování zabezpečení ve vaší aplikaci. RLS umožňuje implementovat omezení přístupu k datovým řádkům. Například pro zajištění, že pracovníci mají přístup pouze k datovým řádkům, které se vztahují k jejich oddělení, nebo pro omezení přístupu zákazníků pouze k datům souvisejícím s jejich společností. Logika omezení přístupu se nachází v databázové vrstvě, nikoli mimo data v jiné aplikační vrstvě. Databázový systém použije omezení přístupu při každém pokusu o přístup k datům z libovolné vrstvy. Díky tomu je systém zabezpečení spolehlivější a robustnější tím, že sníží plochu systému zabezpečení.

Mějte na paměti, že zabezpečení na úrovni řádků jako předefinované funkce databáze platí jenom pro SQL Server od roku 2016, Azure SQL Database a sql Managed Instance. Pokud není implementovaná funkce RLS, měla by být zajištěna omezení přístupu k datům pomocí zobrazení a postupů.

Role správce systému by měla obsahovat pouze platné nezbytné uživatele.

Nadpis	Detaily
Součást	Databáze
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	Hierarchie oprávnění SQL, zabezpečitelné sql
Kroky	Členové pevné role serveru SysAdmin by měli být velmi omezeni a nikdy neobsahují účty používané aplikacemi. Projděte si seznam uživatelů v roli a odeberte všechny nepotřebné účty.

Připojení ke cloudové bráně pomocí nejméně privilegovaných tokenů

Nadpis	Detaily
Součást	Cloudová brána IoT
Fáze SDL	Nasazení
Použitelné technologie	Obecná
Atributy	Volba brány – Azure IoT Hub
Odkazy	Řízení přístupu ke službě Iot Hub
Kroky	Poskytněte různým komponentám, které se připojují ke službě Cloud Gateway (IoT Hub), oprávnění s nejnižšími oprávněními. Typickým příkladem je – komponenta správy/zřizování zařízení používá protokol registryread/write, Event Processor (ASA) používá Service Connect. Jednotlivá zařízení se připojují pomocí přihlašovacích údajů zařízení

Použití klíče SAS jen pro odesílání oprávnění pro generování tokenů zařízení

Nadpis	Detaily
Součást	Azure Event Hub
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	Přehled ověřování a modelu zabezpečení služby Event Hubs
Kroky	Klíč SAS se používá ke generování jednotlivých tokenů zařízení. Při generování tokenu zařízení pro daného vydavatele použijte klíč SAS jen pro odeslání.

Nepoužívejte přístupové tokeny, které poskytují přímý přístup k centru událostí.

Nadpis	Detaily
Součást	Azure Event Hub
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	Přehled ověřování a modelu zabezpečení služby Event Hubs
Kroky	Token, který uděluje přímý přístup k centru událostí, by neměl být zařízením udělen. Použití nejméně privilegovaného tokenu pro zařízení, které poskytuje přístup pouze vydavateli, by pomohlo identifikovat a zakázat ho, pokud by se zjistilo, že jde o podvodné nebo ohrožené zařízení.

Připojení k centru událostí pomocí klíčů SAS, které mají minimální požadovaná oprávnění

Nadpis	Detaily
Součást	Azure Event Hub
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	Přehled ověřování a modelu zabezpečení služby Event Hubs
Kroky	Poskytněte různým back-endovým aplikacím, které se připojují k centru událostí, oprávnění s nejnižšími oprávněními. Vygenerujte samostatné klíče SAS pro každou back-endovou aplikaci a poskytují jenom požadovaná oprávnění – Odesílat, přijímat nebo spravovat.

Použití tokenů prostředků k připojení ke službě Azure Cosmos DB, kdykoli je to možné

Nadpis	Detaily
Součást	Azure Document DB
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Token prostředku je přidružený k prostředku oprávnění služby Azure Cosmos DB a zachycuje vztah mezi uživatelem databáze a oprávněním, které má uživatel pro konkrétní prostředek aplikace Azure Cosmos DB (např. kolekci, dokument). Token prostředku vždy používejte pro přístup ke službě Azure Cosmos DB, pokud klient nemůže být důvěryhodný pro zpracování hlavních klíčů nebo klíčů jen pro čtení , jako je aplikace koncového uživatele, jako je mobilní nebo desktopový klient. Použijte hlavní klíč nebo klíče jen pro čtení z back-endových aplikací, které můžou bezpečně ukládat tyto klíče.

Povolení jemně odstupňované správy přístupu k předplatnému Azure pomocí Azure RBAC

Nadpis	Detaily
Součást	Hranice důvěryhodnosti Azure
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	Přiřazení rolí Azure ke správě přístupu k prostředkům předplatného Azure
Kroky	Řízení přístupu na základě role v Azure (Azure RBAC) umožňuje jemně odstupňovanou správu přístupu pro Azure. Pomocí Azure RBAC můžete udělit jenom množství přístupu, které uživatelé potřebují k provádění svých úloh.

Omezení přístupu klienta k operacím clusteru pomocí RBAC Service Fabric

Nadpis	Detaily
Součást	Hranice důvěryhodnosti Service Fabric
Fáze SDL	Nasazení
Použitelné technologie	Obecná
Atributy	Prostředí – Azure
Odkazy	Řízení přístupu na základě role Service Fabric pro klienty Service Fabric
Kroky	Azure Service Fabric podporuje dva různé typy řízení přístupu pro klienty, kteří jsou připojení ke clusteru Service Fabric: správce a uživatel. Řízení přístupu umožňuje správci clusteru omezit přístup k určitým operacím clusteru pro různé skupiny uživatelů, aby byl cluster bezpečnější. Správci mají úplný přístup k možnostem správy (včetně možností čtení a zápisu). Ve výchozím nastavení mají uživatelé přístup ke správě jen pro čtení (například možnosti dotazů) a možnost řešit aplikace a služby. V době vytváření clusteru zadáte dvě role klienta (správce a klient), a to tak, že pro každý z nich zadáte samostatné certifikáty.

Modelování zabezpečení a použití zabezpečení na úrovni polí v případě potřeby

Nadpis	Detaily
Součást	Dynamics CRM
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Modelování zabezpečení a použití zabezpečení na úrovni polí v případě potřeby

Při modelování zabezpečení účtů portálu mějte na paměti, že se model zabezpečení portálu liší od zbytku CRM.

Nadpis	Detaily
Součást	Portál Dynamics CRM
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Při modelování zabezpečení účtů portálu mějte na paměti, že se model zabezpečení portálu liší od zbytku CRM.

Udělení jemně odstupňovaného oprávnění pro řadu entit ve službě Azure Table Storage

Nadpis	Detaily
Součást	Azure Storage
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	StorageType – tabulka
Odkazy	Delegování přístupu k objektům v účtu úložiště Azure pomocí SAS
Kroky	V některých obchodních scénářích může být služba Azure Table Storage nutná k ukládání citlivých dat, která vyhovují různým stranám. Například citlivá data týkající se různých zemí/oblastí. V takových případech je možné podpisy SAS vytvořit zadáním rozsahů klíčů oddílů a řádků, aby uživatel mohl přistupovat k datům specifickým pro určitou zemi nebo oblast.

Povolení řízení přístupu na základě role Azure (Azure RBAC) k účtu úložiště Azure pomocí Azure Resource Manageru

Nadpis	Detaily
Součást	Azure Storage
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	Jak zabezpečit účet úložiště pomocí řízení přístupu na základě role v Azure (Azure RBAC)
Kroky	Když vytvoříte nový účet úložiště, vyberete model nasazení Classic nebo Azure Resource Manageru. Klasický model vytváření prostředků v Azure umožňuje přístup k předplatnému jenom všem nebo nic a účet úložiště. Pomocí modelu Azure Resource Manageru vložíte účet úložiště do skupiny prostředků a budete řídit přístup k rovině správy daného konkrétního účtu úložiště pomocí ID Microsoft Entra. Můžete například konkrétním uživatelům udělit přístup k klíčům účtu úložiště, zatímco jiní uživatelé můžou zobrazit informace o účtu úložiště, ale nemají přístup k klíčům účtu úložiště.

Implementace implicitní detekce jailbreaku nebo rootingu

Nadpis	Detaily
Součást	Mobilní klient
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Aplikace by měla chránit vlastní konfiguraci a uživatelská data v případě, že je telefon root nebo jailbreak. Rooting/jailbreak implikuje neoprávněný přístup, který normální uživatelé nebudou dělat na svých vlastních telefonech. Aplikace by proto měla mít při spuštění aplikace implicitní logiku detekce, aby se zjistilo, jestli byl telefon root. Logika detekce může jednoduše přistupovat k souborům, ke kterým má obvykle přístup pouze uživatel root, například: /system/app/Superuser.apk /sbin/su /system/bin/su /system/xbin/su /data/local/xbin/su /data/local/bin/su /system/sd/xbin/su /system/bin/failsafe/su /data/local/su Pokud má aplikace přístup k některému z těchto souborů, znamená to, že aplikace běží jako uživatel root.

Slabý odkaz na třídu ve WCF

Nadpis	Detaily
Součást	WCF
Fáze SDL	Sestavení
Použitelné technologie	Obecné, NET Framework 3
Atributy	–
Odkazy	MSDN, Fortify Kingdom
Kroky	Systém používá slabý odkaz na třídu, který by mohl útočníkovi umožnit spuštění neoprávněného kódu. Program odkazuje na uživatelem definovanou třídu, která není jedinečně identifikována. Když .NET načte tuto slabě identifikovanou třídu, zavaděč typu CLR vyhledá třídu v následujících umístěních v zadaném pořadí: Pokud je známo sestavení typu, zavaděč prohledá umístění přesměrování konfiguračního souboru, GAC, aktuální sestavení pomocí konfiguračních informací a základního adresáře aplikace. Pokud je sestavení neznámé, zavaděč vyhledá aktuální sestavení, mscorlib a umístění vrácené obslužnou rutinou události TypeResolve. Toto pořadí hledání CLR lze upravit pomocí háků, jako je mechanismus předávání typů a událost AppDomain.TypeResolve. Pokud útočník zneužije pořadí hledání CLR tak, že vytvoří alternativní třídu se stejným názvem a umístí ji do alternativního umístění, které clR načte jako první, clr neúmyslně spustí kód zadaný útočníkem.

Příklad

Element <behaviorExtensions/> konfiguračního souboru WCF níže dává WCF pokyn k přidání vlastní třídy chování do konkrétní rozšíření WCF.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""MyBehavior"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

Použití plně kvalifikovaných (silných) názvů jednoznačně identifikuje typ a dále zvyšuje zabezpečení systému. Při registraci typů v souborech machine.config aappch

Příklad

Element <behaviorExtensions/> konfiguračního souboru WCF níže dává WCF pokyn, aby do konkrétní přípony WCF přidal třídu vlastního chování se silným odkazem.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""Microsoft.ServiceModel.Samples.MyBehaviorSection, MyBehavior,
            Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

Wcf-Implement Authorization Control

Nadpis	Detaily
Součást	WCF
Fáze SDL	Sestavení
Použitelné technologie	Obecné, NET Framework 3
Atributy	–
Odkazy	MSDN, Fortify Kingdom
Kroky	Tato služba nepoužívá autorizační ovládací prvek. Když klient volá určitou službu WCF, poskytuje wcf různá schémata autorizace, která ověřují, že volající má oprávnění ke spuštění metody služby na serveru. Pokud nejsou pro služby WCF povolené ovládací prvky autorizace, může ověřený uživatel dosáhnout eskalace oprávnění.

Příklad

Následující konfigurace dává WCF pokyn, aby při provádění služby nezkontroloval úroveň autorizace klienta:

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""None"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Pomocí schématu autorizace služby ověřte, že volající metody služby má oprávnění k tomu. WCF poskytuje dva režimy a umožňuje definici vlastního schématu autorizace. Režim UseWindowsGroups používá role a uživatele Systému Windows a režim UseAspNetRoles používá k ověření ASP.NET zprostředkovatele rolí, jako je SQL Server.

Příklad

Následující konfigurace dává WCF pokyn, aby se před spuštěním služby Add service ujistil, že klient je součástí skupiny Administrators:

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""UseWindowsGroups"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Služba se pak deklaruje jako následující:

[PrincipalPermission(SecurityAction.Demand,
Role = ""Builtin\\Administrators"")]
public double Add(double n1, double n2)
{
double result = n1 + n2;
return result;
}

Implementace správného mechanismu autorizace ve webovém rozhraní API ASP.NET

Nadpis	Detaily
Součást	Webové rozhraní API
Fáze SDL	Sestavení
Použitelné technologie	Obecné, MVC5
Atributy	Není k dispozici, zprostředkovatel identity – ADFS, zprostředkovatel identity – Microsoft Entra ID
Odkazy	Ověřování a autorizace ve webovém rozhraní API ASP.NET
Kroky	Informace o rolích pro uživatele aplikace můžou být odvozeny od microsoft Entra ID nebo deklarací identity ADFS, pokud se na ně aplikace spoléhá jako na zprostředkovatele identity nebo samotná aplikace ji může poskytnout. V každém z těchto případů by vlastní implementace autorizace měla ověřit informace o roli uživatele. Informace o rolích pro uživatele aplikace můžou být odvozeny od microsoft Entra ID nebo deklarací identity ADFS, pokud se na ně aplikace spoléhá jako na zprostředkovatele identity nebo samotná aplikace ji může poskytnout. V každém z těchto případů by vlastní implementace autorizace měla ověřit informace o roli uživatele.

Příklad

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
public class ApiAuthorizeAttribute : System.Web.Http.AuthorizeAttribute
{
        public async override Task OnAuthorizationAsync(HttpActionContext actionContext, CancellationToken cancellationToken)
        {
            if (actionContext == null)
            {
                throw new Exception();
            }

            if (!string.IsNullOrEmpty(base.Roles))
            {
                bool isAuthorized = ValidateRoles(actionContext);
                if (!isAuthorized)
                {
                    HandleUnauthorizedRequest(actionContext);
                }
            }

            base.OnAuthorization(actionContext);
        }

public bool ValidateRoles(actionContext)
{
   //Authorization logic here; returns true or false
}

}

Všechny kontrolery a metody akcí, které je potřeba chránit, by měly být zdobeny výše uvedeným atributem.

[ApiAuthorize]
public class CustomController : ApiController
{
     //Application code goes here
}

Provedení kontrol autorizace v zařízení, pokud podporuje různé akce, které vyžadují různé úrovně oprávnění

Nadpis	Detaily
Součást	Zařízení IoT
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Zařízení by mělo volajícímu autorizovat, aby zkontrolovalo, jestli má volající požadovaná oprávnění k provedení požadované akce. Řekněme například, že zařízení je inteligentní zámek dveří, který lze monitorovat z cloudu, a navíc poskytuje funkce, jako je vzdálené zamykání dveří. Smart Door Lock poskytuje funkce odemknutí pouze v případě, že se někdo fyzicky blíží ke dveřím s kartou. V tomto případě by měla být implementace vzdáleného příkazu a řízení provedena takovým způsobem, že neposkytuje žádné funkce pro odemknutí dveří, protože cloudová brána nemá oprávnění odeslat příkaz k odemknutí dveří.

Provádění kontrol autorizace ve službě Field Gateway, pokud podporuje různé akce, které vyžadují různé úrovně oprávnění

Nadpis	Detaily
Součást	IoT Field Gateway
Fáze SDL	Sestavení
Použitelné technologie	Obecná
Atributy	–
Odkazy	–
Kroky	Brána pole by měla volajícímu autorizovat, aby zkontrolovala, jestli má volající požadovaná oprávnění k provedení požadované akce. Například pro uživatelské rozhraní nebo rozhraní API správce by měla existovat různá oprávnění, která se používají ke konfiguraci zařízení brány polí v/s, která se k němu připojují.