Principy přístupu jen pro aplikace
Když aplikace přímo přistupuje k prostředku, jako je Microsoft Graph, jeho přístup není omezen na soubory nebo operace dostupné pro každého uživatele. Aplikace volá rozhraní API přímo pomocí vlastní identity a uživatel nebo aplikace s právy správce ji musí autorizovat pro přístup k prostředkům. Tento scénář je jen pro aplikace.
Kdy mám používat přístup jen pro aplikaci?
Ve většině případů je přístup jen pro aplikace širší a výkonnější než delegovaný přístup, takže byste měli používat jenom přístup jen pro aplikace tam, kde je to potřeba. Obvykle je to správná volba, pokud:
- Aplikace se musí spouštět automatizovaným způsobem bez vstupu uživatele. Například denní skript, který kontroluje e-maily z určitých kontaktů a odesílá automatizované odpovědi.
- Aplikace potřebuje přístup k prostředkům patřícím více různým uživatelům. Aplikace pro ochranu před únikem informací může například potřebovat načíst zprávy z mnoha různých chatovacích kanálů, z nichž každý má jiné účastníky.
- Zjistíte, že vás láká ukládat přihlašovací údaje místně a umožníte aplikaci přihlásit se jako uživatel nebo správce.
Naproti tomu byste nikdy neměli používat přístup jen pro aplikaci, kde by se uživatel normálně přihlásil ke správě vlastních prostředků. Tyto typy scénářů musí používat delegovaný přístup, aby byl nejméně privilegovaný.
Autorizace aplikace pro volání jen pro aplikaci
Pokud chcete volat jen pro aplikace, musíte klientské aplikaci přiřadit příslušné role aplikace. Role aplikací se také označují jako oprávnění jen pro aplikaci. Jsou to role aplikací , protože udělují přístup pouze v kontextu aplikace prostředků, která tuto roli definuje.
Pokud chcete například přečíst seznam všech týmů vytvořených v organizaci, musíte aplikaci přiřadit jako roli aplikace Microsoft Graph Team.ReadBasic.All . Tato role aplikace umožňuje číst tato data, když je microsoft Graph aplikací prostředků. Toto přiřazení nepřiřazuje klientskou aplikaci k roli Teams, která by jí mohla umožnit zobrazit tato data prostřednictvím jiných služeb.
Jako vývojář musíte nakonfigurovat všechna požadovaná oprávnění jen pro aplikace, označovaná také jako role aplikací při registraci aplikace. Požadovaná oprávnění aplikace můžete nakonfigurovat prostřednictvím webu Azure Portal nebo Microsoft Graphu. Přístup jen pro aplikace nepodporuje dynamický souhlas, takže nemůžete požadovat jednotlivá oprávnění ani sady oprávnění za běhu.
Jakmile nakonfigurujete všechna oprávnění, která vaše aplikace potřebuje, musí získat souhlas správce pro přístup k prostředkům. Například pouze uživatelé s rolí globálního správce můžou udělit oprávnění jen pro aplikaci (role aplikací) pro rozhraní Microsoft Graph API. Uživatelé s jinými rolemi správců, jako je správce aplikací a správce cloudových aplikací, můžou udělit oprávnění jenom pro ostatní prostředky.
Správa uživatelé můžou udělit oprávnění jen pro aplikace pomocí webu Azure Portal nebo prostřednictvím kódu programu prostřednictvím rozhraní Microsoft Graph API. Můžete také zobrazit výzvu k interaktivnímu souhlasu z vaší aplikace, ale tato možnost není vhodnější, protože přístup jenom k aplikaci nevyžaduje uživatele.
Uživatelé uživatelů s účty Microsoft, jako jsou účty Outlook.com nebo Xbox Live, nikdy nemůžou autorizovat přístup jen pro aplikace.
Vždy dodržujte princip nejnižších oprávnění: Nikdy byste neměli požadovat role aplikací, které vaše aplikace nepotřebuje. Tento princip pomáhá omezit riziko zabezpečení v případě ohrožení vaší aplikace a usnadňuje správcům udělení přístupu k aplikaci. Pokud například vaše aplikace potřebuje identifikovat uživatele bez čtení podrobných informací o profilu, měli byste místo toho požádat o omezenější roli User.Read.Allaplikace Microsoft GraphUser.ReadBasic.All.
Návrh a publikování rolí aplikací pro službu prostředků
Pokud vytváříte službu na Microsoft Entra ID, které zveřejňuje rozhraní API pro ostatní klienty, aby volali, můžete chtít podporovat automatizovaný přístup s rolemi aplikací (oprávnění jen pro aplikace). Role aplikací pro vaši aplikaci můžete definovat v části Role aplikace registrace vaší aplikace v Centru pro správu Microsoft Entra. Další informace o tom, jak vytvořit role aplikace, naleznete v tématu Deklarace rolí pro aplikaci.
Při zveřejnění rolí aplikací pro ostatní uživatele zadejte jasné popisy scénáře správci, který je bude přiřazovat. Role aplikací by obecně měly být co nejužší a podporovat konkrétní funkční scénáře, protože přístup jen pro aplikaci není omezený uživatelskými právy. Vyhněte se zveřejnění jedné role, která uděluje úplný read nebo úplný read/write přístup ke všem rozhraním API a prostředkům, které vaše služba obsahuje.
Poznámka:
Role aplikací (oprávnění jen pro aplikace) je také možné nakonfigurovat tak, aby podporovaly přiřazování uživatelům a skupinám. Ujistěte se, že správně nakonfigurujete role aplikace pro zamýšlený scénář přístupu. Pokud máte v úmyslu používat role aplikací rozhraní API pro přístup jen pro aplikace, vyberte aplikace jako jediné povolené typy členů při vytváření rolí aplikace.
Jak funguje přístup jenom k aplikacím?
Nejdůležitější věcí, kterou je potřeba pamatovat na přístup jen pro aplikaci, je to, že volající aplikace funguje vlastním jménem a jako vlastní identita. Neexistuje žádná interakce uživatele. Pokud byla aplikace přiřazena k dané roli aplikace pro prostředek, má aplikace plně nekontrénovaný přístup ke všem prostředkům a operacím, které se řídí danou rolí aplikace.
Jakmile je aplikace přiřazená k jedné nebo více rolím aplikace (oprávněním jen pro aplikaci), může požádat token jen pro aplikaci z Id Microsoft Entra pomocí toku přihlašovacích údajů klienta nebo jakéhokoli jiného podporovaného ověřovacího toku . Přiřazené role se přidají k roles deklaraci identity přístupového tokenu aplikace.
V některých scénářích může identita aplikace určit, jestli je udělen přístup, podobně jako uživatelská práva v delegovaném volání. Role aplikace například Application.ReadWrite.OwnedBy uděluje aplikaci možnost spravovat instanční objekty, které vlastní aplikace.
Příklad přístupu jen pro aplikace – Automatizované e-mailové oznámení prostřednictvím Microsoft Graphu
Následující příklad znázorňuje realistický scénář automatizace.
Alice chce týmu oznámit e-mailem pokaždé, když složka sestav oddělení, která se nachází ve sdílené složce systému Windows, zaregistruje nový dokument. Alice vytvoří naplánovanou úlohu, která spustí skript PowerShellu pro prozkoumání složky a vyhledání nových souborů. Skript pak odešle e-mail pomocí poštovní schránky chráněné rozhraním API prostředku Microsoft Graph.
Skript běží bez zásahu uživatele, a proto autorizační systém kontroluje pouze autorizaci aplikace. Exchange Online zkontroluje, jestli správce udělil klientovi volání oprávnění aplikace (roli Mail.Send aplikace). Pokud Mail.Send aplikaci neudělíte, Exchange Online žádost selže.
| POST /users/{id}/{userPrincipalName}/sendMail | Klientská aplikace udělila Mail.Send | Klientská aplikace nemá udělenou poštu.Send |
|---|---|---|
| Skript používá poštovní schránku Alice k odesílání e-mailů. | 200 – Přístup udělen. Správa aplikaci povolit odesílání pošty jako libovolného uživatele. | 403 - Neautorizováno. Správa nepovolil tomuto klientovi odesílat e-maily. |
| Skript vytvoří vyhrazenou poštovní schránku pro odesílání e-mailů. | 200 – Přístup udělen. Správa aplikaci povolit odesílání pošty jako libovolného uživatele. | 403 - Neautorizováno. Správa nepovolil tomuto klientovi odesílat e-maily. |
Uvedený příklad je jednoduchá ilustrace autorizace aplikace. Produkční služba Exchange Online podporuje mnoho dalších scénářů přístupu, například omezení oprávnění aplikace na konkrétní poštovní schránky Exchange Online.