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

Kimlik, çok kiracılı çözümlerin önemli bir yönüdür. Uygulamanızın kimlik bileşenleri aşağıdaki görevlerden sorumludur:

• Kimlik doğrulaması olarak bilinen kullanıcının kimliğini doğrulama

• Kullanıcının izinlerini kiracı kapsamında yetkilendirme olarak adlandırılan şekilde uygulama

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 erişebileceği bilgileri belirler. Uygulamanızı ve verilerinizi kiracılar arasında yalıtmak için kimlik gereksinimlerinizi dikkate almanız önemlidir.

Dikkat

Çok kiracılı uygulamalar ve hizmet olarak yazılım (SaaS) uygulamaları içindeki kimlik doğrulama ve yetkilendirme hizmetleri genellikle bir dış kimlik sağlayıcısı (IdP) tarafından sağlanır. IdP genellikle yönetilen kimlik platformunun ayrılmaz bir parçasıdır.

Kendi IdP'nizi oluşturmak karmaşık, pahalı ve güvenli hale getirmek zordur. Bu bir kötü model olarak kabul edilir ve bunu önermiyoruz.

Çok kiracılı bir kimlik stratejisi tanımlamadan önce hizmetiniz için aşağıdaki üst düzey kimlik gereksinimlerini göz önünde bulundurun:

• Kullanıcıların veya iş yükü kimliklerinin tek bir uygulamaya mı yoksa bir ürün ailesi içindeki birden çok uygulamaya mı erişeceğini belirleyin. Bazı ürün aileleri, satış noktası sistemleri ve envanter yönetimi platformları gibi aynı kimlik altyapısını paylaşan farklı uygulamalar içerebilir.

• Çözümünüzün OAuth2 ve OpenID Connect gibi modern kimlik doğrulama ve yetkilendirme standartlarını uygulayıp uygulamadığını göz önünde bulundurun.

• Kimlik doğrulamasının kullanıcı arabirimi tabanlı uygulamalarla sınırlı olup olmadığını veya API erişiminin kiracılar ve üçüncü taraf sistemler için de geçerli olup olmadığını değerlendirin.

• Kiracıların kendi IdP'leriyle federasyona ihtiyaç duyup duymadığını ve her kiracı için birden fazla IdP'nin desteklenmesi gerekip gerekmediğini belirleyin. Örneğin, her kiracının çözümünüzle federe olduğu Microsoft Entra ID, Auth0 ve Active Directory Federasyon Hizmetleri kiracılarınız olabilir. IdP'lerinizin hangi federasyon protokollerini kullandığını belirleyin çünkü bu protokoller IdP'nizin neleri desteklemesi gerektiğini belirler.

• Kimlik stratejinizi şekillendiren Genel Veri Koruma Yönetmeliği (GDPR) gibi karşılamaları gereken geçerli uyumluluk gereksinimlerini gözden geçirin.

• Kiracıların yasal, uyumluluk veya operasyonel gereksinimleri karşılamak için belirli coğrafi bölgelerde kimlik verilerinin depolanmasını gerektirip gerektirmediğini belirleyin.

• Kullanıcıların uygulama içindeki birden çok kiracıdan verilere erişip erişmeyeceğini değerlendirin. Böyle bir durum varsa, belirli kullanıcılar için sorunsuz kiracı geçişlerini desteklemeniz veya kiracılar arasında birleştirilmiş görünümler sağlamanız gerekebilir. Örneğin, Azure portalında oturum açan kullanıcılar, erişimi olan farklı Microsoft Entra ID dizinleri ve abonelikleri arasında kolayca geçiş yapabilir.

Üst düzey gereksinimlerinizi oluştururken, kullanıcı dizini kaynakları, kaydolma ve oturum açma akışları gibi daha belirli 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. Bir dizin, her kimlik için yetkili kayıtlar içerebilir. Veya başka bir IdP 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 IdP: Yerel bir IdP, 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 IdP: Sosyal IdP, kullanıcıların bir sosyal ağda veya Facebook, Google veya kişisel bir Microsoft hesabı gibi başka bir genel IdP'de sahip oldukları bir kimliği kullanmalarına olanak tanır. Sosyal IdP'ler genellikle işletmeden tüketiciye (B2C) SaaS çözümlerinde kullanılır.

• Kiracının Microsoft Entra Id dizini: İşletmeler arası (B2B) birçok SaaS çözümünde kiracıların zaten kendi Microsoft Entra ID dizini olabilir ve çözümünüzün kendi dizinini çö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 IdP'siyle federasyon: Bazı B2B SaaS çözümlerinde kiracıların Microsoft Entra ID dışında kendi IdP'leri olabilir ve çözümünüzün bu kimlikle federasyon oluşturmasını isteyebilirler. Federasyon çoklu oturum açmayı (SSO) etkinleştirir. Ayrıca kiracıların 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 IdP'yi desteklemesi gerekip gerekmediğini göz önünde bulundurmalısınız. Örneğin, tek bir kiracının yerel kimlikleri, sosyal kimlikleri ve federasyon kimliklerini desteklemesi gerekebilir. Şirketler hem çalışanlarına hem de yüklenicilerine yönelik bir çözüm kullandığında bu gereksinim tipiktir. Federasyon, çalışanlara erişim izni verirken, federasyon IdP'sinde hesabı olmayan yüklenicilere veya kullanıcılara erişim izni vermek için de kullanabilir.

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ı hakkındaki ayrıntılar.

• Çok faktörlü kimlik doğrulaması (MFA) bilgileri de dahil olmak üzere kullanıcılarınızın kimliğini güvenli bir şekilde doğrulamak için gereken bilgiler.

• Yetkilendirme için kiracı rolleri ve izinleri gibi kiracıya özgü bilgiler.

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. Yetkilendirme verilerini, kiracı bilgilerinin yanı sıra uygulama katmanında depolayın.

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

Çok kiracılı çözümler genellikle bir kullanıcı veya iş yükü kimliğinin birden çok kiracıda uygulama kaynaklarına ve verilerine erişmesine izin verir. Bu yaklaşım gerektiğinde aşağıdaki faktörleri göz önünde bulundurun:

• Her kişi için tek bir kullanıcı kimliği mi oluşturacağınız yoksa her kiracı-kullanıcı bileşimi için ayrı kimlikler mi oluşturacağınız konusunda karar verin.

  • Mümkün olduğunda her kişi için tek bir kimlik kullanın. Hem çözüm sağlayıcısı hem de kullanıcılar için hesap yönetimini basitleştirir. Ayrıca, modern IDP'lerin sağladığı akıllı tehdit korumalarının birçoğu tek bir kullanıcı hesabına sahip olan her kişiye güvenir.

  • Bazı senaryolarda birden çok farklı kimlik kullanın. Örneğin, insanlar sisteminizi hem iş hem de kişisel amaçlarla kullanıyorsa, kullanıcı hesaplarını ayırmak isteyebilirler. Ya da 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ı bir kiracıyla nasıl eşlemeyi planladığınızı düşünün. Örneğin, kaydolma işlemi sırasında, kullanıcıların bir kiracıya ilk kez eriştiğinde girmeleri için benzersiz bir davet kodu sağlayabilirsiniz. Bazı çözümlerde, kullanıcının kaydolma e-posta adresinin etki alanı adı ilişkili kiracısını tanımlayabilir. Alternatif olarak, kiracı eşlemesini belirlemek için kullanıcının kimlik kaydından başka bir öznitelik kullanabilirsiniz. Bu ilişki daha sonra hem kiracı hem de kullanıcı için sabit, benzersiz tanımlayıcılar temelinde depolanmalıdır.

Çözümünüz her kullanıcıyı tek bir kiracının verilerine erişecek şekilde sınırlıyorsa aşağıdaki kararları göz önünde bulundurun:

• IdP'nin kullanıcının eriştiği kiracıyı nasıl tanımladığını belirleyin.

• IdP'nin kiracı tanımlayıcısını uygulamaya nasıl ileteceklerini açıklayın. Genellikle, bir kiracı kimliği talebi belirteçe eklenir.

Tek bir kullanıcıya birden çok kiracıya erişim verilmesi gerekiyorsa aşağıdaki kararları göz önünde bulundurun:

• Çözüm, kullanıcıları tanımlamak ve kiracılar arasında uygun izinler vermek için mantığı desteklemelidir. Örneğin, bir kullanıcı bir kiracıda yönetici haklarına sahip olabilir, ancak başka bir kiracıda sınırlı erişime sahip olabilir. Ö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?

• Net bir mekanizma, kullanıcıların kiracılar arasında geçiş yapmalarına izin vermelidir. Bu yaklaşım sorunsuz bir kullanıcı deneyimi sağlar ve yanlışlıkla kiracılar arası erişimi engeller.

• İş yükü kimliklerini kullanıyorsanız, erişmeye çalıştıkları kiracıları belirtmeleri gerekir. Bu gereksinim, kimlik doğrulama isteklerine kiracıya özgü bağlam eklemeyi içerebilir.

• Kullanıcının kimlik kaydında depolanan kiracıya özgü bilgilerin kiracılar arasında istemeden sızıntı yapıp yapmadığını göz önünde bulundurun. Örneğin, bir kullanıcı sosyal kimlikle kaydolup iki kiracıya erişim elde ederse ve A Kiracısı kullanıcı profilini zenginleştirirse, B Kiracısının bu zenginleştirilmiş bilgilere erişimi olup olmadığını belirleyin.

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 IdP'si ile federasyona ihtiyacınız yoksa self servis kayıt olma gerekebilir. Kendi kendine kaydolma işlemi gerekiyorsa aşağıdaki faktörleri göz önünde bulundurmanız gerekir:

• Kullanıcıların hangi kimlik kaynaklarından kaydolmasına izin verılacağını tanımlayın. Örneğin, kullanıcıların yerel kimlik oluşturup oluşturamayacağını ve ayrıca bir sosyal IdP kullanıp kullanamayacağını belirleyin.

• Çözümünüzün yalnızca yerel kimlikler kullanılıyorsa belirli e-posta etki alanlarına izin verip vermeyeceğini belirtin. Örneğin, bir kiracının belirli bir @contoso.com e-posta adresine sahip kullanıcılara kaydolmayı kısıtlayıp kısıtlayamayacağını belirleyin.

• Yerel kimlikleri tanımlamak için kullanılan kullanıcı asıl adı (UPN) açıkça belirlenmelidir. Yaygın UPN'ler e-posta adresleri, kullanıcı adları, telefon numaraları veya üyelik tanımlayıcılarıdır. UPN'ler değişebildiğinden, yetkilendirme ve denetim için temel alınan sabit benzersiz tanımlayıcıya başvurmanız önerilir. Örnek olarak Microsoft Entra Id içindeki nesne kimliği (OID) gösteriliyor.

• Doğruluğundan emin olmak için UPN'lerin doğrulanması gerekebilir. Bu işlem, erişim vermeden önce bir e-posta adresinin veya telefon numarasının sahipliğini doğrulamayı içerebilir.

• Bazı çözümler, kiracı yöneticilerinin kullanıcı kaydolmalarını onaylamasını gerektirebilir. Bu onay işlemi, kiracıya kimlerin katıldığı üzerinde yönetim denetimi sağlar.

• Kiracıların, kiracılara özgü bir kaydolma deneyimi veya URL gerektirip gerektirmediğine karar verin. Örneğin, kullanıcılar kaydolduğunda kiracılarınızın markalı bir kaydolma deneyimine ihtiyacı olup olmadığını veya devam etmeden önce bir kayıt isteğini kesme ve ek doğrulama gerçekleştirme olanağını belirleyin.

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

Kullanıcılar kendileri için bir kimlik kaydı yapabiliyorsa, bir kiracıya (tenant) erişim izni vermek için bir süreç tanımlayın. Kaydolma akışı, el ile erişim verme işlemini veya kullanıcılar hakkındaki bilgileri temel alan e-posta adresleri gibi otomatik bir işlem içerebilir. Bu süreci planlamak ve aşağıdaki faktörleri göz önünde bulundurmak önemlidir:

• Kaydolma akışının kullanıcıya belirli bir kiracıya erişim izni verildiğini nasıl belirleyeceğini tanımlayın.

• Çözümünüzün uygun olduğunda kiracıya kullanıcı erişimini otomatik olarak iptal edip etmediğini tanımlayın. Örneğin, kullanıcılar bir kuruluştan ayrıldığında, erişimlerini kaldırmak için el ile veya otomatikleştirilmiş bir işlem yapılmalıdır.

• Kiracıların ortamlarına erişimi olan kullanıcıları gözden geçirebilmesi ve atanan izinlerini anlayabilmesi için bir kullanıcı denetimi özelliği sağlayın.

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 çıkarma işlemini otomatikleştirmelerini sağlayan 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 kimlik kayıtlarının oluşturulmasını ve kaldırılmasını ve kiracı izinlerinin yönetimini içerir. Çok kiracılı bir çözümde otomatik hesap yaşam döngüsü yönetimi uygularken aşağıdaki faktörleri göz önünde bulundurun:

• Müşterilerinizin her kiracı için otomatik bir yaşam döngüsü süreci yapılandırmaları ve yönetmeleri gerekip gerekmediğini belirleyin. Ö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.

• SCIM uygulamanız mı yoksa federasyon teklif etmeniz mi gerektiğini belirleyin. Federasyon, kiracıların çözümünüzdeki yerel kullanıcıları yönetmek yerine gerçeklerin kaynağını kendi sistemleri içinde tutarak kullanıcı yönetimi üzerinde denetim sahibi olmasını sağlar.

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 faktörleri göz önünde bulundurun:

• Bazı kiracılar kendi MFA ilkelerini yapılandırma olanağı gerektirebilir. Ö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 için özel koşullu erişim kuralları tanımlama seçeneği önemli olabilir. Örneğin, farklı kiracıların belirli coğrafi bölgelerden gelen oturum açma girişimlerini engellemesi gerekebilir.

• Kiracıların oturum açma işlemini ayrı ayrı özelleştirmesi gerekip gerekmediğini belirleyin. Örneğin, çözümünüzün bir müşterinin logosunu göstermesi gerekebilir. Alternatif olarak, ödül numarası gibi kullanıcı bilgilerini başka bir sistemden alıp IdP'ye döndürerek kullanıcı profilini zenginleştirmesi gerekebilir.

• Bazı kullanıcıların diğer kullanıcıların kimliğine bürünmeleri gerekebilir. Ö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 sorununu araştırmak isteyebilir.

• Bazı kullanıcılar veya dış uygulamalar için API erişimi gerekebilir. Bu senaryolar, standart kullanıcı kimlik doğrulama akışlarını atlayan çözümün API'lerini doğrudan çağırmayı içerebilir.

İş 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 yönetim görevlerini otomatikleştirebilmeleri için çözümünüzün sağladığı bir API'ye erişmesi gerekebilir.

Microsoft Entra iş yükü kimliklerini destekler ve diğer IdP'ler de genellikle bunları destekler.

İş 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 düzenli anahtar yenileme ve sertifikaların süresi dolması 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ştirebiliyorsa aşağıdaki faktörleri dikkate almanız gerekir:

• her kiracıda iş yükü kimliklerinin nasıl oluşturulup yönetileceğini belirleyin.

• İş yükü kimlik isteklerinin kiracı için nasıl kapsamlandığını belirleyin.

• Her kiracının oluşturduğu iş yükü kimliklerinin sayısını sınırlamanız gerekip gerekmediğini değerlendirin.

• Her kiracıdaki iş yükü kimlikleri için koşullu erişim denetimlerinin gerekli olup olmadığını belirleyin. Ö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 sağladığınız güvenlik denetimlerini belirleyin. Örneğin, otomatik anahtar yenileme, anahtar geçerlilik süresi sonu, sertifika geçerlilik süresi sonu ve oturum açma riski izleme, iş yükü kimliğinin kötüye kullanımı riskini azaltmaya yardımcı olur.

SSO kurulumu için bir Kimlik Sağlayıcı (IdP) ile bağlantı kurun

Zaten kendi kullanıcı dizinleri olan kiracılar, çözümünüzün kendi dizinleriyle birleştirilebilmesini 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 SSO deneyimlerini etkinleştirmek istediğinde önemlidir.

Kiracıların çözümünüzle federasyon yapmasını bekliyorsanız aşağıdaki faktörleri göz önünde bulundurun:

• Kiracı için federasyonu yapılandırma işlemini göz önünde bulundurun. Kiracıların federasyonu kendilerinin yapılandırıp yapılandırmadığını veya işlemin ekibiniz tarafından el ile yapılandırma ve bakım gerektirerek gerekli olup olmadığını belirleyin.

• Çözümünüzün hangi federasyon protokollerini desteklediğini tanımlayın.

• Federasyon yanlış yapılandırmalarının istenmeyen kiracılara erişim vermesini engelleyen işlemler oluşturun.

• Çözümünüzde tek bir kiracının IdP'sinin birden fazla kiracıya federasyon gerektirip gerektirmeyeceğini planlayın. Örneğin, müşterilerin hem eğitim hem de üretim kiracısı varsa, her kiracıyla aynı IdP'yi federasyona eklemeleri gerekebilir.

Yetkilendirme modelleri

Çözümünüz için en mantıklı yetkilendirme modeline karar verin. Aşağıdaki yaygın yetkilendirme yaklaşımlarını göz önünde bulundurun:

• 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.

Yetkilendirmeler ve lisanslama

Bazı çözümlerde, ticari fiyatlandırma modelinizin bir parçası olarak kullanıcı başına lisanslama kullanabilirsiniz. Bu senaryoda, farklı özelliklere sahip farklı kullanıcı lisansları 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.

Kimlik sistemine güvenmek yerine uygulama kodunuz veya ayrılmış yetkilendirmeler sisteminizde yetkilendirmeleri izlemenizi ve zorunlu kılmanızı öneririz. Bu işlem yetkilendirmeye benzer ancak kimlik yönetimi katmanının dışında gerçekleşir.

Bu ayrılığın birkaç nedeni vardır:

• Lisanslama modellerinin karmaşıklığı: Lisanslama kuralları genellikle karmaşıktır ve iş modeline özeldir. Örneğin, lisanslar kullanıcı başına, zamana bağlı (günlük veya aylık tahsis), eşzamanlı kullanım sınırını belirleyebilir veya belirli yeniden atama kurallarına sahip olabilir. Kimlik sağlayıcıları genellikle karmaşık ticari lisanslama mantığı için değil, kullanıcı kimlik doğrulaması ve temel yetkilendirme için tasarlanmıştır.

• Bağımsızlık: Lisans yönetimi için kimlik sağlayıcısı özelliklerine güvenmek çözümünüzü bu sağlayıcıya veya kısıtlamalarına kilitleyebilir. Farklı kimlik sağlayıcıları kullanan müşterileri destekliyorsanız, yine de onlar için özel bir çözüm oluşturmanız gerekir.

Yaygın bir desen, uygulamanın veritabanındaki veya ayrılmış bir hizmet içindeki lisansları yönetmektir. Kullanıcı oturum açtığında, kimlik sağlayıcısı yetkilendirmelerini alır ve bunları çalışma zamanında uygulama bileşenleri tarafından denetlenebilecek özel talepler olarak yetkilendirme belirtecine ekler.

Kimlik ölçeklendirme ve kimlik doğrulama hacmi

Çok kiracılı çözümler arttıkça, çözümün işlemesi için gereken kullanıcı ve oturum açma isteklerinin sayısı artar. Şu ölçeklenebilirlik konularını değerlendirin:

• Kullanıcı dizininin gerekli kullanıcı sayısını destekleyecek şekilde ölçeklendirilip ölçeklendirilmeyeceğini değerlendirin.

• Kimlik doğrulama işleminin beklenen sayıda oturum açma ve kaydolma işlemini işleyip işlemediğini değerlendirin.

• Kimlik doğrulama sisteminin işleyemeyeceği ani artışlar olup olmadığını belirleyin. Örneğin, Pasifik Saati ile 09:00'da batı ABD'deki herkes çalışmaya başlayabilir ve çözümünüzde oturum açabilirsiniz ve bu da oturum açma isteklerinde ani bir artış oluşturur. Bu senaryolar bazen oturum açma fırtınaları olarak adlandırılır.

• Çözümünüzün bazı bölümlerindeki yüksek yükün kimlik doğrulama işleminin performansını etkileyip etkilemediğini belirleyin. Örneğin, kimlik doğrulaması bir uygulama katmanı API'sine çağrı yapılmasını gerektiriyorsa, kimlik doğrulama isteklerinde bir artış genel sistem performansını etkileyebilir.

• IdP kullanılamaz duruma gelirse çözümünüzün nasıl davranacağını tanımlayın. İş sürekliliğini korumak için bir yedekleme kimlik doğrulama hizmetinin dahil edilip edilmeyeceğini göz önünde bulundurun.

Katkıda Bulunanlar

Microsoft bu makaleyi korur. Bu makaleyi aşağıdaki katkıda bulunanlar yazdı.

Asıl yazarlar:

• John Downs | Baş Yazılım Mühendisi, Azure Desenleri ve Uygulamaları
• Daniel Scott-Raynsford | İş Ortağı Teknoloji Stratejisti
• Arsen Vladimirskiy | Baş Müşteri Mühendisi, Azure için FastTrack

Diğer katkıda bulunanlar:

• Jelle Druyts | Baş Müşteri Mühendisi, Azure için FastTrack
• Landon Pierce | Kıdemli Müşteri Mühendisi
• Sander van den Hoven | Kıdemli İş Ortağı Teknoloji Stratejisti
• Nick Ward | Üst Düzey Bulut Çözümü Mimarı

Nonpublic LinkedIn profillerini görmek için LinkedIn'de oturum açın.

İlgili kaynak

• Çok kiracılı çözümlerde kimlik için mimari yaklaşımlar

Sonraki adım

Çok kiracılı bir uygulamada etki alanı adlarıyla çalışırken dikkat edilmesi gerekenler hakkında bilgi edinin.