Kimlik doğrulama temsilcisi olarak bir dış kimlik sağlayıcısı kullanın. Bu geliştirmeyi kolaylaştırabilir, kullanıcı yönetimi gereksinimini en aza indirebilir ve uygulamanın kullanıcı deneyimini geliştirebilir.
Bağlam ve sorun
Kullanıcıların genellikle bir iş ilişkisine sahip oldukları farklı kuruluşlar tarafından sağlanan ve barındırılan birden çok uygulama ile çalışması gerekir. Bu kullanıcıların her bir uygulama için belirli (ve birbirinden farklı) parolalar kullanması gerekiyor olabilir. Bu aşağıdakilere neden olabilir:
Bölünmüş bir kullanıcı deneyimi. Çok sayıda oturum açma kimlik bilgisine sahip olan kullanıcılar bunları sık sık unutur.
Güvenlik açıklarına maruz kalma. Bir kullanıcı şirketten ayrıldığında hesabın sağlamasının hemen kaldırılması gerekir. Bu, büyük kuruluşlarda kolayca gözden kaçabilir.
Karmaşık kullanıcı yönetimi. Yöneticilerin tüm kullanıcılar için kimlik bilgilerini yönetmesi ve parola anımsatıcılar sağlamak gibi ek görevler gerçekleştirmesi gerekir.
Kullanıcılar genellikle tüm bu uygulamalar için aynı kimlik bilgilerini kullanmayı tercih eder.
Çözüm
Federe kimlik kullanabilen bir kimlik doğrulama mekanizması uygulayın. Kullanıcı kimlik doğrulamasını uygulama kodundan ayırın ve kimlik doğrulaması için güvenilir bir kimlik sağlayıcısını temsilci olarak seçin. Bu, geliştirmeyi basitleştirebilir ve yönetim yükünü azaltarak kullanıcılara daha fazla kimlik sağlayıcısı (IdP) kullanarak oturum açma olanağı sunar. Ayrıca kimlik doğrulamasını yetkilendirmeden açıkça ayırmanızı sağlar.
Güvenilen kimlik sağlayıcıları şirket dizinleri, şirket içi federasyon hizmetleri, iş ortakları tarafından sağlanan diğer güvenlik belirteci hizmetleri (STS) veya bir Microsoft, Google, Yahoo! ya da Facebook hesabı olan kullanıcıların kimliğini doğrulayabilen sosyal kimlik sağlayıcılarını içerir.
Şekilde bir istemci uygulaması kimlik doğrulaması gerektiren bir hizmete erişmesi gerektiğinde Federe Kimlik düzeni gösterilmektedir. Kimlik doğrulaması STS ile birlikte çalışan bir IpP tarafından yapılır. IdP kimliği doğrulanan kullanıcı hakkında bilgiler sağlayan güvenlik belirteçleri verir. Talep olarak adlandırılan bu bilgiler kullanıcının kimliğini içerir ve rol üyeliği ve daha ayrıntılı erişim hakları gibi diğer bilgileri de içerebilir.
Bu model genellikle talep tabanlı erişim denetimi olarak adlandırılır. Uygulama ve hizmetler belirteçteki talepleri temel alarak özellikler ve işlevlere erişimi yetkilendirir. Kimlik doğrulaması gerektiren hizmetin IdP’ye güvenmesi gerekir. İstemci uygulaması kimlik doğrulaması yapan IdP ile iletişim kurar. Kimlik doğrulaması başarılı olursa, IdP kullanıcıyı STS’ye tanıtan talepleri içeren bir belirteç döndürür (IDP ve STS’nin aynı hizmet olabileceğine dikkat edin). STS belirteci istemciye döndürmeden önce belirteçteki talepleri önceden tanımlı kuralları temel alarak dönüştürebilir veya geliştirebilir. İstemci uygulaması daha sonra bu belirteci kimlik kanıtı olarak hizmete geçirebilir.
Güven zincirinde ek güvenlik belirteci hizmetleri olabilir. Örneğin, daha sonra açıklanan senaryoda şirket içi bir STS kullanıcının kimliğini doğrulamak için bir kimlik sağlayıcısına erişmekten sorumlu başka bir STS’ye güvenir. Bu yaklaşım şirket içi bir STS ve dizin olan kurumsal senaryolarda yaygındır.
Federe kimlik doğrulaması farklı etki alanlarında kimliklere güvenme sorununa standart tabanlı bir çözüm sunar ve çoklu oturum açmayı destekler. Kimlik sağlayıcılarına doğrudan ağ bağlantısı gerektirmeden çoklu oturum açmayı desteklediğinden, bu kimlik doğrulama türü, özellikle bulutta barındırılan uygulamalar olmak üzere tüm uygulama türlerinde daha yaygın hale gelmektedir. Kullanıcının her uygulama için kimlik bilgilerini girmesi gerekmez. Bu, birçok farklı uygulamaya erişmek için gereken kimlik bilgilerinin oluşturulmasını önlediğinden ve kullanıcının kimlik bilgilerini özgün kimlik sağlayıcısı dışında tüm kullanıcılardan gizlediğinden güvenliği artırır. Uygulamalar yalnızca belirteçteki kimliği doğrulanan kimlik bilgilerini görür.
Ayrıca federe kimliğin ana avantajlarından biri kimlik ve kimlik bilgileri yönetiminin kimlik sağlayıcısının sorumluluğunda olmasıdır. Uygulama veya hizmetin kimlik yönetimi özellikleri sağlaması gerekmez. Ayrıca, kurumsal senaryolarda, kurumsal dizin kimlik sağlayıcısına güveniyorsa kullanıcı hakkında bilgilere sahip olması gerekmez. Bu, dizin içinde kullanıcı kimliğini yönetmeyle ilişkili tüm yönetim yükünü kaldırır.
Sorunlar ve dikkat edilmesi gerekenler
Federe kimlik doğrulaması kullanan uygulamalar tasarlarken aşağıdakileri göz önünde bulundurun:
Kimlik doğrulaması tek hata noktası olabilir. Uygulamanızı birden çok veri merkezine dağıtırsanız, uygulama güvenilirliği ve kullanılabilirliğini sürdürmek için kimlik yönetimi mekanizmanızı da aynı veri merkezlerine dağıtmayı göz önünde bulundurun.
Kimlik doğrulaması araçları, kimlik doğrulaması belirtecinde yer alan rol taleplerine dayalı olarak erişim denetimini yapılandırmayı mümkün kılar. Bu genellikle rol tabanlı erişim denetimi (RBAC) olarak adlandırılır ve özellikler ve kaynaklara erişim üzerinde daha ayrıntılı bir denetim düzeyi sunabilir.
Kurumsal bir dizinden farklı olarak, sosyal kimlik sağlayıcılarını kullanan talep tabanlı kimlik doğrulaması genellikle kimliği doğrulanan kullanıcı hakkında bir e-posta adresi ve belki bir ad dışında bilgi sağlamaz. Bir Microsoft hesabı gibi bazı sosyal kimlik sağlayıcıları yalnızca benzersiz bir tanımlayıcı sağlar. Uygulamanın genellikle kayıtlı kullanıcılar hakkında bazı bilgileri tutması ve bu bilgileri belirteçteki taleplerde yer alan tanımlayıcı ile eşleştirebilmesi gerekir. Genellikle bu, kullanıcı kayıt sırasında uygulamaya ilk kez eriştiğinde yapılır ve daha sonra bilgiler her kimlik doğrulamasından sonra ek talepler olarak belirtece eklenir.
STS için yapılandırılmış birden fazla kimlik sağlayıcısı varsa, STS kullanıcının kimlik doğrulaması için hangi kimlik sağlayıcısına yönlendirileceğini belirlemelidir. Bu işlem giriş alanı bulma olarak adlandırılır. STS bunu kullanıcının sağladığı bir e-posta adresine veya kullanıcı adına, kullanıcının eriştiği uygulamanın bir alt etki alanına, kullanıcının IP adresi kapsamına veya kullanıcının tarayıcısında depolanan bir tanımlama bilgisinin içeriğine göre otomatik olarak yapabilir. Örneğin, kullanıcı user@live.com gibi Microsoft etki alanında yer alan bir e-posta adresi girdiyse, STS kullanıcıyı Microsoft hesabı oturum açma sayfasına yönlendirir. Daha sonraki ziyaretlerde, STS son oturum açmanın bir Microsoft hesabı ile yapıldığını belirtmek için bir tanımlama bilgisi kullanabilir. Otomatik bulma giriş bölgesini belirleyemiyorsa, STS güvenilen kimlik sağlayıcılarını listeleyen bir giriş bölgesi bulma sayfası görüntüler ve kullanıcı kullanmak istediği bölgeyi seçer.
Bu düzenin kullanılacağı durumlar
Bu düzen, aşağıdakine benzer senaryolarda kullanışlıdır:
Kuruluşta çoklu oturum açma. Bu senaryoda kurumsal güvenlik sınırının dışında bulutta barındırılan kurumsal uygulamalar için, çalışanların bir uygulamayı her ziyaret ettiklerinde oturum açmalarına gerek kalmadan kimlik doğrulaması yapmanız gerekir. Kullanıcı deneyimi, kullanıcıların kurumsal bir ağda oturum açarken kimlik doğrulaması yaptıkları ve daha sonradan tekrar oturum açmalarına gerek kalmadan tüm ilgili uygulamalara eriştikleri şirket içi uygulamalar ile aynıdır.
Birden çok iş ortağı ile federasyon kimliği. Bu senaryoda hem kurumsal çalışanlar hem de kurumsal dizinde hesabı olmayan iş ortaklarının kimliklerini doğrulamanız gerekir. Bu işletmeler arası uygulamalar, üçüncü taraf hizmetlerle tümleştirilen uygulamalar ve farklı BT sistemlerine sahip şirketlerin kaynakları birleştirdiği veya paylaştığı durumlarda yaygındır.
SaaS uygulamalarında federasyon kimliği. Bu senaryoda, bağımsız yazılım satıcıları birden çok istemci veya kiracı için kullanıma hazır bir hizmet sağlar. Her kiracı uygun bir kimlik sağlayıcısı kullanarak kimliğini doğrular. Örneğin işletme kullanıcıları kurumsal kimlik bilgilerini ve tüketiciler ve kiracının müşterileri sosyal kimlik bilgilerini kullanır.
Bu düzen aşağıdaki durumlarda kullanışlı olmayabilir:
Uygulamanın tüm kullanıcılarının kimliği tek bir sağlayıcı tarafından doğrulanabilir ve başka bir kimlik sağlayıcısı kullanılarak kimlik doğrulaması yapma gereksinimi yoktur. Bu bir VPN kullanarak veya (bulut barındırma senaryosunda) şirket içi dizin ve uygulama arasındaki bir sanal ağ bağlantısı üzerinden kimlik doğrulaması için kurumsal bir dizin (uygulama içinden erişilebilir) kullanan iş uygulamalarında sıklıkla görülür.
Uygulama ilk olarak özel kullanıcı depoları gibi başka bir kimlik doğrulama mekanizması kullanılarak oluşturulmuş veya talep tabanlı teknolojiler tarafından kullanılan anlaşma standartlarını işleyemiyor. Mevcut uygulamalara sonradan talep tabanlı kimlik doğrulaması ve erişim denetimi eklemek karmaşık olabilir ve büyük olasılıkla uygun maliyetli değildir.
İş yükü tasarımı
Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için Federe Kimlik deseninin iş yükünün tasarımında nasıl kullanılabileceğini değerlendirmelidir. Örneğin:
| Yapı Taşı | Bu desen sütun hedeflerini nasıl destekler? |
|---|---|
| Güvenilirlik tasarımı kararları, iş yükünüzün arızaya karşı dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma gelmesini sağlamaya yardımcı olur. | Kullanıcı yönetimi ve kimlik doğrulamasının boşaltılması, bu bileşenlerin güvenilirliğini genellikle yüksek bir SLO'ya sahip olan kimlik sağlayıcısına değiştirir. Ayrıca, iş yükü olağanüstü durum kurtarma sırasında kimlik doğrulama bileşenlerinin büyük olasılıkla iş yükü kurtarma planının bir parçası olarak ele alınması gerekmez. - RE:02 Kritik akışlar - RE:09 Olağanüstü durum kurtarma |
| Güvenlik tasarımı kararları, iş yükünüzün verilerinin ve sistemlerinin gizliliğini, bütünlüğünü ve kullanılabilirliğini sağlamaya yardımcı olur. | Kullanıcı yönetimini ve kimlik doğrulamasını dışlaştırarak, bu özellikleri iş yükünüzde uygulamaya gerek kalmadan kimlik tabanlı tehdit algılama ve önleme için gelişmiş özellikler elde edebilirsiniz. Dış kimlik sağlayıcıları ise modern birlikte çalışabilir kimlik doğrulama protokollerini kullanır. - SE:02 Güvenli geliştirme yaşam döngüsü - SE:10 İzleme ve tehdit algılama |
| Performans Verimliliği , ölçeklendirme, veri ve kod iyileştirmeleri aracılığıyla iş yükünüzün talepleri verimli bir şekilde karşılamasını sağlar. | Kullanıcı yönetimi ve kimlik doğrulamasını boşalttığınızda, uygulama kaynaklarını diğer önceliklere ayırabilirsiniz. - PE:03 Hizmetleri seçme |
Herhangi bir tasarım kararında olduğu gibi, bu desenle ortaya konulabilecek diğer sütunların hedeflerine karşı herhangi bir dengeyi göz önünde bulundurun.
Örnek
Kuruluş, Microsoft Azure'da çok kiracılı bir hizmet olarak yazılım (SaaS) uygulaması barındırıyor. Uygulama kiracıların kendi kullanıcıları için uygulamayı yönetmek için kullanabilecekleri bir web sitesi içerir. Uygulama, bir kullanıcının kimliği kuruluşun kendi Active Directory'sinde doğrulandığında kiracıların Active Directory Federasyon Hizmetleri (AD FS) (AD FS) tarafından oluşturulan bir federasyon kimliği kullanarak web sitesine erişmesine olanak tanır.
Şekilde, kiracıların kendi kimlik sağlayıcılarıyla (1. adım) nasıl kimlik doğrulaması yaptıkları gösterilmektedir. Bu örnekte AD FS. Bir kiracının kimliğini başarıyla doğruladıktan sonra AD FS bir belirteç verir. İstemci tarayıcısı bu belirteci SaaS federasyon sağlayıcısı için geçerli olan bir belirteci geri almak için kiracının AD FS tarafından verilen belirteçlere güvenen SaaS uygulamasının federasyon sağlayıcısına iletir (2. adım). Gerekirse, SaaS federasyon sağlayıcısı istemci tarayıcısına yeni belirteci döndürmeden önce belirteçteki talepleri uygulamanın tanıdığı taleplere dönüştürür (adım 3). Uygulama SaaS federasyon sağlayıcısı tarafından verilen belirteçlere güvenir ve yetkilendirme kurallarını uygulamak için belirteçteki talepleri kullanır (adım 4).
Kiracıların uygulamaya erişmek için ayrı kimlik bilgilerini hatırlaması gerekmez ve kiracının şirketindeki bir yönetici, uygulamaya erişebilen kullanıcıların listesini kendi AD FS'sinde yapılandırabilir.
Sonraki adımlar
- Microsoft Entra ID
- Active Directory Domain Services
- Active Directory Federasyon Hizmetleri
- Azure’da Çok Müşterili Uygulamalar