AWS Active Directory Federation Service ile Federasyon
There are lots of documentation(blog posts etc.) about AWS in English that’s why I have been writing in Turkish. I hope this will be informative for Turkish readers.
Regards.
Merhaba,
Security Assertion Markup Language(SAML), security domain’leri(party’ler) arasında authentication ve authorization verisinin alışverişini sağlayan xml tabanlı sistemdir. Benzer bir ifade ile; identity provider ile service provider arasında “authorization&authentication data exchange” için kullanılan bir katmandır. SAML tabanlı sistemlerin listesi için bir web adresini kaynaklar kısmında paylaştım. Yazımın konusu olacağı için belirteyim, saml uyumlu identity provider’lardan biri de Active Directory Federation Service’tir.
Dizin hizmeti(identity store) olarak genelde MS Active Directory kullanıldığı için identity provider olarak ADFS’i seçebiliriz. ADFS yerine bir başka identity provider’ı, Shibboleth’ı, kullanabilirsiniz.AWS’nin blog’larında her ikisini de anlatan post’lar mevcut.İlk olarak ADFS’i inceleyelim. Sonrasında diğer idP hakkında yazacağım.(Kısaltma – identity provider:idP)
**Yazıya devam etmeden önce konu bütünlüğü açısında, AWS IAM Kimlik ve Erişim Yönetimi başlıklı yazımı incelemenizi öneriyorum. Web adresini kaynaklar kısmında bulabilirsiniz.**
11.Kasım.2013’deki blog post’u ile AWS, SAML desteğini aws sistemine dahil ettiğini duyurmuş.Böylece AWS kaynaklarına erişimde (management console ve/veya api call) enterprise seviyede federated sso desteği sağlanmış. Yapı topolojik olarak aşağıdaki gibi çalışıyor.
- Kullanıcı web browser ile sso portalına bağlanır.
- Authentication evresi tamamlanır.
- ADFS’den gelen cevap, portal tarafından aws sistemine iletilir.
- AWS yönetim konsolu açılır.
ADFS ile Federated SSO işleyişini test etmek için oluşturduğum lab envanterimden bahsedeyim. Sanallaştırma platform olarak windows 8.1 hyper-v kullandım. Active Directory Domain Service’leri, Windows Server 2012 R2 sunucu üzerinde çalışmaktaydı. ADFS ‘ide aynı sunucu üzerinde kurdum. Aynı sunucu üzerinde Certificate Authority’de kuruluydu. Roller arasındaki ADFS kurulumu oldukça rutin bir işlem olduğu için kurulum adımlarını detaylandırmayacağım. ADFS kurulumu için kaynaklar kısmında bir kaç web adresi paylaştım.
AD ve ADFS yapılarım hakkında bilgi vereyim.
ADFS servis hesabı adfssvc ‘dir. Aws-dev ve adfs-production grup’larını, AWS IAM role’lerine karşılık kullandım. Oluşturduğum IAM role’lerinden yazının ilerleyen kısımlarında bahsedeceğim. Jane ve John account’ları da test account’larıdır 🙂
ADFS url’lerinin bazıları aşağıdaki gibidir.
- https://sts.barisaws.com/adfs/services/trust/2005/issuedtokenmixedasymmetricbasic256
- https://sts.barisaws.com/adfs/services/trust/2005/issuedtokenmixedsymmetricbasic256
- https://sts.barisaws.com/adfs/services/trust/13/issuedtokenmixedasymmetricbasic256
- https://sts.barisaws.com/adfs/services/trust/13/issuedtokenmixedsymmetricbasic256
- https://sts.barisaws.com/adfs/services/trust/2005/issuedtokenmixedasymmetricbasic256
- https://sts.barisaws.com/adfs/ls/
- https://sts.barisaws.com/adfs/services/trust/2005/certificatemixed
- https://sts.barisaws.com/adfs/services/trust/mex
AWS tarafında saml provider’ını oluştururken adfs servisinizden tedarik edeceğiniz metadata xml dosyasını kullanmanız gerekecek. Test ortamımdaki adfs servisinden metadata xml’ini https://sts.barisaws.com/FederationMetadata/2007-06/FederationMetadata.xml adresinden tedarik ettim. Bu adres standart bir adrestir. Üstteki adresi google chrome ile browse ederek *.xml dosyasını kaydediniz. IE 11 ile browse ederek katdettiğinizde *.xml dokumanında problem çıkıyor(aws tarafındaki işlemlerde hata veriyor ve *.xml tanınamıyor!)
AWS tarafında identity provide oluşturacağız.Daha önce bahsettiğim xml dosyasını bu aşamada kullanacaksınız.Bu aşamadan sonra adfs trust yapılandırması ile devam edeceğiz.
Üstteki sihirbazı kullanarak aws iam servis altında identity provider’ınızı oluşturuyorsunuz. Oluşturduğum idP’nin detayı aşağıdaki gibidir.
idP ismini ve arn(amazon resource number) ismi not alınız. Daha sonra adfs tarafında trust oluştururken kullanacaksınız.
AD tarafında oluşturduğum group objelerine karşılık aws iam servisinden iki adet role oluşturdum. Role’lere farklı izinler verdim. AD tarafındaki dev veya prod group’una üye olan account(Ör: john veya jane) aws konsoluna giriş yaptığında, ilgili role’ün sahip olduğu izinler ile aws kaynaklarına erişebilecek.
AWS-DEV role’ünün izinleri:
AWS-Production role’ünün izinleri:
Rollerden biri tüm aws servislerine tam erişim iznine, diğeri rds servisi tam erişim iznine sahiptir!
- arn:aws:iam::700691817817:role/AWS-Production
- arn:aws:iam::700691817817:role/AWS-DEV
Her iki role’ün arn numaralarını da not alın. ADFS trust yapılandırmasında kullanacaksınız.
ADFS Trust yapılandırması ile devam ediyoruz.
“Add Relying Party Trust…” ile devam ediyoruz.
Üstteki kutucuğa aşağıdaki web adresini yazarak ilerliyoruz.
https://signin.aws.amazon.com/static/saml-metadata.xml adres aws için standart bir adrestir. Olası problemlerde aws yönetim konsolundan problem kaydı açarak veya destek aldığınız 3rd party service provider’dan sorgulayabilirsiniz.
Sonraki ekranda Display Name belirliyorsunuz. Uygun bir isim belirleyerek devam ediyoruz. Multi factor authentication ayarları aşaması geliyor. Şu an mfa tanımlamıyorum.
Devam.
Permit ile devam ediyoruz.
Yapılandırmayı kontrol ederek sihirbazı tanamlayınız. Relying Party Trust oluşmuş oldu. Trust özelliklerinden claim rule’larını düzenleyeceğiz.
Daha önce hazırladığım için üstteki context menüde “update from federation …” ifadesi görünüyor. Oluşturmanız gereken claim rule’lar aşağıdaki gibidir.
Bunları nasıl oluşturacağınız konusunda kaynaklar kısmında web adresleri belirttim. Oluşturduğum dört kuralın detaylarını aşağıdaki resmedeyim.
Rule 1
Rule 2
Outgoing claim type kutusundaki adres https://aws.amazon.com/SAML/Attributes/RoleSessionName şeklindedir. AD ‘de oluşturduğunuz user account’larda e-mail adresi attribute’u dolu olmalıdır!
Rule 3
Custom rule kutusuna yazmanız gereken code için yine kaynaklar kısmında belirttiğim adresleri kullanabilirsiniz.
Rule 4
Üstteki kutuda, daha önce not almanızı önerdiğim arn ifadelerini kullanıyoruz. Claim rule’ları kısmına dört adet kural eklemiş olduk. Sihirbazı onaylayıp kapatabiliriz. Test aşamasına geldik 🙂
Yapının topolojik olarak nasıl çalıştığını hatırlayınız. Kullanıcı bir portala bağlanıyordu. Portalın web adresi https://sts.barisaws.com/adfs/ls/IdpInitiatedSignOn.aspx şeklindedir(kendi ortamızda gerekli isim değişikliğini yapınız!)
Sign in ile devam. Credential girişi için pop-up çıkacak.
AD ‘de oluşturduğunuz test kullanıcılarından biri ile giriş yapabilirsiniz.
Federated Login işlemi başarılı oldu. Giriş yapan kullanıcı, IAM role’lerinin yetkisine göre aws yönetim konsolunda yönetimsel işlemler yapılabilir.
Üstteki örnekte; barisaws\john.doe kullanıcısının cloudsearch isimli amazon web servisini yönetme hakkı yokmuş 🙂 Çünkü aws-production role’üne sadece rds full access izni vermiştim!
AWS kaynaklarına erişimde ADFS ile enterprise federation single sign on yaklaşımını incelemiş olduk. AD yapınıza yeni AD Group’ları eklerseniz, AWS IAM Role’lerine de aynı isimle eklemeler yaparak istenilen izinleri tanımlayabilirsiniz. Veya AWS IAM role’leri ile AD User & Group ‘larınızı eşleştirmek için farklı stratejiler geliştirebilirsiniz. AWS dokumanlarını incelerken bana en anlamlı gelen bu yöntemdi 🙂
Herkese sorunsuz ve neşeli günler dilerim.
Kaynaklar:
https://aydogmusoglu.com/aws-iam-kimlik-ve-erisim-ynetimi.html
http://en.wikipedia.org/wiki/SAML-based_products_and_services
http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
https://aws.amazon.com/blogs/aws/aws-identity-and-access-management-using-saml/
http://blogs.technet.com/b/rmilne/archive/2014/04/28/how-to-install-adfs-2012-r2-for-office-365.aspx