Çok kiracılı bir çözümde kimlikle ilgili mimari konular

  • Makale

Kimlik, çok kiracılı çözümlerin önemli bir yönüdür. Uygulamanızın kimlik bileşenleri aşağıdakilerin her ikisinde de sorumludur:

  • Kullanıcının kim olduğunu doğrulama (kimlik doğrulaması).
  • Kullanıcının izinlerini bir kiracı (yetkilendirme) kapsamında zorunlu tutma.

Müşterileriniz ayrıca dış uygulamaları verilerine erişmeleri veya çözümünüzle tümleştirmeleri için yetkilendirmek isteyebilir. Kullanıcının kimliği, bir kullanıcının veya hizmetin hangi bilgilere erişeceğini belirler. Uygulamanızı ve verilerinizi kiracılar arasında yalıtmak için kimlik gereksinimlerinizi dikkate almanız önemlidir.

Dikkat

Çok kiracılı ve SaaS uygulamalarında kimlik doğrulama ve yetkilendirme hizmetleri genellikle üçüncü taraf kimlik sağlayıcısı (IdP) tarafından sağlanır. Kimlik sağlayıcısı genellikle hizmet olarak kimlik (IDaaS) platformunun ayrılmaz bir parçasıdır.

Kendi IdP'nizi oluşturmak karmaşık, pahalıdır ve güvenli bir şekilde oluşturulması zordur. Kendi kimlik sağlayıcınızı oluşturmak bir kötü modeldir. Bunu önermiyoruz.

Çok kiracılı bir kimlik stratejisi tanımlamadan önce aşağıdaki gereksinimler de dahil olmak üzere hizmetinizin üst düzey kimlik gereksinimlerini dikkate almanız gerekir:

  • Bir kullanıcı veya iş yükü kimlikleri , bir ürün ailesinde tek bir uygulamaya veya birden çok uygulamaya erişmek için kullanılacak mı? Örneğin, perakende ürün ailesinin hem satış noktası uygulaması hem de aynı kimlik çözümünü paylaşan bir envanter yönetimi uygulaması olabilir.
  • OAuth2 ve OpenID Bağlan gibi modern kimlik doğrulaması ve yetkilendirme uygulamayı planlıyor musunuz?
  • Çözümünüz yalnızca kullanıcı arabirimi tabanlı uygulamalarınıza kimlik doğrulaması mı sağlıyor? Ya da kiracılarınıza ve üçüncü taraflara API erişimi de sağlıyor musunuz?
  • Kiracıların kendi IdP'lerine federasyonları gerekecek mi ve her kiracı için birden çok farklı kimlik sağlayıcısının desteklenmesi gerekecek mi? Örneğin, her birinin çözümünüzle birleştirmek istediği Microsoft Entra Id, Auth0 ve Active Directory Federasyon Hizmetleri (AD FS) (ADFS) kiracılarınız olabilir. Protokoller kendi IdP'nizin gereksinimlerini etkilediğinden kiracılarınızın IdP'lerinin hangi federasyon protokollerini destekleyebileceğinizi de anlamanız gerekir.
  • GDPR gibi karşılamaları gereken belirli uyumluluk gereksinimleri var mı?
  • Kiracılarınızın kimlik bilgilerinin belirli bir coğrafi bölgede bulunması gerekiyor mu?
  • Çözümünüzün kullanıcıları, bir kiracıdan veya uygulamanızdaki birden çok kiracıdan gelen verilere erişim ister mi? Kiracılar arasında hızla geçiş yapabilmeleri veya birden çok kiracıdan birleştirilmiş bilgileri görüntülemeleri gerekiyor mu? Örneğin, Azure portalında oturum açmış olan kullanıcılar farklı Azure Etkin Dizinleri ile erişimleri olan abonelikler arasında kolayca geçiş yapabilir.

Üst düzey gereksinimlerinizi oluşturduktan sonra, kullanıcı dizini kaynakları ve kaydolma/oturum açma akışları gibi daha ayrıntılı ayrıntıları ve gereksinimleri planlamaya başlayabilirsiniz.

Kimlik dizini

Çok kiracılı bir çözümün bir kullanıcı veya hizmetin kimliğini doğrulaması ve yetkilendirmesi için, kimlik bilgilerini depolamak için bir yere ihtiyacı vardır. Dizin, her kimlik için yetkili kayıtlar içerebilir veya başka bir kimlik sağlayıcısının dizininde depolanan dış kimliklere başvurular içerebilir.

Çok kiracılı çözümünüz için bir kimlik sistemi tasarlarken, kiracılarınızın ve müşterilerinizin aşağıdaki IdP türlerinden hangisini gerektirebileceğini göz önünde bulundurmanız gerekir:

  • Yerel kimlik sağlayıcısı. Yerel kimlik sağlayıcısı, kullanıcıların kendilerini hizmete kaydolmasına olanak tanır. Kullanıcılar bir kullanıcı adı, e-posta adresi veya ödül kartı numarası gibi bir tanımlayıcı sağlar. Ayrıca parola gibi bir kimlik bilgisi de sağlarlar. IdP hem kullanıcı tanımlayıcısını hem de kimlik bilgilerini depolar.
  • Sosyal kimlik sağlayıcısı. Sosyal kimlik sağlayıcısı, kullanıcıların bir sosyal ağda veya Facebook, Google veya kişisel bir Microsoft hesabı gibi başka bir genel kimlik sağlayıcısında sahip oldukları bir kimliği kullanmalarına olanak tanır.
  • Kiracının Microsoft Entra Kimliğini veya Microsoft 365 dizinini kullanın. Kiracılar zaten kendi Microsoft Entra Id veya Microsoft 365 dizinlerine sahip olabilir ve çözümünüzün kendi dizinlerini çözümünüze erişmek için IdP olarak kullanmasını isteyebilirler. Çözümünüz çok kiracılı bir Microsoft Entra uygulaması olarak derlendiğinde bu yaklaşım mümkündür.
  • Kiracının kimlik sağlayıcısıyla federasyon. Kiracıların Microsoft Entra ID veya Microsoft 365 dışında kendi IdP'leri olabilir ve çözümünüzün bu kimlikle federasyon oluşturmasını isteyebilirler. Federasyon çoklu oturum açma (SSO) deneyimlerini etkinleştirir ve kiracıların kendi kullanıcılarının yaşam döngüsünü ve güvenlik ilkelerini çözümünüzden bağımsız olarak yönetmesini sağlar.

Kiracılarınızın birden çok kimlik sağlayıcısını desteklemesi gerekip gerekmediğini göz önünde bulundurmalısınız. Örneğin, tek bir kiracıda yerel kimlikleri, sosyal kimlikleri ve federasyon kimliklerini desteklemeniz gerekebilir. Şirketler hem kendi çalışanları hem de yükleniciler için bir çözüm kullandığında bu gereksinim yaygındır. Kendi çalışanlarının çözüme erişimi için federasyonu kullanabilir ve ayrıca federasyon IdP'sinde hesabı olmayan yüklenicilere veya konuk kullanıcılara erişim izni verebilir.

Kimlik doğrulaması ve kiracı yetkilendirme bilgilerini depolama

Çok kiracılı bir çözümde, aşağıdaki türler de dahil olmak üzere çeşitli kimlik bilgilerinin nerede depolandığına dikkat etmeniz gerekir:

  • Kiracılarınızın gerektirdiği adlar ve diğer bilgiler de dahil olmak üzere kullanıcı ve hizmet hesaplarıyla ilgili ayrıntılar.
  • Çok faktörlü kimlik doğrulaması (MFA) sağlamak için gereken bilgiler de dahil olmak üzere kullanıcılarınızın kimliğini güvenli bir şekilde doğrulamak için gereken bilgiler.
  • Kiracı rolleri ve izinleri gibi kiracıya özgü bilgiler. Bu bilgiler yetkilendirme için kullanılır.

Dikkat

Kimlik doğrulama işlemlerini kendiniz oluşturmanızı önermiyoruz. Modern IdP'ler bu kimlik doğrulama hizmetlerini uygulamanıza sağlar ve MFA ve koşullu erişim gibi diğer önemli özellikleri de içerir. Kendi kimlik sağlayıcınızı oluşturmak bir kötü modeldir. Bunu önermiyoruz.

Kimlik bilgilerini depolamak için aşağıdaki seçenekleri göz önünde bulundurun:

  • Tüm kimlik ve yetkilendirme bilgilerini IdP dizininde depolayın ve birden çok kiracı arasında paylaşın.
  • Kullanıcı kimlik bilgilerini IdP dizininde depolayın ve yetkilendirme bilgilerini kiracı bilgileriyle birlikte uygulama katmanında depolayın.

Bir kullanıcının kimlik sayısını belirleme

Bir kullanıcı veya iş yükü kimliğinin birden çok kiracının uygulamasına ve verilerine erişmesine izin veren çok kiracılı çözümler için yaygın olarak kullanılır. Çözümünüz için bu yaklaşımın gerekli olup olmadığını göz önünde bulundurun. Öyleyse aşağıdaki soruları dikkate almanız gerekir:

  • Her kişi için tek bir kullanıcı kimliği mi oluşturmanız yoksa her kiracı-kullanıcı bileşimi için ayrı kimlikler mi oluşturmanız gerekir?
    • Mümkün olduğunca her kişi için tek bir kimlik kullanmak en iyisidir. Hem sizin hem çözüm satıcısı olarak hem de kullanıcılarınız için birden çok kullanıcı hesabını yönetmek zorlaşır. Buna ek olarak, modern bir IdP tarafından sunulan akıllı tehdit korumalarının çoğu, her bir kişinin tek bir kullanıcı hesabına sahip olmasını kullanır.
    • Ancak bazı durumlarda, bir kullanıcının birden çok farklı kimlike sahip olması gerekebilir. Örneğin, insanlar sisteminizi hem iş hem de kişisel amaçlarla kullanıyorsa, kullanıcı hesaplarını ayırmak isteyebilirler. Alternatif olarak, kiracılarınızın katı mevzuat veya coğrafi veri depolama gereksinimleri varsa, bir kişinin düzenlemelere veya yasalara uyabilmesi için birden çok kimliği olmasını gerektirebilir.
  • Kiracı başına kimlikler kullanıyorsanız, kimlik bilgilerini birden çok kez depolamaktan kaçının. Kullanıcıların kimlik bilgileri tek bir kimlikte depolanmalıdır ve birden çok kiracının kimlik kayıtlarından aynı kullanıcı kimlik bilgilerine başvurmak için konuk kimlikleri gibi özellikleri kullanmanız gerekir.

Kullanıcılara kiracı verilerine erişim izni verme

Kullanıcıların bir kiracıya nasıl eşleneceklerini düşünün. Örneğin, kaydolma işlemi sırasında, kiracıya ilk kez erişen kişilerin girdiği benzersiz bir davet kodu kullanabilirsiniz. Bazı çözümlerde, kullanıcıların kaydolma e-posta adreslerinin etki alanı adını, ait oldukları kiracıyı tanımlamanın bir yolu olarak kullanabilirsiniz. Alternatif olarak, kullanıcıyı bir kiracıyla eşlemek için kullanıcının kimlik kaydının başka bir özniteliğini de kullanabilirsiniz. Ardından eşlemeyi hem kiracı hem de kullanıcı için temel alınan sabit benzersiz tanımlayıcılara göre depolamanız gerekir.

Çözümünüz tek bir kullanıcının yalnızca tek bir kiracının verilerine erişecek şekilde tasarlandıysa aşağıdaki kararları göz önünde bulundurun:

  • IdP kullanıcının hangi kiracıya eriştiğini nasıl algılar?
  • IdP kiracı tanımlayıcısını uygulamaya nasıl iletmektedir? Genellikle belirteçe bir kiracı tanımlayıcı talebi eklenir.

Tek bir kullanıcıya birden çok kiracıya erişim verilmesi gerekiyorsa aşağıdaki kararları dikkate almanız gerekir:

  • Çözümünüz birden çok kiracıya erişimi olan bir kullanıcıyı nasıl tanımlar ve bu kullanıcıya izin verir? Örneğin, bir kullanıcı eğitim kiracısında yönetici olabilir ve üretim kiracısına salt okunur erişime sahip olabilir mi? Veya bir kuruluştaki farklı departmanlar için ayrı kiracılarınız olabilir, ancak tüm kiracılarda tutarlı kullanıcı kimliklerini korumanız gerekir mi?
  • Bir kullanıcı kiracılar arasında nasıl geçiş yapar?
  • İş yükü kimliklerini kullanıyorsanız, bir iş yükü kimliği erişmesi gereken kiracıyı nasıl belirtir?
  • Kullanıcının kimlik kaydında kiracılar arasında bilgi sızdırabilecek kiracıya özgü bilgiler var mı? Örneğin, bir kullanıcının sosyal kimlikle kaydolmuş olduğunu ve ardından iki kiracıya erişim verildiğini varsayalım. Kiracı A, kullanıcının kimliğini daha fazla bilgiyle zenginleştirmiş. B kiracısının zenginleştirilmiş bilgilere erişmesi gerekir mi?

Yerel kimlikler veya sosyal kimlikler için kullanıcı kayıt işlemi

Bazı kiracıların, kullanıcıların çözümünüzdeki bir kimliğe kaydolmasına izin vermeleri gerekebilir. Kiracının kimlik sağlayıcısıyla federasyona ihtiyacınız yoksa self servis kaydolma gerekebilir. Kendi kendine kaydolma işlemi gerekiyorsa aşağıdaki soruları göz önünde bulundurmanız gerekir:

  • Kullanıcıların hangi kimlik kaynaklarından kaydolmasına izin verilir? Örneğin, bir kullanıcı yerel kimlik oluşturabilir ve aynı zamanda bir sosyal kimlik sağlayıcısı kullanabilir mi?
  • Yalnızca yerel kimliklere izin veriliyorsa, yalnızca belirli e-posta etki alanlarına izin verilir mi? Örneğin, bir kiracı yalnızca e-posta adresi olan @contoso.com kullanıcıların kaydolmasına izin verilebileceğini belirtebilir mi?
  • Oturum açma işlemi sırasında her yerel kimliği benzersiz olarak tanımlamak için kullanılması gereken kullanıcı asıl adı (UPN) nedir? Örneğin, bir e-posta adresi, kullanıcı adı, telefon numarası ve ödül kartı numarası, UPN'ler için yaygın olarak kullanılan seçeneklerdir. Ancak, UPN'ler zaman içinde değişebilir. Uygulamanızın yetkilendirme kurallarında veya denetim günlüklerinde kimliğe başvurduysanız, kimliğin temel alınan sabit benzersiz tanımlayıcısını kullanmak iyi bir uygulamadır. Microsoft Entra Id sabit bir tanımlayıcı olan bir nesne kimliği (OID) sağlar.
  • Kullanıcının UPN'sini doğrulaması gerekecek mi? Örneğin, kullanıcının e-posta adresi veya telefon numarası UPN olarak kullanılıyorsa, bilgilerin doğru olduğunu nasıl doğrularsınız?
  • Kiracı yöneticilerinin kaydolmaları onaylaması gerekiyor mu?
  • Kiracılar kiracıya özgü bir kaydolma deneyimi veya URL mi gerektiriyor? Örneğin kiracılarınız, kullanıcılar kaydolduğunda markalı bir kaydolma deneyimine ihtiyaç duyuyor mu? Kiracılarınız, devam etmeden önce bir kayıt isteğine müdahale etme ve ek doğrulama gerçekleştirme olanağı gerektiriyor mu?

Kendi kendine kaydolan kullanıcılar için kiracı erişimi

Kullanıcıların kendilerini bir kimliğe kaydolmasına izin verildiğinde, genellikle bir kiracıya erişim izni verilmesi için bir işlem olması gerekir. Kaydolma akışı bir erişim verme işlemi içerebilir veya e-posta adresleri gibi kullanıcılar hakkındaki bilgilere göre otomatikleştirilebilir. Bu süreci planlamak ve aşağıdaki soruları göz önünde bulundurmak önemlidir:

  • Kaydolma akışı, kullanıcıya belirli bir kiracıya erişim verilmesi gerektiğini nasıl belirleyecek?
  • Kullanıcıların artık bir kiracıya erişimi olmaması gerekiyorsa çözümünüz erişimlerini otomatik olarak iptal eder mi? Örneğin, kullanıcılar bir kuruluştan ayrıldığında, kiracıdan erişimini kaldıran el ile veya otomatikleştirilmiş bir işlem olması gerekir.
  • Kiracıların, kiracılarına ve izinlerine erişimi olan kullanıcıları denetlemesi için bir yol sağlamanız gerekiyor mu?

Otomatik hesap yaşam döngüsü yönetimi

Bir çözümün kurumsal veya kurumsal müşterileri için yaygın bir gereksinim, hesap ekleme ve şirket dışı eklemeyi otomatikleştirmelerine olanak tanıyan bir dizi özelliktir. Etki Alanları Arası Kimlik Yönetimi (SCIM) için Sistem gibi açık protokoller, otomasyona endüstri standardı bir yaklaşım sağlar. Bu otomatik işlem genellikle yalnızca kimlik kayıtlarının oluşturulmasını ve kaldırılmasını değil, aynı zamanda kiracı izinlerinin yönetimini de içerir. Çok kiracılı bir çözümde otomatik hesap yaşam döngüsü yönetimi uygularken aşağıdaki soruları göz önünde bulundurun:

  • Müşterilerinizin kiracı başına otomatik yaşam döngüsü sürecini yapılandırması ve yönetmesi gerekiyor mu? Örneğin, bir kullanıcı eklendiğinde, her kiracının farklı bir izin kümesine sahip olduğu uygulamanızdaki birden çok kiracıda kimlik oluşturmanız gerekebilir.
  • Kullanıcıların gerçek kaynağını yerel kullanıcıları yönetmek yerine kiracının denetimi altında tutmak için SCIM uygulamanız mı gerekiyor yoksa bunun yerine kiracılar federasyonu sağlayabilir misiniz?

Kullanıcı kimlik doğrulama işlemi

Bir kullanıcı çok kiracılı bir uygulamada oturum açtığında, kimlik sisteminiz kullanıcının kimliğini doğrular. Kimlik doğrulama işleminizi planlarken aşağıdaki soruları göz önünde bulundurmanız gerekir:

  • Kiracılarınızın kendi çok faktörlü kimlik doğrulaması (MFA) ilkelerini yapılandırması gerekiyor mu? Örneğin, kiracılarınız finansal hizmetler sektöründeyse katı MFA ilkeleri uygulaması gerekirken, küçük bir çevrimiçi perakendeci aynı gereksinimlere sahip olmayabilir.
  • Kiracılarınızın kendi koşullu erişim kurallarını yapılandırması gerekiyor mu? Örneğin, farklı kiracıların belirli coğrafi bölgelerden gelen oturum açma girişimlerini engellemesi gerekebilir.
  • Kiracılarınızın her kiracı için oturum açma işlemini özelleştirmesi gerekiyor mu? Örneğin, bir müşterinin logosunu göstermeniz gerekiyor mu? Veya her kullanıcı hakkındaki bilgilerin ödül numarası gibi başka bir sistemden ayıklanması ve kullanıcı profiline eklemek için kimlik sağlayıcısına döndürülmesi gerekiyor mu?
  • Kullanıcılarınızın diğer kullanıcıların kimliğine bürünmek zorunda mı? Örneğin, bir destek ekibi üyesi, kullanıcı olarak kimlik doğrulaması yapmak zorunda kalmadan kullanıcı hesabının kimliğine bürünerek başka bir kullanıcının yaşadığı sorunu araştırmak isteyebilir.
  • Kullanıcılarınızın çözümünüz için API'lere erişmesi gerekiyor mu? Örneğin, kullanıcıların veya üçüncü taraf uygulamaların, kimlik doğrulama akışı sağlamak için kullanıcı arabirimi olmadan çözümünüzü genişletmek için API'lerinizi doğrudan çağırması gerekebilir.

İş yükü kimlikleri

Çoğu çözümde kimlik genellikle bir kullanıcıyı temsil eder. Bazı çok kiracılı sistemler, uygulama kaynaklarınıza erişim elde etmek için hizmetler ve uygulamalar tarafından iş yükü kimliklerinin kullanılmasına da olanak tanır. Örneğin, kiracılarınızın bazı yönetim görevlerini otomatikleştirebilmeleri için çözümünüz tarafından sağlanan bir API'ye erişmesi gerekebilir.

İş yükü kimlikleri kullanıcı kimliklerine benzer, ancak genellikle anahtarlar veya sertifikalar gibi farklı kimlik doğrulama yöntemleri gerektirir. İş yükü kimlikleri MFA kullanmaz. Bunun yerine, iş yükü kimlikleri genellikle normal anahtar sıralı ve sertifika süre sonu gibi diğer güvenlik denetimlerini gerektirir.

Kiracılarınız çok kiracılı çözümünüz için iş yükü kimliği erişimini etkinleştirebilmeyi bekliyorsa aşağıdaki soruları göz önünde bulundurmanız gerekir:

  • her kiracıda iş yükü kimlikleri nasıl oluşturulacak ve yönetilecek?
  • İş yükü kimlik isteklerinin kapsamı kiracı olarak nasıl belirlenir?
  • Her kiracı tarafından oluşturulan iş yükü kimliklerinin sayısını sınırlamanız gerekiyor mu?
  • Her kiracı için iş yükü kimlikleri üzerinde koşullu erişim denetimleri sağlamanız gerekiyor mu? Örneğin, bir kiracı iş yükü kimliğinin belirli bir bölge dışından doğrulanmasını sınırlamak isteyebilir.
  • İş yükü kimliklerinin güvenli kalmasını sağlamak için kiracılara hangi güvenlik denetimlerini sağlayacaksınız? Örneğin, otomatik anahtar alma, anahtar süre sonu, sertifika süre sonu ve oturum açma riski izleme, bir iş yükü kimliğinin kötüye kullanılabilmesi için riski azaltmanın tüm yöntemleridir.

Çoklu oturum açma (SSO) için bir kimlik sağlayıcısıyla federasyon

Zaten kendi kullanıcı dizinleri olan kiracılar, çözümünüzün kendi dizinlerine federasyon oluşturmasını isteyebilir. Federasyon, çözümünüzün farklı kimliklerle başka bir dizini yönetmek yerine kendi dizinindeki kimlikleri kullanmasına olanak tanır.

Federasyon özellikle bazı kiracılar kendi kimlik ilkelerini belirtmek veya çoklu oturum açma (SSO) deneyimlerini etkinleştirmek istediğinde önemlidir.

Kiracıların çözümünüzle federasyon oluşturmasını bekliyorsanız aşağıdaki soruları göz önünde bulundurmanız gerekir:

  • Kiracı için federasyonu yapılandırma işlemi nedir? Kiracılar federasyonu kendileri yapılandırabilir mi yoksa süreç ekibiniz tarafından el ile yapılandırma ve bakım gerektirebilir mi?
  • Hangi federasyon protokollerini destekleyeceksiniz?
  • Başka bir kiracıya erişim vermek için federasyonun yanlış yapılandırılmamasını sağlamak için hangi işlemler gerçekleştirilir?
  • Tek bir kiracının kimlik sağlayıcısının çözümünüzde birden fazla kiracıya federasyon olması gerekecek mi? Örneğin, müşterilerin hem eğitim hem de üretim kiracısı varsa, aynı kimlik sağlayıcısını her iki kiracıya da federasyonları gerekebilir.

Yetkilendirme modelleri

Çözümünüz için en mantıklı yetkilendirme modeline karar verin. İki yaygın yetkilendirme yaklaşımı şunlardır:

  • Rol tabanlı yetkilendirme. Kullanıcılar rollere atanır. Uygulamanın bazı özellikleri belirli rollerle sınırlıdır. Örneğin, yönetici rolündeki bir kullanıcı herhangi bir eylemi gerçekleştirebilirken, daha düşük bir roldeki bir kullanıcı sistem genelinde bir izin alt kümesine sahip olabilir.
  • Kaynak tabanlı yetkilendirme. Çözümünüz, her birinin kendi izin kümesine sahip olan bir dizi farklı kaynak sağlar. Belirli bir kullanıcı bir kaynağın yöneticisi olabilir ve başka bir kaynağa erişimi olmayabilir.

Bu modeller ayrıdır ve seçtiğiniz yaklaşım uygulamanızı ve uygulayabileceğiniz yetkilendirme ilkelerinin karmaşıklığını etkiler.

Daha fazla bilgi için bkz . Rol tabanlı ve kaynak tabanlı yetkilendirme.

Yetkilendirmeler ve lisanslama

Bazı çözümlerde, ticari fiyatlandırma modelinizin bir parçası olarak kullanıcı başına lisanslama kullanabilirsiniz. Farklı özelliklere sahip farklı kullanıcı lisans katmanları sağlarsınız. Örneğin, bir lisansı olan kullanıcıların uygulama özelliklerinin bir alt kümesini kullanmasına izin verilebileceğini varsayabilir. Belirli kullanıcıların lisanslarına göre erişmesine izin verilen özelliklere bazen yetkilendirme adı verilir.

Yetkilendirmeleri izleme ve zorlama yetkilendirmeye benzer olsa da, genellikle kimlik sistemi tarafından yönetmek yerine uygulama kodu veya ayrılmış yetkilendirmeler sistemi tarafından işlenir.

Kimlik ölçeklendirme ve kimlik doğrulama hacmi

Çok kiracılı çözümler arttıkça, çözüm tarafından işlenmesi gereken kullanıcı ve oturum açma isteklerinin sayısı artar. Aşağıdaki soruları dikkate almanız gerekir:

  • Kullanıcı dizini gereken kullanıcı sayısına ölçeklendirilecek mi?
  • Kimlik doğrulama işlemi beklenen sayıda oturum açma ve kaydolma işlemini işleyecek mi?
  • Kimlik doğrulama sisteminin işleyebildiği ani artışlar olacak mı? Örneğin, 09:00 PST'de batı Birleşik Devletler bölgesindeki herkes çalışmaya başlayabilir ve çözümünüzde oturum açarak oturum açma isteklerinde ani artışa neden olabilir. Bu durumlara bazen oturum açma fırtınaları denir.
  • Çözümünüzün diğer bölümlerindeki yüksek yük, kimlik doğrulama işleminin performansını etkileyebilir mi? Örneğin, kimlik doğrulama işleminiz bir uygulama katmanı API'sine çağrı yapılmasını gerektiriyorsa, çözümünüzün geri kalanında çok sayıda kimlik doğrulama isteği sorunlara neden olur mu?
  • IdP'niz kullanılamaz duruma gelirse ne olur? IdP kullanılamaz durumdayken iş sürekliliği sağlamak için devralabilecek bir yedekleme kimlik doğrulama hizmeti var mı?

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazarlar:

Diğer katkıda bulunanlar:

Sonraki adımlar

Çok kiracılı çözümlerde kimlik için mimari yaklaşımları gözden geçirin.