Share via

Architekturális szempontok az identitáshoz több-bérlős megoldásban

  • Cikk

Az identitás minden több-bérlős megoldás fontos eleme. Az alkalmazás identitásösszetevői a következőkért felelősek:

  • Annak ellenőrzése, hogy ki a felhasználó (hitelesítés).
  • A felhasználó engedélyeinek kikényszerítése a bérlő hatókörén belül (engedélyezés).

Előfordulhat, hogy az ügyfelek engedélyezni szeretnék a külső alkalmazások számára az adataik elérését vagy a megoldásba való integrálást. A felhasználó identitása határozza meg, hogy milyen információkhoz férhet hozzá egy felhasználó vagy szolgáltatás. Fontos, hogy figyelembe vegye az identitáskövetelményeket, hogy elkülönítse az alkalmazást és az adatokat a bérlők között.

Figyelmeztetés

A több- és SaaS-alkalmazásokon belüli hitelesítési és engedélyezési szolgáltatásokat általában egy külső identitásszolgáltató (IdP) biztosítja. Az identitásszolgáltató általában az identitásszolgáltatás (IDaaS) platform szerves része.

A saját identitásszolgáltató létrehozása összetett, költséges és nehezen építkezhet biztonságosan. A saját identitásszolgáltató létrehozása egy antipattern. Nem javasoljuk.

A több-bérlős identitásstratégia meghatározása előtt először figyelembe kell vennie a szolgáltatás magas szintű identitáskövetelményeit, beleértve a következő követelményeket:

  • A felhasználó- vagy számítási feladatok identitásai egy termékcsaládon belül egyetlen alkalmazáshoz vagy több alkalmazáshoz is hozzáférnek? Egy kiskereskedelmi termékcsalád például rendelkezhet egy értékesítési pont alkalmazással és egy készletkezelési alkalmazással is, amely ugyanazzal az identitásmegoldással rendelkezik.
  • Modern hitelesítés és engedélyezés implementálását tervezi, például OAuth2 és OpenID Csatlakozás?
  • A megoldás csak a felhasználói felületalapú alkalmazások hitelesítését biztosítja? Vagy API-hozzáférést is biztosít a bérlőinek és harmadik feleknek?
  • A bérlőknek össze kell egyesíteniük a saját identitásszolgáltatójukat, és több különböző identitásszolgáltatót kell támogatniuk minden bérlőhöz? Előfordulhat például, hogy Microsoft Entra ID, Auth0 és Active Directory összevonási szolgáltatások (AD FS) (ADFS) bérlői vannak, ahol mindegyik össze szeretné egyesíteni a megoldást. Azt is tudnia kell, hogy a bérlői azonosítók mely összevonási protokolljait fogja támogatni, mivel a protokollok befolyásolják a saját identitásszolgáltatójának követelményeit.
  • Vannak bizonyos megfelelőségi követelmények, amelyeknek meg kell felelniük, például a GDPR-nak?
  • A bérlői identitásadatoknak egy adott földrajzi régióban kell lenniük?
  • A megoldás felhasználóinak hozzáférésre van szükségük egy bérlő vagy több bérlő adataihoz az alkalmazásban? Szükség van arra, hogy gyorsan váltson a bérlők között, vagy több bérlő összesített adatait tekintse meg? Az Azure Portalra bejelentkezett felhasználók például egyszerűen válthatnak a különböző Azure Active Directoryk és előfizetések között, amelyekhez hozzáféréssel rendelkeznek.

Amikor létrehozta a magas szintű követelményeket, elkezdhet pontosabb részleteket és követelményeket tervezni, például a felhasználói címtár forrásait és a regisztrációs/bejelentkezési folyamatokat.

Identitáskönyvtár

Ahhoz, hogy egy több-bérlős megoldás hitelesítse és engedélyezze a felhasználót vagy szolgáltatást, szüksége van egy helyre az identitásadatok tárolására. A címtárak tartalmazhatnak mérvadó rekordokat az egyes identitásokhoz, vagy tartalmazhatnak olyan külső identitásokra mutató hivatkozásokat, amelyek egy másik identitásszolgáltató címtárában vannak tárolva.

Ha identitásrendszert tervez a több-bérlős megoldáshoz, figyelembe kell vennie, hogy a bérlőknek és az ügyfeleknek milyen típusú identitásszolgáltatóra lehet szükségük:

  • Helyi identitásszolgáltató. A helyi identitásszolgáltató lehetővé teszi a felhasználók számára, hogy regisztráljanak a szolgáltatásra. A felhasználók felhasználónevet, e-mail-címet vagy azonosítót, például jutalomkártyaszámot adnak meg. Emellett hitelesítő adatokat is biztosítanak, például jelszót. Az identitásszolgáltató a felhasználói azonosítót és a hitelesítő adatokat is tárolja.
  • Közösségi identitásszolgáltató. A közösségi identitásszolgáltató lehetővé teszi a felhasználók számára, hogy közösségi hálózaton vagy más nyilvános identitásszolgáltatón , például Facebookon, Google-on vagy személyes Microsoft-fiókban lévő identitást használjanak.
  • Használja a bérlő Microsoft Entra-azonosítóját vagy Microsoft 365-címtárát. Előfordulhat, hogy a bérlők már rendelkeznek saját Microsoft Entra-azonosítóval vagy Microsoft 365-címtárral, és előfordulhat, hogy azt szeretnék, hogy a megoldás a saját címtárukat használja identitásszolgáltatóként a megoldás eléréséhez. Ez a megközelítés akkor lehetséges, ha a megoldás több-bérlős Microsoft Entra-alkalmazásként van létrehozva.
  • Összevonás egy bérlő identitásszolgáltatójával. Előfordulhat, hogy a bérlőknek a Microsoft Entra ID vagy a Microsoft 365 kivételével saját identitásszolgáltatójuk van, és előfordulhat, hogy a megoldás összevonását szeretné. Az összevonás lehetővé teszi az egyszeri bejelentkezés (SSO) használatát, és lehetővé teszi a bérlők számára, hogy a megoldástól függetlenül kezeljék a felhasználók életciklusát és biztonsági szabályzatait.

Érdemes megfontolnia, hogy a bérlőknek több identitásszolgáltatót kell-e támogatniuk. Előfordulhat például, hogy egy bérlőn belül támogatnia kell a helyi identitásokat, a közösségi identitásokat és az összevont identitásokat. Ez a követelmény gyakori, ha a vállalatok olyan megoldást használnak, amely mind a saját alkalmazottaik, mind a alvállalkozók számára készült. Előfordulhat, hogy összevonást használnak a saját alkalmazottaik számára a megoldáshoz való hozzáféréshez, ugyanakkor lehetővé teszik a hozzáférést a alvállalkozókhoz vagy a vendégfelhasználókhoz is, akik nem rendelkeznek fiókkal az összevont identitásszolgáltatóban.

Hitelesítési és bérlői engedélyezési információk tárolása

Több-bérlős megoldás esetén meg kell fontolnia, hogy hol tároljon több típusú identitásinformációt, beleértve a következő típusokat:

  • A felhasználói és szolgáltatásfiókok részletei, beleértve a nevüket és a bérlők által igényelt egyéb információkat.
  • A felhasználók biztonságos hitelesítéséhez szükséges információk, beleértve a többtényezős hitelesítés (MFA) biztosításához szükséges információkat is.
  • Bérlőspecifikus információk, például bérlői szerepkörök és engedélyek. Ez az információ az engedélyezéshez használatos.

Figyelmeztetés

Nem javasoljuk, hogy saját maga építse ki a hitelesítési folyamatokat. A modern azonosítók ezeket a hitelesítési szolgáltatásokat biztosítják az alkalmazásnak, és más fontos funkciókat is tartalmaznak, például az MFA-t és a feltételes hozzáférést. A saját identitásszolgáltató létrehozása egy antipattern. Nem javasoljuk.

Fontolja meg az identitásadatok tárolásának alábbi lehetőségeit:

  • Tárolja az összes identitás- és engedélyezési információt az idP-címtárban, és ossza meg azokat több bérlő között.
  • Tárolja a felhasználói hitelesítő adatokat az IdP könyvtárban, és tárolja az engedélyezési adatokat az alkalmazásszinten, a bérlői adatok mellett.

A felhasználó identitásainak számának meghatározása

A több-bérlős megoldások esetében gyakori, hogy egy felhasználó vagy számítási feladat identitása több bérlő alkalmazásához és adataihoz fér hozzá. Gondolja át, hogy ez a megközelítés szükséges-e a megoldáshoz. Ha igen, akkor vegye figyelembe a következő kérdéseket:

  • Létre kell hoznia egy felhasználói identitást minden egyes személyhez, vagy külön identitásokat kell létrehoznia minden bérlő-felhasználó kombinációhoz?
    • A legjobb, ha minden személyhez egyetlen identitást használ, ahol csak lehetséges. A megoldás szállítójaként és a felhasználók számára is nehéz lesz több felhasználói fiókot kezelni. Emellett a modern identitásszolgáltató által kínált intelligens veszélyforrások elleni védelem nagy része arra támaszkodik, hogy minden személy egyetlen felhasználói fiókkal rendelkezik.
    • Bizonyos helyzetekben azonban szükség lehet arra, hogy a felhasználó több különböző identitással rendelkezzen. Ha például a felhasználók munkahelyi és személyes célokra is használják a rendszert, előfordulhat, hogy el szeretnének különíteni a felhasználói fiókjukat. Vagy ha a bérlők szigorú szabályozási vagy földrajzi adattárolási követelményekkel rendelkeznek, előfordulhat, hogy egy személynek több identitással kell rendelkeznie, hogy megfeleljenek a szabályozásoknak vagy törvényeknek.
  • Ha bérlőnkénti identitásokat használ, kerülje a hitelesítő adatok többszöri tárolását. A felhasználóknak egyetlen identitáson kell tárolniuk a hitelesítő adataikat, és olyan funkciókkal kell rendelkezniük, mint a vendégidentitások, amelyek több bérlő identitásrekordjából származó felhasználói hitelesítő adatokra hivatkoznak.

Hozzáférés biztosítása a felhasználók számára a bérlői adatokhoz

Gondolja át, hogyan lesznek leképezve a felhasználók egy bérlőre. A regisztrációs folyamat során például használhat egy egyedi meghívókódot, amelyet az első alkalommal adnak meg, amikor hozzáférnek egy bérlőhöz. Egyes megoldásokban a felhasználók regisztrációs e-mail-címeinek tartománynevét használhatja annak a bérlőnek a azonosítására, amelyhez tartoznak. Vagy a felhasználó identitásrekordjának egy másik attribútumával leképezheti a felhasználót egy bérlőre. Ezután a leképezést a bérlő és a felhasználó mögöttes nem módosítható egyedi azonosítói alapján kell tárolnia.

Ha a megoldás úgy van kialakítva, hogy egyetlen felhasználó csak egyetlen bérlő adataihoz férhessen hozzá, fontolja meg a következő döntéseket:

  • Hogyan észleli az identitásszolgáltató, hogy egy felhasználó melyik bérlőhöz fér hozzá?
  • Hogyan továbbítja az identitásszolgáltató a bérlőazonosítót az alkalmazásnak? A rendszer gyakran hozzáad egy bérlőazonosító jogcímet a jogkivonathoz.

Ha egyetlen felhasználónak több bérlőhöz kell hozzáférést biztosítani, akkor a következő döntéseket kell megfontolnia:

  • Hogyan azonosítja és adja meg a megoldás az engedélyeket egy olyan felhasználónak, aki több bérlőhöz fér hozzá? Lehet például, hogy egy felhasználó rendszergazda egy betanítási bérlőben, és írásvédett hozzáféréssel rendelkezik egy éles bérlőhöz? Vagy rendelkezhet külön bérlőkkel a szervezet különböző részlegeihez, de konzisztens felhasználói identitásokat kell fenntartania az összes bérlőben?
  • Hogyan vált egy felhasználó a bérlők között?
  • Ha számítási feladatok identitását használja, hogyan határozza meg a számítási feladat identitása azt a bérlőt, amelyhez hozzá kell férnie?
  • Van olyan bérlőspecifikus információ a felhasználó identitásrekordjában, amely információkat szivárogtathat ki a bérlők között? Tegyük fel például, hogy egy felhasználó regisztrált egy közösségi identitással, majd hozzáférést kapott két bérlőhöz. Az A bérlő további információkkal bővítette a felhasználó identitását. A B bérlőnek hozzáféréssel kell rendelkeznie a bővített információkhoz?

Felhasználói regisztrációs folyamat helyi identitásokhoz vagy közösségi identitásokhoz

Előfordulhat, hogy egyes bérlőknek engedélyezniük kell a felhasználóknak, hogy regisztráljanak egy identitásra a megoldásban. Önkiszolgáló regisztrációra lehet szükség, ha nincs szükség a bérlő identitásszolgáltatójával való összevonásra. Ha önaláírási folyamatra van szükség, fontolja meg a következő kérdéseket:

  • Mely identitásforrásokból regisztrálhatnak a felhasználók? Létrehozhat például egy felhasználó egy helyi identitást, és használhat közösségi identitásszolgáltatót is?
  • Ha csak helyi identitások engedélyezettek, csak adott e-mail-tartományok engedélyezettek? Megadhatja például egy bérlő, hogy csak az e-mail-címmel rendelkező @contoso.com felhasználók regisztráljanak?
  • Mi az a felhasználónév (UPN), amelyet a bejelentkezési folyamat során az egyes helyi identitások egyedi azonosításához kell használni? Az UPN-ekhez például gyakran használt e-mail-cím, felhasználónév, telefonszám és jutalomkártyaszám. Az UPN-k azonban idővel változhatnak. Ha az alkalmazás engedélyezési szabályaiban vagy naplóiban szereplő identitásra hivatkozik, célszerű az identitás mögöttes nem módosítható egyedi azonosítóját használni. A Microsoft Entra ID egy objektumazonosítót (OID) biztosít, amely nem módosítható azonosító.
  • A felhasználónak ellenőriznie kell az upn-et? Ha például a felhasználó e-mail-címét vagy telefonszámát egyszerű felhasználónévként használják, hogyan fogja ellenőrizni, hogy az adatok pontosak-e?
  • A bérlői rendszergazdáknak jóvá kell hagyniuk a regisztrációkat?
  • A bérlőknek bérlőspecifikus regisztrációs felületre vagy URL-címre van szükségük? A bérlőknek például védjegyes regisztrációs felületre van szükségük, amikor a felhasználók regisztrálnak? A bérlőknek szükségük van arra, hogy elfogjanak egy regisztrációs kérést, és további ellenőrzést hajtsanak végre a folytatás előtt?

Bérlői hozzáférés önkiszolgáló felhasználók számára

Amikor a felhasználók regisztrálhatják magukat egy identitásra, általában szükség van egy folyamatra, hogy hozzáférést kapjanak egy bérlőhöz. A regisztrációs folyamat tartalmazhat hozzáférés-engedélyezési folyamatot, vagy automatizálható a felhasználók adatai, például az e-mail-címük alapján. Fontos, hogy megtervezze ezt a folyamatot, és fontolja meg a következő kérdéseket:

  • Hogyan határozza meg a regisztrációs folyamat, hogy egy felhasználónak hozzáférést kell biztosítani egy adott bérlőhöz?
  • Ha a felhasználóknak már nincs hozzáférésük egy bérlőhöz, a megoldás automatikusan visszavonja a hozzáférést? Ha például a felhasználók elhagynak egy szervezetet, szükség van egy manuális vagy automatizált folyamatra, amely eltávolítja a hozzáférésüket a bérlőről.
  • Meg kell adnia egy módot a bérlők számára a bérlői hozzáféréssel és engedélyekkel rendelkező felhasználók naplózására?

Automatizált fiókéletciklus-kezelés

A megoldások vállalati vagy nagyvállalati ügyfeleinek gyakori követelménye az olyan funkciók készlete, amelyek lehetővé teszik számukra a fiókok előkészítésének és beléptetésének automatizálását. A nyílt protokollok, például a tartományközi identitáskezelés (SCIM) iparági szintű megközelítést biztosítanak az automatizáláshoz. Ez az automatizált folyamat általában nem csak az identitásrekordok létrehozását és eltávolítását, hanem a bérlői engedélyek kezelését is magában foglalja. Vegye figyelembe a következő kérdéseket, amikor automatizált fiók életciklus-felügyeletet implementál egy több-bérlős megoldásban:

  • Az ügyfeleknek bérlőnkénti automatizált életciklus-folyamatot kell konfigurálnia és kezelnie? Ha például egy felhasználót előkészítenek, előfordulhat, hogy több bérlőn belül kell létrehoznia az identitást az alkalmazásban, ahol mindegyik bérlő eltérő engedélykészlettel rendelkezik.
  • Végre kell hajtania az SCIM-et, vagy meg tudja adni a bérlői összevonást, hogy a helyi felhasználók kezelése helyett a bérlő felügyelete alatt tartsa a felhasználók igazságforrását?

Felhasználói hitelesítési folyamat

Amikor egy felhasználó bejelentkezik egy több-bérlős alkalmazásba, az identitásrendszer hitelesíti a felhasználót. A hitelesítési folyamat megtervezésekor érdemes megfontolnia a következő kérdéseket:

  • A bérlőknek konfigurálniuk kell a saját többtényezős hitelesítési (MFA-) szabályzataikat? Ha például a bérlői a pénzügyi szolgáltatási ágazatban vannak, szigorú MFA-szabályzatokat kell implementálniuk, míg egy kis online kiskereskedőnek nem feltétlenül ugyanazok a követelmények.
  • A bérlőknek saját feltételes hozzáférési szabályokat kell konfigurálniuk? Előfordulhat például, hogy a különböző bérlőknek blokkolnia kell a bejelentkezési kísérleteket adott földrajzi régiókból.
  • A bérlőknek testre kell szabni az egyes bérlők bejelentkezési folyamatát? Például meg kell jelenítenie egy ügyfél emblémáját? Vagy az egyes felhasználók adatait ki kell nyerni egy másik rendszerből, például jutalomszámból, és vissza kell adni az identitásszolgáltatónak a felhasználói profilhoz való hozzáadáshoz?
  • A felhasználóknak más felhasználókat kell megszemélyesítenie? Előfordulhat például, hogy egy támogatási csapattag egy másik felhasználó által észlelt problémát szeretne kivizsgálni úgy, hogy megszemélyesíti a felhasználói fiókját anélkül, hogy hitelesítést kellene végeznie felhasználóként.
  • A felhasználóknak hozzáférést kell szereznie a megoldás API-ihoz? Előfordulhat például, hogy a felhasználóknak vagy külső alkalmazásoknak közvetlenül meg kell hívniuk az API-kat a megoldás kiterjesztése érdekében, anélkül, hogy felhasználói felület lenne a hitelesítési folyamat biztosításához.

Számítási feladatok identitásai

A legtöbb megoldásban az identitás gyakran egy felhasználót jelöl. Egyes több-bérlős rendszerek lehetővé teszik a számítási feladatok identitásainak használatát a szolgáltatások és alkalmazások számára, hogy hozzáférjenek az alkalmazás erőforrásaihoz. Előfordulhat például, hogy a bérlőknek hozzá kell férniük a megoldás által biztosított API-hoz, hogy automatizálhassák a felügyeleti feladataik egy részét.

A számítási feladatok identitásai hasonlóak a felhasználói identitásokhoz, de általában különböző hitelesítési módszereket, például kulcsokat vagy tanúsítványokat igényelnek. A számítási feladatok identitásai nem használják az MFA-t. Ehelyett a számítási feladatok identitásai általában más biztonsági vezérlőket igényelnek, például a kulcsok rendszeres gördülését és a tanúsítványok lejáratát.

Ha a bérlők várhatóan engedélyezik a számítási feladatok identitásának hozzáférését a több-bérlős megoldáshoz, vegye figyelembe az alábbi kérdéseket:

  • Hogyan jönnek létre és kezelhetők a számítási feladatok identitásai az egyes bérlőkben?
  • Hogyan terjednek ki a számítási feladatok identitáskérései a bérlőre?
  • Korlátoznia kell az egyes bérlők által létrehozott számítási feladatok identitásainak számát?
  • Szükség van feltételes hozzáférés-vezérlésre az egyes bérlők számítási feladat-identitásaihoz? Előfordulhat például, hogy egy bérlő korlátozni szeretné a számítási feladatok identitásának hitelesítését egy adott régión kívülről.
  • Mely biztonsági vezérlőket fogja biztosítani a bérlőknek a számítási feladatok identitásának biztonságossá tételéhez? Például az automatizált kulcsgördülés, a kulcs lejárata, a tanúsítvány lejárata és a bejelentkezési kockázat monitorozása a kockázat csökkentésének összes módszere, ahol a számítási feladatok identitása visszaélhet.

Összevonás identitásszolgáltatóval egyszeri bejelentkezéshez (SSO)

Azok a bérlők, akik már rendelkeznek saját felhasználói könyvtárakkal, előfordulhat, hogy a megoldás összevonást szeretne a címtáraikhoz. Az összevonás lehetővé teszi, hogy a megoldás a címtárukban lévő identitásokat használja ahelyett, hogy egy másik, különálló identitásokkal rendelkező könyvtárat kezel.

Az összevonás különösen akkor fontos, ha egyes bérlők saját identitásszabályzatokat szeretnének megadni, vagy egyszeri bejelentkezést (SSO) szeretnének engedélyezni.

Ha azt várja, hogy a bérlők összevonják a megoldást, vegye figyelembe az alábbi kérdéseket:

  • Mi a bérlő összevonásának konfigurálásának folyamata? Konfigurálhatják maguk a bérlők az összevonást, vagy a folyamathoz manuális konfigurálásra és karbantartásra van szükség a csapat által?
  • Mely összevonási protokollokat fogja támogatni?
  • Milyen folyamatok vannak érvényben annak biztosítása érdekében, hogy az összevonás ne legyen helytelenül konfigurálva, hogy hozzáférést biztosítson egy másik bérlőnek?
  • Egyetlen bérlő identitásszolgáltatóját több bérlőhöz kell összevonni a megoldásban? Ha például az ügyfelek rendelkeznek betanítási és éles bérlővel is, előfordulhat, hogy ugyanazt az identitásszolgáltatót kell összevonniuk mindkét bérlővel.

Engedélyezési modellek

Döntse el, hogy melyik engedélyezési modell a legmegfelelőbb a megoldáshoz. Két gyakori engedélyezési módszer:

  • Szerepköralapú engedélyezés. A felhasználók szerepkörökhöz vannak rendelve. Az alkalmazás egyes funkciói meghatározott szerepkörökre korlátozódnak. A rendszergazdai szerepkörben lévő felhasználók például bármilyen műveletet végrehajthatnak, míg egy alacsonyabb szerepkörű felhasználó a teljes rendszerben rendelkezhet engedélyek egy részhalmazával.
  • Erőforrás-alapú engedélyezés. A megoldás különböző erőforrásokat biztosít, amelyek mindegyike saját engedélykészlettel rendelkezik. Előfordulhat, hogy egy adott felhasználó egy erőforrás rendszergazdája, és nem rendelkezik hozzáféréssel egy másik erőforráshoz.

Ezek a modellek eltérőek, és a választott megközelítés hatással van a megvalósításra és a megvalósítható engedélyezési szabályzatok összetettségére.

További információ: Szerepköralapú és erőforrás-alapú engedélyezés.

Jogosultságok és licencelés

Egyes megoldásokban felhasználónkénti licencelést használhat a kereskedelmi díjszabási modell részeként. Különböző szintű felhasználói licenceket biztosítana különböző képességekkel. Az egy licenccel rendelkező felhasználók például használhatják az alkalmazás funkcióinak egy részét. Azokat a képességeket, amelyekhez adott felhasználók hozzáférhetnek a licenceik alapján, néha jogosultságnak is nevezik.

Bár a jogosultságok nyomon követése és érvényesítése hasonló az engedélyezéshez, általában az alkalmazáskód vagy egy dedikált jogosultsági rendszer kezeli, nem pedig az identitásrendszer kezeli.

Identitásméret és hitelesítési kötet

A több-bérlős megoldások növekedésével nő a megoldás által feldolgozandó felhasználók és bejelentkezési kérelmek száma. Vegye figyelembe a következő kérdéseket:

  • A felhasználói címtár a szükséges felhasználók számára lesz skálázva?
  • A hitelesítési folyamat kezeli a bejelentkezések és a regisztrációk várt számát?
  • Lesznek olyan csúcsok, amelyeket a hitelesítési rendszer nem tud kezelni? Például 9:00-kor a nyugati Egyesült Államok régióban mindenki elkezdhet dolgozni, és bejelentkezhet a megoldásba, ami megugrik a bejelentkezési kérelmekben. Ezeket a helyzeteket néha bejelentkezési viharoknak is nevezik.
  • Befolyásolhatja a megoldás más részeinek magas terhelése a hitelesítési folyamat teljesítményét? Ha például a hitelesítési folyamat alkalmazásszintű API-ba való behívást igényel, a nagy számú hitelesítési kérés problémákat okoz a megoldás többi része számára?
  • Mi történik, ha az identitásszolgáltató elérhetetlenné válik? Van olyan biztonsági mentési hitelesítési szolgáltatás, amely átveheti az üzletmenet folytonosságát, miközben az identitásszolgáltató nem érhető el?

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerzők:

Egyéb közreműködők:

Következő lépések

Tekintse át a több-bérlős megoldások identitáskezelési megközelítéseit.