Federasyon

Federasyon, yetkilendirme yetkilisinin diğer üyelerine temsilci seçmesine izin verir. Örneğin, aşağıdaki iş sorununu göz önünde bulundurun: Otomatik parça üretim şirketi Contoso Ltd, müşterisi Fabrikam Inc.'in yetkili çalışanlarının Contoso'nun parça siparişi Web Hizmeti'ne güvenli bir şekilde erişmesine izin vermek istiyor. Bu senaryo için bir güvenlik çözümü Contoso'nun Fabrikam ile bir güven mekanizması kurarak erişim yetkilendirme kararını Fabrikam'a devretmesidir. Bu işlem aşağıdaki gibi çalışabilir:

• Fabrikam, Contoso'nun ortağı olduğunda Contoso ile bir güven anlaşması ayarlar. Bu adımın amacı, Fabrikam'ın yetkilendirmesini temsil edecek ve Contoso için kabul edilebilir olacak güvenlik belirteci türünü ve içeriğini kabul etmektir. Örneğin, konu adı "CN=Fabrikam Inc Supplier STS" olan güvenilir bir X.509 sertifikasının, contoso Web Hizmeti tarafından kabul edilecek saml için bir SAML belirteci imzalaması gerektiğine karar verilebilir. Ayrıca, verilen SAML belirtecindeki güvenlik talebi 'https://schemas.contoso.com/claims/lookup' (parça arama yetkilendirmesi için) veya 'https://schemas.contoso.com/claims/order' (parça sıralama yetkilendirmesi için) olması gerektiğine karar verilebilir.
• Fabrikam çalışanı iç parça sipariş uygulamasını kullandığında, önce Fabrikam içindeki bir güvenlik belirteci hizmetiyle (STS) iletişim kurar. Bu çalışanın kimliği dahili Fabrikam güvenlik mekanizması (örneğin, Windows etki alanı kullanıcı adı/parolası) kullanılarak doğrulanır, parçaları sipariş etme yetkisi doğrulanır ve uygun talepleri içeren kısa süreli bir SAML belirteci verilir ve yukarıda karar verilen X.509 sertifikası tarafından imzalanır. Ardından parça sıralama uygulaması, kimlik doğrulaması yapmak ve sıralama görevini gerçekleştirmek için verilen SAML belirtecini sunan Contoso hizmetiyle iletişim kurar.

Burada, Fabrikam STS 'veren taraf' olarak, Contoso parts hizmeti ise 'bağlı olan taraf' olarak hareket eder.

Federasyon Özellikleri

Federasyon senaryosunda yer alan taraflar veya roller için desteklenen güvenlik özellikleri şunlardır:

• İstemci tarafı: GÜVENLIK belirtecini STS'den almak için WsRequestSecurityTokenişlevikullanılabilir. Alternatif olarak, CardSpace veya LiveID gibi bir istemci tarafı güvenlik belirteci sağlayıcı kitaplığını kullanabilir ve ardından WsCreateXmlSecurityTokenkullanarak yerel olarak bir güvenlik belirteci oluşturmak için çıktısını kullanabilir. Her iki durumda da, istemci güvenlik belirtecini aldıktan sonra hizmete belirteci sunmak için WS_XML_TOKEN_MESSAGE_SECURITY_BINDING belirten bir kanal oluşturabilir ve kanalı korumak için WS_SSL_TRANSPORT_SECURITY_BINDING gibi bir aktarım güvenlik bağlaması oluşturabilir.
• Sunucu tarafı: SAML belirteçleri veren bir güvenlik belirteci hizmeti olan bir federasyon senaryosunda, sunucu kanalı korumak için WS_SSL_TRANSPORT_SECURITY_BINDING gibi bir aktarım güvenlik bağlamasıyla birlikte WS_SAML_MESSAGE_SECURITY_BINDINGkullanabilir.
• STS tarafı: STS'nin bir Web Hizmeti uygulaması olduğunu ve diğer tüm güvenli Web Hizmetleri gibi dinleyici oluşturma zamanında güvenlik açıklaması yapısı kullanarak ondan güvenlik belirteci isteyenlerin güvenlik gereksinimlerini belirtebileceğini unutmayın. Daha sonra gelen istek iletisi yüklerini ayrıştırarak belirteç isteklerini doğrulayabilir ve verilen belirteçleri yanıt iletisi yükleri olarak geri gönderebilir. Şu anda bu ayrıştırma ve verme adımlarına yardımcı olacak özellik sağlanmamektedir.

İstemci tarafının, belirteç türünü bilmeden veya belirteç türüne özel işlem yapmadan verilen güvenlik belirtecini genel olarak XML güvenlik belirteci olarak işleyebileceğini unutmayın. Ancak, sunucunun anlamak ve işlemek için belirli bir güvenlik belirteci türünü anlaması gerekir. Güvenlik belirteci isteği ve yanıt adımları, WS-Trust belirtiminde tanımlanan yapıları kullanır.

Daha Karmaşık Federasyon Senaryoları

Federasyon senaryosu, federasyon zinciri oluşturan birden çok STS içerebilir. Aşağıdaki örneği göz önünde bulundurun:

• İstemci, LiveID kullanıcı adı/parolası kullanarak LiveID STS'de kimlik doğrulaması yapar ve bir güvenlik belirteci T1 alır.
• İstemci, T1 kullanarak STS1'de kimlik doğrulaması yapar ve bir güvenlik belirteci T2 alır.
• İstemci, T2 kullanarak STS2'de kimlik doğrulaması yapar ve bir güvenlik belirteci T3 alır.
• İstemci, T3 kullanarak hedef hizmet S'de kimlik doğrulaması yapar.

Burada LiveID STS, STS1, STS2 ve S federasyon zincirini oluşturur. Federasyon zincirindeki STS'ler, genel uygulama senaryosu için çeşitli roller gerçekleştirebilir. Bu tür STS işlevsel rollerine örnek olarak kimlik sağlayıcısı, yetkilendirme karar alıcısı, anonimleştirici ve kaynak yöneticisi verilebilir.

STS İstek Parametreleri ve Meta Veri Değişimi

İstemcinin başarılı bir WsRequestSecurityToken çağrısı yapabilmesi için, bu çağrının parametrelerini (gerekli belirteç türü ve talep türleri gibi), güvenlik açıklamasını istek kanalının STS'ye gereksinimlerini ve STS'nin uç nokta adresini bilmesi gerekir. İstemci uygulaması bu bilgileri belirlemek için aşağıdaki tekniklerden herhangi birini kullanabilir:

• Tasarım zamanı kararlarının bir parçası olarak uygulamadaki bilgileri sabit kodlayın.
• Bu bilgileri yerel uygulama dağıtıcısı tarafından ayarlanan bir uygulama düzeyi yapılandırma dosyasından okuyun.
• WS_ISSUED_TOKEN_MESSAGE_SECURITY_BINDING_CONSTRAINT yapısına sahip meta verileri içeri aktarma özelliğini kullanarak çalışma zamanında bu bilgileri dinamik olarak bulun.

Federasyon ile dinamik MEX kullanımını göstermek için yukarıdaki 3 STS örneğini göz önünde bulundurun. İstemci, T3 (STS2'den ne isteneceği) ve STS2 dinamik MEX adresi (sts2'nin nerede bulunacağı) hakkında bilgi edinmek için önce S ile dinamik bir MEX yapar. Ardından bu bilgileri kullanarak STS2 ile dinamik bir MEX gerçekleştirerek T2 ve STS1 hakkındaki bilgileri keşfeder ve bu şekilde devam eder.

Bu nedenle, federasyon zincirini oluşturmak için dinamik MEX adımları 4, 3, 2, 1 sırasıyla gerçekleşir ve belirteç isteği ve sunu adımları federasyon zincirini sarmak için 1, 2, 3, 4 sırasına göre gerçekleşir.