SAML (“Security Assertion Markup Language”) ile Kimlik Doğrulama
Kimlik ve erişim yönetimi (Identity & Access Management) günümüzde kurumlardaki siber güvenlik süreçlerinin doğru yönetilmesinde büyük rol oynar. Kimlik ve erişim yönetimi için, en basit tabirle “doğru kişilerin, doğru zamanda, doğru amaçlarla, doğru kaynaklara erişimini sağlayan güvenlik disiplinidir” diyebiliriz. SAML, açık kaynaklı bir standart olarak uygulamaların kimlik doğrulama ve yetkilendirme mekanizmalarını sağlamakta bizlere yardımcı olmaktadır. Saml teknolojisini detaylı olarak anlatmaya geçmeden önce kimlik doğrulama, yetkilendirme ile beraber bu yazıda sıkça karşılaşılacak kavramlardan ve bir uygulamadaki ilkel ve gelişmiş kimlik doğrulama ve yetkilendirme mekanizmaları basitçe nasıl olabilir bunlardan bahsetmek istiyorum.
İlk olarak;
Kimlik Doğrulama (Authentication) kısaca AuthN
- Kimlik doğrulama kullanıcının, bir sistemde haklarının olup olmadığını ve aslında kim olduğunu teyit etme işlemidir. Bu teyit işlemi, parolalar, akıllı kartlar veya bir göz retinası gibi çeşitli yöntem ve araçlarla gerçekleştirilebilir.
Yetkilendirme (Authorization) kısaca AuthZ
-Yetkilendirme ise bir kullanıcının herhangi bir sistemde kimlik doğrulama işlemi gerçekleştikten sonra hangi haklara sahip olacağıdır.
Service Provider (SP)
-Bu yazı özelinde SP yi erişmeye çalıştığınız kaynak olarak düşünebilirsiniz
Identity Provider (IdP)
- Kullanıcı bilgilerini saklayan ve doğrulayan servis
Claim
- Talep, iddia anlamlarına gelir. Kullanıcı bilgilerini key-value formunda tutan yapılardır. Yapılan talep doğrultusunda bu yapılardaki bilgiler kimlik doğrulama ve yetkilendirme için kullanılabilir.
Birçok çalışanı olan bir şirkette bir uygulama geliştirdiğinizi ve bu uygulamanın kendi içindeki (local) tanımlanmış olan kullanıcılarla kimlik doğrulama ve yetkilendirme işlemini yaptığını düşünün. İlk olarak uygulamanızın içinde farklı kullanıcıları birbirinden ayırmak için bir uygulama mantığına sahip olmanız gerekiyor. Daha sonra kullanıcıları tutmak için bir user store, Kimlik doğrulama işlemleri için bir mekanizmaya ve rollerin ve hakların belirlendiği bir başka yapıya aynı uygulama içinde ihtiyacınız olacaktır.
Bu tip uygulamaların sayısı çoğalmaya başlayınca hem kullanıcı için, hem uygulamayı geliştiren için hem de uygulamaları yöneten insanlar için bu durum çok zor bir hal alacaktır. Kullanıcılar her uygulama için farklı kimlik doğrulama yöntemlerini saklamak veya hatırlamak zorunda kalacaktır ki bu zayıf parola veya bütün uygulamalarda aynı parola kullanımı gibi güvenlik zafiyetlerine sebebiyet verebilirdi. Uygulamaları yönetenler ise bir kullanıcı ile ilgili işlem yapılacağı zaman bütün uygulamalarda tek tek o işlemi yapmak zorunda kalacaklardı.
Bu problemlerin önüne geçmek için Claim-based erişim modeli kullanılmaya başlandı. Claim-based modelinde kullanıcılar elde ettikleri claimleri (key-value çifti) hedef sisteme erişmek için kullanırlar. Bu modelde uygulamanız ve kimlik sağlayıcılar(IdP) arasında bir trust ilişkisi kurulması gerekiyor. IdP ler, Security Token service ve User Store bileşenlerine sahiptir. User store kullanıcı kimliklerini barındırır. Bir database den veya active directory ortamından sağlanan verilerle bu karşılanabilir. Security Token Service kullanıcı isteklerini karşılamakla ve token üretmekle yükümlüdür. Kullanıcı IdP den kimlik doğrulama ve yetkilendirme işlemlerini yaptıktan sonra IdP nin sağlamış olduğu claim ile uygulamaya erişim gerçekleştirilir. Eğer uygulama claim i doğrulamazsa erişime izin vermez.
Uygulamada local user store yapısı hala olabilir fakat bu kullanıcıların ayarlarının ve erişim haklarının saklanması içindir. Uygulama parolaları saklamaz veya kullanmaz. Bu modelle beraber yazılım geliştiricilerin karışık kimlik doğrulama mekanizmaları yerine elde edilen claimi kabul eden basit bir mekanizma oluşturması yeterli olacaktır. Bu yöntem kullanıcılar, uygulamayı yönetenler ve yazılım geliştiriciler için daha uygun bir yöntemdir. Kullanıcılar tek bir platforma giriş yaptıktan sonra elde ettikleri claimlerle istedikleri uygulamada erişim elde edebilirler. Uygulama yöneticileri ise bir kullanıcı ile ilgili işlem yapacakları zaman tek tek bütün uygulamalarda düzenleme yapmak yerine sadece IdP den bu işlemi gerçekleştirebilirler.
Claim-based erişim modelinde uygulamaların ve IdP lerin arasındaki Trust çok önemlidir. Bu trust idp ve uygulamaların karşılıklı bir takım bilgileri içeren metadatalarını exchange etmeleriyle kurulabilir. Birbirleriyle trust ilişkisi kuran bileşenlerin oluşturduğu yapıya realm/security domain denir ve sistemlere erişmek için claim ler kullanılır. Birden fazla realm e sahipseniz ve bu realm lerin arasında trust yoksa Realm A de elde edilen bir claim i Realm B deki bir sisteme erişmek için kullanamazsınız. İki veya daha fazla Realm in birbirleriyle Trust olması Federation ile sağlanır.
Claim-based erişim modeliyle alakalı bir fikir oluştuysa SAML bu oyunun neresinde biraz buna bakalım.
SAML Nedir?
SAML yani Security Assertion Markup Language ilk olarak v1.0 versiyonuyla 2002 de karşımıza çıktı. Daha sonra 2003 te v.1.1 ve son olarak SAML v2.0 2005 yılında duyuruldu. SAML, OASIS (Organization for the Advancement of Structured Information Standards) tarafından geliştirilmiş, genellikle web tabanlı SSO lar tarafından kullanılan açık kaynak kodlu bir teknolojidir.
Ne zaman ve hangi durumlarda?
Hem kimlik doğrulama (authentication) hem de yetkilendirme (authorization) için kullanılabilir. SAML bize kimlik sağlayıcılar(IdP) ve servis sağlayıcılar(SP) arasında kullanıcı bilgilerini güvenli bir şekilde değiş tokuş etmemize olanak sağlayan XML tabanlı bir çözümdür.
Neden SAML?
SAML teknolojisinin IDP ler, kullanıcılar ve SP ler için bir çok avantajı vardır. Merkezi IDP deki kimlik doğrulama ve erişimler üzerindeki denetimi sağlayarak daha güvenli bir yapı sunar. Single Sign-on (SSO) yapısının kurulmasında çıkabilecek ek maliyetlere çözüm olabilir. SSO kullanılarak oturum açıldığında kullanıcılar her SP de farklı oturum açılmasına gerek kalmadan erişim sağlayabilir. SAML kimlik avı ve kimlik hırsızlığı gibi başımızı ağrıtabilecek güvenlik problemlerinin önüne geçmemize yardımcı olur. SAML ayrıca, bireysel kullanıcıların oturum açma kimlik bilgilerini saklamak zorunda olmadıklarından dolayı SP’ler için güvenlik risklerini azaltır ve büyük ölçekli veri ihlallerinin önüne geçerek çok daha az risk oluşturur.
SAML ın dezavantajlarından bahsedecek olursak birçok erişim yönetimi ürününün SAML konfigürasyonlarını karmaşık ve zaman alan bir şekilde gerçekleştirmesidir. Modern erişim yönetimi ürünleri bu konfigürasyonları birçok uygulama ile entegre bir şekilde hazır hale getirip basit kurulum sihirbazlarıyla ve güncel tutulan entegrasyonlarla güvenli ve basit bir şekilde gerçekleştirebilmektedir.
Nasıl?
SAML protokolünün nasıl çalıştığını tanımlayabilmek için temelde 3 bileşene ihtiyacımız var. Bir kullanıcı ajanı(user agent), Kimlik sağlayıcı(IdP) ve Servis Sağlayıcı(SP). Kullanıcı ajanı bir internet tarayıcısı olabilir. Servis sağlayıcısı ise erişmek istediğimiz uygulamadır. Claim-Based erişim metodundan bahsederken IdP ve uygulama arasındaki Trustın olmazsa olmaz olduğundan bahsetmiştik. Kullanıcı internet tarayıcısı aracılığı ile IdP den kimlik doğrulama ve yetkilendirme işlemlerini gerçekleştirir. IdP kullanıcıya SAML Assertion denilen bir bilet sağlar. Bunu claim gibi de düşünebilirsiniz. Kullanıcı daha sonra IdP den elde ettiği bu bilet ile öncesinde IdP ile arasında trust ilişkisi kurulan uygulamaya veya uygulamalara erişebilir.
IdP tarafından üretilen SAML Assertion servis sağlayıcıya ulaştıktan sonra servis sağlayıcı bu IdP tarafından imzalanmış bilet üzerindeki bilgileri kendi user store uyla karşılaştırıp eğer uygun eşleşme olursa bu bileti kabul eder. IdP ve servis sağlayıcı kendi aralarında daha önce hangi bilgilerin hangi formatta iletileceği konusunda anlaşmış olmalıdırlar. IdP ve servis sağlayıcı taraflarında bu konfigürasyonlarla beraber gerekli sertifikalarında bulunduğu xml metadata dosyaları oluşturulur. Daha sonra bu metadatalar exchange edilir. Böylelikle daha önce de önemle bahsettiğimiz trust kurulmuş olur.
Aşağıdaki resimde örnek bir metadata görüyorsunuz.
NameID Format nedir?
NameID ( Name Identifier ) kullanıcıların ve servis,kimlik sağlayıcıların birbirleri ile konuşmasına olanak sağlayan bir formattır. Aşağıda birçok NameID tanımlayıcısı görüyorsunuz.
- urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- urn:oasis:names:tc:SAML:2.0:nameid-format:transient
- urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
- urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
- urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
- urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName
- urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
- urn:oasis:names:tc:SAML:2.0:nameid-format:entity
Name ID format listesi sıralı bir listedir ve kullanılacak Name ID formatının belirlenmesinde birinci Name ID en yüksek önceliğe sahiptir. Kullanıcı, SSO işlemini gerçekleştirirken kullanılacak bir NameID format belirtmezse, bu listedeki ilk NameID girdisi seçilir ve desteklenir.
Anlaşılan ve seçilip gönderilen NameID format verileri aşağıdaki gibi olabilir.
- unspecified
- emailAddress — örn. eren@company.com
- X509SubjectName — örn. CN=eren,O=Company Ltd.,C=TR
- WindowsDomainQualifiedName — örn. CompanyDomain\Eren
- kerberos– örn. eren@realm
- entity — Saml tabanlı hizmetler sağlayan ve bir URI ile ifade edilebilen varlıkları tanımlamak için kullanılır
- persistent — Genellikle yerel hesaplarla SP yi bağlamak için kullanılır. Her özel servis için farklı farklı hesap tanımlanması önerilir
- transient — IdP de “tek seferlik kullanım” için oluşturulan kimliğe denk gelir. SP tarafında anonimlik özelliğini desteklerler.
SAML Assertion Nedir?
SAML Assertion aslında IDP tarafından kimliği doğrulanmış kullanıcılara, SP a erişebilmeleri için verilen bilettir. SP ve IDP daha önce bir SAML Assertion formatında anlaşmışlardır. SP, IDP tarafından oluşturulmuş ve kullanıcı ajanı vasıtasıyla iletilmiş SAML Assertion u kontrol eder. Eğer geçerli ve imzalanmış bir bilet ise kullanıcıya erişimi verir. Aşağıdaki görsel bize genel olarak bir SAML Assertion un ne gibi verileri içerdiğine dair bir fikir verebilir.
- Name ID: Kullanıcı için doğru kimlik formatı seçilir
- Method of AuthN: Kullanıcının kim olduğunu doğrularken aynı zamanda bir güven seviyesi oluşur. SP, Kullanıcının getirdiği SAML Assertion a bakıp, belli bir güven seviyesinin altında kalan kullanıcılara erişim vermeyip daha güçlü bir kimlik doğrulama metoduyla tekrar kimliklerini doğrulamaları için IDP ye yönlendirebilir.
- Attributes: Kullanıcıyla alakalı gerekli bilgiler(İsim,soyisim,email,kullanıcı ismi, Domain grubu gibi..)
- Conditions: Replay saldırıları tarzı denemelerin önüne geçmek için geçerli zaman bilgisi veya bu biletin kime gönderildiği gibi bilgiler SAML Assertion a eklenmelidir.
- Issuer ID: SAML Assertion un kim tarafından oluşturulduğu bilgisi
Son olarak SAML Assertion imzalanıp ve hashlenip SP ye gönderilir.
SAML ile Kimlik Doğrulama
SAML ile kimlik doğrulama işlemleri 2 farklı yöntemle yapılabilir;
1- IdP Tarafından Başlatılan (IdP Initiated)
Bu metodda kullanıcı ilk olarak IdP ye erişip kimlik doğrulama işlemlerini gerçekleştirir. Yetkilendirme işlemlerini de gerçekleştirdikten sonra IdP tarafından kullanıcıya SAML Assertion sağlanır. İnternet tarayıcı aracılığı ile SAML Assertion servis sağlayıcıya iletilir. Servis sağlayıcı bu bileti doğrularsa erişim sağlanır ve oturum başlar.
2- Servis Sağlayıcı Tarafından Başlatılan (SP Initiated)
Kullanıcı ilk olarak servis sağlayıcıya gidip erişmeye çalışır. Servis sağlayıcı kullanıcıyı kimlik doğrulama isteği ile beraber IdP ye yönlendirir. Kullanıcı burada kimlik doğrulama ve yetkilendirme işlemlerini gerçekleştirdikten sonra elde edilen bilet internet tarayıcısı aracılığı ile servis sağlayıcıya gönderilir ve eğer bilet doğrulanırsa erişim sağlanır.
Servis Sağlayıcı lar ve IdP ler arasında SAML Assertion lar ve mesajlar SAML2.0 Bindings denilen metotlarla iletilir. Bunlardan önemli olan birkaç tanesine örnek vermek gerekirse HTTP redirect binding, servis sağlayıcı tarafından IdP ye iletilen kimlik doğrulama istekleri için kullanılır. HTTP Post binding ise en sık kullanılandır. Hem SAML Assertion ların iletilmesinde hem de kimlik doğrulama isteklerinde kullanılabilir.
Aşağıdaki örnek “SAML Response” u incelemenizin büyük yararı olacaktır.
Teşekkürler,
Kaynaklar
