Federe Kimlik düzeni
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. Talepler 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 bir ağ bağlantısı gerektirmeden çoklu oturum açmayı desteklediğinden tüm uygulama türlerinde (özellikle bulutta barındırılan uygulamalarda) daha yaygın hale gelmektedir. Kullanıcının her uygulama için kimlik bilgilerini girmesi gerekmez. Bu, birçok farklı uygulama için gereken kimlik bilgilerinin oluşturulmasını önleyene ve kullanıcının kimlik bilgilerini özgün kimlik sağlayıcısı dışında tüm kullanıcılardan gizler. 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 birden çok kimlik sağlayıcısı yapılandırıldıysa, kullanıcının kimlik doğrulaması için hangi kimlik sağlayıcısına yönlendirilmesi gerektiğini algılaması gerekir. 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şirken uygulamanın alt etki alanı, kullanıcının IP adresi kapsamı veya kullanıcının tarayıcısında depolanan bir tanımlama bilgisinin içeriğine göre otomatik olarak yapabiliriz. Ö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.
Örnek
Microsoft Azure’da bir kuruluş bir çok kiracılı hizmet olarak yazılım (SaaS) uygulaması barındırır. 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ğinin kuruluşun kendi Active Directory'si tarafından doğrulandığı zaman kiracıların Active Directory Federasyon Hizmetleri (AD FS) (AD FS) tarafından oluşturulan bir federasyon kimliği kullanarak web sitesine erişmelerini sağlar.

Şekilde, kiracıların kendi kimlik sağlayıcısıyla (1. adım) nasıl kimlik doğrulaması yaptığı ve bu durumda AD FS. Bir kiracının kimlik doğrulamayı başarıyla AD FS bir belirteç sağlar. İstemci tarayıcısı bu belirteci SaaS federasyon sağlayıcısı için geçerli bir belirteç 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 anımsamalarına gerek olmayacaktır ve kiracının şirketinde bir yönetici uygulamaya erişen kullanıcıların AD FS kendi kimlik bilgileriyle yapılandırabilirsiniz.