Összevont identitás mintájaFederated Identity pattern

A hitelesítést delegálhatja egy külső identitásszolgáltatónak.Delegate authentication to an external identity provider. Ezzel leegyszerűsítheti a fejlesztést, minimalizálhatja a szükséges felhasználói adminisztrációt és javíthatja az alkalmazás felhasználói élményét.This can simplify development, minimize the requirement for user administration, and improve the user experience of the application.

Kontextus és problémaContext and problem

A felhasználóknak általában több, különböző üzleti partner által biztosított és üzemeltetett alkalmazást kell használniuk.Users typically need to work with multiple applications provided and hosted by different organizations they have a business relationship with. Előfordulhat, hogy ezeknek a felhasználóknak mindegyikhez adott (eltérő) hitelesítő adatokat kell használniuk.These users might be required to use specific (and different) credentials for each one. Mindez:This can:

  • Nem egységes felhasználói élményt okozhat.Cause a disjointed user experience. A felhasználók gyakran elfelejtik a bejelentkezési hitelesítő adataikat, ha sok különböző adatot kell kezelniük.Users often forget sign-in credentials when they have many different ones.

  • Biztonsági réseket idézhet elő.Expose security vulnerabilities. Ha egy felhasználó kilép a cégtől, a fiókját azonnal meg kell szüntetni.When a user leaves the company the account must immediately be deprovisioned. Nagy cégeknél erről könnyű megfeledkezni.It's easy to overlook this in large organizations.

  • Bonyolítja a felhasználókezelést.Complicate user management. A rendszergazdáknak kell kezelniük az összes felhasználó hitelesítő adatait, és pluszfeladatokat (például jelszó-emlékeztetők küldését) kell elvégezniük.Administrators must manage credentials for all of the users, and perform additional tasks such as providing password reminders.

A felhasználók általában jobban szeretnék ugyanazokat a hitelesítő adatokat használni az összes alkalmazáshoz.Users typically prefer to use the same credentials for all these applications.

MegoldásSolution

Használjon összevont identitás használatára képes hitelesítési mechanizmust.Implement an authentication mechanism that can use federated identity. Különítse el a felhasználói hitelesítést az alkalmazáskódtól, és delegálja a hitelesítést egy megbízható identitásszolgáltatóra.Separate user authentication from the application code, and delegate authentication to a trusted identity provider. Ezzel leegyszerűsítheti a fejlesztést, és lehetővé teheti, hogy a felhasználók szélesebb palettáról válasszanak identitásszolgáltatót a hitelesítéshez, és közben a lehető legkisebbre csökkentsék az adminisztratív terhelést.This can simplify development and allow users to authenticate using a wider range of identity providers (IdP) while minimizing the administrative overhead. Azt is lehetővé teszi, hogy egyértelműen elválassza a hitelesítést az engedélyezéstől.It also allows you to clearly decouple authentication from authorization.

A megbízható identitásszolgáltatók között vannak céges címtárak, helyszíni összevonási szolgáltatások, külső üzleti partnerek által biztosított biztonsági jegykiadó szolgáltatások (STS), vagy éppen közösségi identitásszolgáltatók, amelyek képesek kezelni például a Microsoft-, Google-, Yahoo!- vagy Facebook-fiókkal rendelkező felhasználók hitelesítését.The trusted identity providers include corporate directories, on-premises federation services, other security token services (STS) provided by business partners, or social identity providers that can authenticate users who have, for example, a Microsoft, Google, Yahoo!, or Facebook account.

Az ábra az összevont identitás mintáját mutatja be, amikor egy ügyfélnek épp egy hitelesítést igénylő szolgáltatáshoz kell hozzáférnie.The figure illustrates the Federated Identity pattern when a client application needs to access a service that requires authentication. A hitelesítést egy STS-sel együttműködő identitásszolgáltató hajtja végre.The authentication is performed by an IdP that works in concert with an STS. Az identitásszolgáltató a hitelesített felhasználóról információt szolgáltató biztonsági jogkivonatokat ad ki.The IdP issues security tokens that provide information about the authenticated user. Ez a jogcímnek is nevezett információ tartalmazza a felhasználó identitását, és tartalmazhat más adatokat is, például a szerepkörtagságot és részletesebb hozzáférési jogosultságokat.This information, referred to as claims, includes the user’s identity, and might also include other information such as role membership and more granular access rights.

Az összevont hitelesítés áttekintése

Ezt a modellt gyakran nevezik jogcímalapú hozzáférés-vezérlésnek.This model is often called claims-based access control. Az alkalmazások és a szolgáltatások a jogkivonatban található jogcímek alapján engednek hozzáférést a szolgáltatásokhoz és funkciókhoz.Applications and services authorize access to features and functionality based on the claims contained in the token. A hitelesítést igénylő szolgáltatásnak meg kell bíznia az identitásszolgáltatóban.The service that requires authentication must trust the IdP. Az ügyfélalkalmazás kapcsolatba lép a hitelesítést elvégző identitásszolgáltatóval.The client application contacts the IdP that performs the authentication. Ha a hitelesítés sikeres, az identitásszolgáltató a felhasználót azonosító jogcímeket tartalmazó jogkivonatot ad vissza az STS-nek (tartsa szem előtt, hogy az identitásszolgáltató és az STS lehet ugyanaz a szolgáltatás is).If the authentication is successful, the IdP returns a token containing the claims that identify the user to the STS (note that the IdP and STS can be the same service). Az STS az ügyfélnek való visszaadás előtt előre meghatározott szabályok alapján átalakíthatja és kiegészítheti a jogcímeket.The STS can transform and augment the claims in the token based on predefined rules, before returning it to the client. Az ügyfélalkalmazás ezután továbbíthatja ezt a jogkivonatot a szolgáltatásnak az identitása bizonyítékaként.The client application can then pass this token to the service as proof of its identity.

A megbízhatósági láncban további biztonsági jogkivonat-szolgáltatások is előfordulhatnak.There might be additional security token services in the chain of trust. A később ismertetett forgatókönyvben például egy helyszíni STS megbízik egy másik, a felhasználó hitelesítése céljából egy identitásszolgáltatóhoz való hozzáférésért felelős STS-ben.For example, in the scenario described later, an on-premises STS trusts another STS that is responsible for accessing an identity provider to authenticate the user. Ez a megközelítés gyakori nagyvállalati forgatókönyvekben, ahol van helyszíni STS és címtár is.This approach is common in enterprise scenarios where there's an on-premises STS and directory.

Az összevont hitelesítés szabványalapú megoldást nyújt a különböző tartományokban található identitásokba fektetett bizalom problémájára, és képes az egyszeri bejelentkezés támogatására.Federated authentication provides a standards-based solution to the issue of trusting identities across diverse domains, and can support single sign-on. Minden típusú alkalmazásnál egyre elterjedtebb, különösen a felhőalapú alkalmazásoknál, mert anélkül támogatja az egyszeri bejelentkezést, hogy közvetlen hálózati kapcsolatot igényelne az identitásszolgáltatókhoz.It's becoming more common across all types of applications, especially cloud-hosted applications, because it supports single sign-on without requiring a direct network connection to identity providers. A felhasználónak nem kell minden alkalmazáshoz megadnia a hitelesítő adatait.The user doesn't have to enter credentials for every application. Ez növeli a biztonságot, mivel nem kell létrehozni a sok különböző alkalmazáshoz való hozzáféréshez szükséges hitelesítő adatokat, és az eredeti identitásszolgáltatón kívül minden alkalmazás elől elrejthetők a felhasználó hitelesítő adatai.This increases security because it prevents the creation of credentials required to access many different applications, and it also hides the user’s credentials from all but the original identity provider. Az alkalmazások csak a jogkivonatban található hitelesített identitásadatokat látják.Applications see just the authenticated identity information contained within the token.

Az összevont identitásnak az is nagy előnye, hogy az identitás és a hitelesítő adatok kezelése az identitásszolgáltató felelőssége.Federated identity also has the major advantage that management of the identity and credentials is the responsibility of the identity provider. Az alkalmazásnak vagy szolgáltatásnak nem kell identitáskezelési funkciókat biztosítania.The application or service doesn't need to provide identity management features. Ezenfelül céges forgatókönyvekben a céges címtárnak nem kell tudnia a felhasználóról, ha megbízik az identitásszolgáltatóban.In addition, in corporate scenarios, the corporate directory doesn't need to know about the user if it trusts the identity provider. Ezzel megszűnik a felhasználók identitásának címtáron belül való kezelésének adminisztratív terhe.This removes all the administrative overhead of managing the user identity within the directory.

Problémák és megfontolandó szempontokIssues and considerations

Összevont hitelesítést megvalósító alkalmazások tervezésekor vegye figyelembe az alábbiakat:Consider the following when designing applications that implement federated authentication:

  • A hitelesítés kritikus hibapont lehet a rendszeren belül.Authentication can be a single point of failure. Ha több adatközpontba telepíti az alkalmazását, érdemes lehet az identitáskezelő mechanizmust is telepíteni ugyanazokba az adatközpontokba, hogy megmaradjon az alkalmazás megbízhatósága és rendelkezésre állása.If you deploy your application to multiple datacenters, consider deploying your identity management mechanism to the same datacenters to maintain application reliability and availability.

  • A hitelesítési eszközök segítségével konfigurálható a hitelesítési jogkivonatban található szerepkörjogcímeken alapuló hozzáférés-vezérlés.Authentication tools make it possible to configure access control based on role claims contained in the authentication token. Ezt gyakran nevezik szerepköralapú hozzáférés-vezérlésnek (RBAC), és részletesebb szintű hozzáférés-vezérlést tesz lehetővé a szolgáltatások és erőforrások vonatkozásában.This is often referred to as role-based access control (RBAC), and it can allow a more granular level of control over access to features and resources.

  • A céges címtáraktól eltérően a közösségi identitásszolgáltatókat használó jogcímalapú hitelesítés az e-mail-címen és esetleg a néven kívül általában nem ad meg más adatot a hitelesített felhasználóról.Unlike a corporate directory, claims-based authentication using social identity providers doesn't usually provide information about the authenticated user other than an email address, and perhaps a name. Néhány közösségi identitásszolgáltató – például egy Microsoft-fiók – csak egy egyedi azonosítót biztosít.Some social identity providers, such as a Microsoft account, provide only a unique identifier. Az alkalmazásnak általában kezelnie kell néhány adatot a regisztrált felhasználókról, és képesnek kell lennie megfeleltetni ezt az információt a jogkivonat jogcímeiben tárolt azonosítóval.The application usually needs to maintain some information on registered users, and be able to match this information to the identifier contained in the claims in the token. Ezt általában a regisztráció során szerzi be, amikor a felhasználó először használja az alkalmazást, majd az adatok további jogcímekként kerülnek be a jogkivonatba az egyes hitelesítések után.Typically this is done through registration when the user first accesses the application, and information is then injected into the token as additional claims after each authentication.

  • Ha egynél több identitásszolgáltató van konfigurálva az STS-hez, annak észlelnie kell, hogy melyik identitásszolgáltatóhoz kell átirányítania az adott felhasználót hitelesítésre.If there's more than one identity provider configured for the STS, it must detect which identity provider the user should be redirected to for authentication. Ennek a folyamatnak a kezdőtartomány felderítése a neve.This process is called home realm discovery. Lehetséges, hogy az STS erre képes automatikusan a felhasználó által megadott e-mail-cím vagy felhasználónév, a felhasználó által használni kívánt alkalmazás altartománya, a felhasználó IP-címtartománya vagy egy, a felhasználó böngészőjében tárolt cookie tartalma alapján.The STS might be able to do this automatically based on an email address or user name that the user provides, a subdomain of the application that the user is accessing, the user’s IP address scope, or on the contents of a cookie stored in the user’s browser. Ha például a felhasználó egy Microsoft-tartományba eső e-mail-címet adott meg (pl.: user@live.com), az STS a felhasználót a Microsoft-fiók bejelentkezési oldalára irányítja át.For example, if the user entered an email address in the Microsoft domain, such as user@live.com, the STS will redirect the user to the Microsoft account sign-in page. A későbbi látogatások alkalmával az STS egy cookie segítségével jelezheti, hogy az utolsó bejelentkezés egy Microsoft-fiók segítségével történt.On later visits, the STS could use a cookie to indicate that the last sign in was with a Microsoft account. Ha az automatikus észlelés nem tudja meghatározni a kezdőtartományt, az STS megjelenít egy kezdőtartomány-felderítő oldalt, amely kilistázza a megbízható identitásszolgáltatókat, és a felhasználónak kell kiválasztania, melyiket szeretné igénybe venni.If automatic discovery can't determine the home realm, the STS will display a home realm discovery page that lists the trusted identity providers, and the user must select the one they want to use.

Mikor érdemes ezt a mintát használni?When to use this pattern

Ez a minta például az alábbi forgatókönyvek esetében lehet hasznos:This pattern is useful for scenarios such as:

  • Egyszeri bejelentkezés a vállalatban.Single sign-on in the enterprise. Ebben a forgatókönyvben az alkalmazottakat hitelesíteni kell a felhőben üzemeltetett, vállalati biztonsági határon kívül eső céges alkalmazásokhoz, de nem kell minden alkalommal bejelentkezniük, amikor használnak egy alkalmazást.In this scenario you need to authenticate employees for corporate applications that are hosted in the cloud outside the corporate security boundary, without requiring them to sign in every time they visit an application. A felhasználói élmény ugyanaz, mint a helyszíni alkalmazások használatakor, azaz a hitelesítés egy vállalati hálózatra való bejelentkezéskor történik, és onnantól bejelentkezés nélkül használható az összes releváns alkalmazás.The user experience is the same as when using on-premises applications where they're authenticated when signing in to a corporate network, and from then on have access to all relevant applications without needing to sign in again.

  • Összevont identitás több partnerrel.Federated identity with multiple partners. Ebben a forgatókönyvben a céges alkalmazottakat és a céges címtárban fiókkal nem rendelkező üzleti partnereket is hitelesítenie kell.In this scenario you need to authenticate both corporate employees and business partners who don't have accounts in the corporate directory. Ez a gyakori a cégek közötti alkalmazások és a külső szolgáltatást integráló alkalmazások esetében, valamint olyan helyzetben, amely során különböző informatikai rendszert alkalmazó vállalatok egyesülnek vagy megosztják az erőforrásaikat.This is common in business-to-business applications, applications that integrate with third-party services, and where companies with different IT systems have merged or shared resources.

  • Összevont identitás SaaS-alkalmazásokban.Federated identity in SaaS applications. Ebben a forgatókönyvben független szoftvergyártók biztosítanak használatra kész szolgáltatást több ügyfélnek vagy bérlőnek.In this scenario independent software vendors provide a ready-to-use service for multiple clients or tenants. Mindegyik bérlő egy megfelelő identitásszolgáltató használatával végzi el a hitelesítést.Each tenant authenticates using a suitable identity provider. Az üzleti felhasználók például a céges hitelesítő adatokat fogják használni, a bérlő felhasználói és ügyfelei pedig a közösségi identitásuk hitelesítő adatait.For example, business users will use their corporate credentials, while consumers and clients of the tenant will use their social identity credentials.

Nem érdemes ezt a mintát használni a következő helyzetekben:This pattern might not be useful in the following situations:

  • Az alkalmazás összes felhasználója hitelesíthető egy identitásszolgáltatóval, és nincs szükség más identitásszolgáltatóval való hitelesítésre.All users of the application can be authenticated by one identity provider, and there's no requirement to authenticate using any other identity provider. Ez olyan üzleti alkalmazásoknál gyakori, amelyek az alkalmazásból elérhető céges címtárat használnak hitelesítéshez VPN- vagy (felhőben futtatott forgatókönyvek esetében) a helyszíni címtár és az alkalmazás közötti kapcsolatot biztosító virtuális hálózati kapcsolaton keresztül.This is typical in business applications that use a corporate directory (accessible within the application) for authentication, by using a VPN, or (in a cloud-hosted scenario) through a virtual network connection between the on-premises directory and the application.

  • Az alkalmazás eredetileg egy másik hitelesítési mechanizmussal készült, esetleg egyéni felhasználói tárolókkal, vagy nem képes kezelni a jogcímalapú technológiák által használt egyeztetési szabványokat.The application was originally built using a different authentication mechanism, perhaps with custom user stores, or doesn't have the capability to handle the negotiation standards used by claims-based technologies. A jogcímalapú hitelesítés és hozzáférés-vezérlés meglévő alkalmazásokra történő alkalmazása összetett feladat, és valószínűleg nem túl költséghatékony.Retrofitting claims-based authentication and access control into existing applications can be complex, and probably not cost effective.

PéldaExample

Egy cég több-bérlős szolgáltatott szoftvert (SaaS) üzemeltet alkalmazásként a Microsoft Azure-ban.An organization hosts a multi-tenant software as a service (SaaS) application in Microsoft Azure. Az alkalmazás tartalmaz egy webhelyet, amelyet a bérlők használhatnak az alkalmazás a saját felhasználóik számára történő kezeléséhez.The application includes a website that tenants can use to manage the application for their own users. Az alkalmazás lehetővé teszi a bérlők számára, hogy a Active Directory összevonási szolgáltatások (AD FS) (AD FS) által generált összevont identitás használatával hozzáférjenek a webhelyhez, ha a felhasználót a szervezet saját Active Directoryja hitelesíti.The application allows tenants to access the website by using a federated identity that is generated by Active Directory Federation Services (AD FS) when a user is authenticated by that organization’s own Active Directory.

Az alkalmazás elérési módja a felhasználók számára nagyvállalati előfizető esetében

Az ábrán látható, hogy a bérlők hogyan hitelesítik magukat a saját identitás-szolgáltatóval (1. lépés), ebben az esetben AD FS.The figure shows how tenants authenticate with their own identity provider (step 1), in this case AD FS. A bérlő sikeres hitelesítését követően AD FS jogkivonatot bocsát ki.After successfully authenticating a tenant, AD FS issues a token. Az ügyféloldali böngésző továbbítja ezt a tokent a SaaS-alkalmazás összevonási szolgáltatójának, amely megbízik a bérlő AD FS által kiállított jogkivonatokban, hogy visszaszerezze a SaaS összevonási szolgáltató számára érvényes jogkivonatot (2. lépés).The client browser forwards this token to the SaaS application’s federation provider, which trusts tokens issued by the tenant’s AD FS, in order to get back a token that is valid for the SaaS federation provider (step 2). Ha szükséges, a SaaS összevonási szolgáltató a jogkivonatban található jogcímeket az új jogkivonat ügyfélböngészőnek való visszaadása előtt olyan jogcímekké alakítja, amelyeket az alkalmazás felismer (3. lépés).If necessary, the SaaS federation provider performs a transformation on the claims in the token into claims that the application recognizes (step 3) before returning the new token to the client browser. Az alkalmazás megbízik az SaaS összevonási szolgáltató által kiállított jogkivonatokban, és a jogkivonat jogcímeivel alkalmazza az engedélyezési szabályokat (4. lépés).The application trusts tokens issued by the SaaS federation provider and uses the claims in the token to apply authorization rules (step 4).

A bérlőknek nem kell külön hitelesítő adatokat megjegyezniük az alkalmazás eléréséhez, és a bérlő vállalatának rendszergazdája a saját AD FS az alkalmazáshoz hozzáférő felhasználók listáját is konfigurálhatja.Tenants won't need to remember separate credentials to access the application, and an administrator at the tenant’s company can configure in its own AD FS the list of users that can access the application.