Nasıl yapılır: Azure Access Control Hizmetinden Geçiş
Uyarı
Bu içerik eski Azure AD v1.0 uç noktasına yöneliktir. Yeni projeler için Microsoft kimlik platformu kullanın.
Azure Active Directory 'nin (Azure AD) bir hizmeti olan Microsoft Azure Access Control Hizmeti (ACS), 7 Kasım 2018'de kullanımdan kaldırılacaktır. O zamana kadar Access Control kullanan uygulamalar ve hizmetler farklı bir kimlik doğrulama mekanizmasına tamamen geçirilmelidir. Bu makalede, Access Control kullanımınızı kullanımdan kaldırmayı planladığınız için geçerli müşterilere yönelik öneriler açıklanır. Şu anda Access Control kullanmıyorsanız herhangi bir işlem yapmanız gerekmez.
Genel Bakış
Access Control, web uygulamalarınıza ve hizmetlerinize erişim için kullanıcıların kimliğini doğrulamanın ve yetkilendirmenin kolay bir yolunu sunan bir bulut kimlik doğrulama hizmetidir. Birçok kimlik doğrulaması ve yetkilendirme özelliğinin kodunuz dışında sınanmasını sağlar. Access Control öncelikle Microsoft .NET istemcilerinin, ASP.NET web uygulamalarının ve Windows Communication Foundation (WCF) web hizmetlerinin geliştiricileri ve mimarları tarafından kullanılır.
Access Control kullanım örnekleri üç ana kategoriye ayrılabilir:
- Azure Service Bus ve Dynamics CRM dahil olmak üzere belirli Microsoft bulut hizmetlerinde kimlik doğrulaması. İstemci uygulamaları, çeşitli eylemler gerçekleştirmek üzere bu hizmetlerde kimlik doğrulaması yapmak için Access Control belirteçleri alır.
- Hem özel hem de önceden paketlenmiş (SharePoint gibi) web uygulamalarına kimlik doğrulaması ekleme. Web uygulamaları Access Control "pasif" kimlik doğrulamasını kullanarak Bir Microsoft hesabıyla (eski adı Live ID) ve Google, Facebook, Yahoo, Azure AD ve Active Directory Federasyon Hizmetleri (AD FS) (AD FS) hesaplarıyla oturum açmayı destekleyebilir.
- Access Control tarafından verilen belirteçlerle özel web hizmetlerinin güvenliğini sağlama. Web hizmetleri , "etkin" kimlik doğrulaması kullanarak yalnızca Access Control ile kimlik doğrulaması yapmış bilinen istemcilere erişim izni vermelerini sağlayabilir.
Bu kullanım örneklerinin her biri ve önerilen geçiş stratejileri aşağıdaki bölümlerde ele alınmaktadır.
Uyarı
Çoğu durumda, mevcut uygulamaları ve hizmetleri daha yeni teknolojilere geçirmek için önemli kod değişiklikleri gerekir. Olası kesintileri veya kapalı kalma sürelerini önlemek için geçişinizi planlamaya ve yürütmeye hemen başlamanızı öneririz.
Access Control aşağıdaki bileşenlere sahiptir:
- Kimlik doğrulama isteklerini alan ve karşılığında güvenlik belirteçleri veren bir güvenli belirteç hizmeti (STS).
- Access Control ad alanlarını oluşturduğunuz, sildiğiniz ve etkinleştirdiğiniz ve devre dışı bırakacağınız klasik Azure portalı.
- Access Control ad alanlarını özelleştirip yapılandırdığınız ayrı bir Access Control yönetim portalı.
- Portalların işlevlerini otomatikleştirmek için kullanabileceğiniz bir yönetim hizmeti.
- Sorunları Access Control belirteçlerin çıkış biçimini işlemek üzere karmaşık mantık tanımlamak için kullanabileceğiniz bir belirteç dönüştürme kuralı altyapısı.
Bu bileşenleri kullanmak için bir veya daha fazla Access Control ad alanı oluşturmanız gerekir. Ad alanı, uygulamalarınızın ve hizmetlerinizin iletişim kurduğunu ayrılmış bir Access Control örneğidir. Ad alanı diğer tüm Access Control müşterilerinden yalıtılır. Diğer Access Control müşterileri kendi ad alanlarını kullanır. Access Control'daki bir ad alanının şuna benzer ayrılmış bir URL'si vardır:
https://<mynamespace>.accesscontrol.windows.net
STS ve yönetim işlemleriyle tüm iletişim bu URL'de gerçekleştirilir. Farklı amaçlar için farklı yollar kullanırsınız. Uygulamalarınızın veya hizmetlerinizin Access Control kullanıp kullanmadığını belirlemek için https://< namespace.accesscontrol.windows.net> adresine gelen trafiği izleyin. Bu URL'ye gelen tüm trafik Access Control tarafından işlenir ve sonlandırılmalıdır.
Bunun istisnası, trafiğin olmasıdır https://accounts.accesscontrol.windows.net. Bu URL'ye gelen trafik zaten farklı bir hizmet tarafından işlenir ve Access Control kullanımdan kaldırılmasından etkilenmez.
Access Control hakkında daha fazla bilgi için bkz. Access Control Service 2.0 (arşivlenmiş).
Uygulamalarınızdan hangilerinin etkilendiğini öğrenin
Uygulamalarınızdan hangilerinin ACS'nin kullanımdan kaldırılmasından etkilendiğini öğrenmek için bu bölümdeki adımları izleyin.
ACS PowerShell'i indirme ve yükleme
PowerShell Galerisi gidin ve Acs.Namespaces dosyasını indirin.
komutunu çalıştırarak modülü yükleme
Install-Module -Name Acs.Namespaceskomutunu çalıştırarak tüm olası komutların listesini alın
Get-Command -Module Acs.NamespacesBelirli bir komutla ilgili yardım almak için şunu çalıştırın:
Get-Help [Command-Name] -Fullburada
[Command-Name]ACS komutunun adıdır.
ACS ad alanlarınızı listeleme
Connect-AcsAccount cmdlet'ini kullanarak ACS'ye bağlanın.
Komutları yürütmek için önce komutunu çalıştırmanız
Set-ExecutionPolicy -ExecutionPolicy Bypassve bu aboneliklerin yöneticisi olmanız gerekebilir.Get-AcsSubscription cmdlet'ini kullanarak kullanılabilir Azure aboneliklerinizi listeleyin.
Get-AcsNamespace cmdlet'ini kullanarak ACS ad alanlarınızı listeleyin.
Hangi uygulamaların etkilendiğini denetleyin
Önceki adımdaki ad alanını kullanın ve
https://<namespace>.accesscontrol.windows.netÖrneğin, ad alanlarının biri contoso-test ise
https://contoso-test.accesscontrol.windows.netACS'nin kullanımdan kaldırılmasından etkilenecek uygulamaların listesini görmek için Güven ilişkileri'nin altında Bağlı olan taraf uygulamaları'nı seçin.
Sahip olduğunuz diğer TÜM ACS ad alanları için 1-2 arası adımları yineleyin.
Kullanımdan kaldırma zamanlaması
Kasım 2017 itibarıyla tüm Access Control bileşenleri tam olarak desteklenmektedir ve çalışır durumdadır. Tek kısıtlama, klasik Azure portalı aracılığıyla yeni Access Control ad alanları oluşturamamanızdır.
Access Control bileşenlerini kullanımdan kaldırma zamanlaması aşağıdadır:
- Kasım 2017: Klasik Azure portalında Azure AD yönetici deneyimi kullanımdan kaldırıldı. Bu noktada, Access Control için ad alanı yönetimi yeni, ayrılmış bir URL'de kullanılabilir:
https://manage.windowsazure.com?restoreClassic=true. Mevcut ad alanlarınızı görüntülemek, ad alanlarını etkinleştirmek ve devre dışı bırakmak ve isterseniz ad alanlarını silmek için bu URL'yi kullanın. - 2 Nisan 2018: Klasik Azure portalı tamamen kullanımdan kaldırıldı, yani Access Control ad alanı yönetimi artık herhangi bir URL aracılığıyla kullanılamıyor. Bu noktada, Access Control ad alanlarınızı devre dışı bırakamaz, etkinleştiremez, silemez veya numaralandıramazsınız. Ancak, Access Control yönetim portalı tamamen işlevsel olacak ve konumunda
https://<namespace>.accesscontrol.windows.netyer alacaktır. Access Control diğer tüm bileşenleri normal çalışmaya devam eder. - 7 Kasım 2018: Tüm Access Control bileşenleri kalıcı olarak kapatılır. Buna Access Control yönetim portalı, yönetim hizmeti, STS ve belirteç dönüştürme kuralı altyapısı dahildir. Bu noktada, Access Control gönderilen tüm istekler (konumunda
<namespace>.accesscontrol.windows.netbulunur) başarısız olur. Bu süreden önce tüm mevcut uygulamaları ve hizmetleri diğer teknolojilere geçirmiş olmanız gerekir.
Not
İlke, belirli bir süre için belirteç istemeyen ad alanlarını devre dışı bırakır. Eylül 2018'in başlarından itibaren, bu süre şu anda 14 günlük hareketsizliktedir, ancak önümüzdeki haftalarda 7 günlük etkinliksizlik süresine kısaltılacaktır. Şu anda devre dışı bırakılmış Access Control ad alanınız varsa ad alanlarını yeniden etkinleştirmek için ACS PowerShell'i indirip yükleyebilirsiniz.
Geçiş stratejileri
Aşağıdaki bölümlerde, Access Control'den diğer Microsoft teknolojilerine geçiş için üst düzey öneriler açıklanmaktadır.
Microsoft bulut hizmetlerinin istemcileri
Access Control tarafından verilen belirteçleri kabul eden her Microsoft bulut hizmeti artık en az bir alternatif kimlik doğrulama biçimini destekliyor. Doğru kimlik doğrulama mekanizması her hizmet için farklılık gösterir. Resmi yönergeler için her hizmetin belirli belgelerine başvurmanızı öneririz. Kolaylık sağlamak için her belge kümesi burada sağlanır:
| Hizmet | Rehber |
|---|---|
| Azure Service Bus | Paylaşılan erişim imzalarına geçiş |
| Azure Service Bus Geçişi | Paylaşılan erişim imzalarına geçiş |
| Azure Yönetilen Önbelleği | Redis için Azure Cache’e geçiş |
| Azure DataMarket | Azure AI hizmetleri API'lerine geçiş |
| BizTalk Services | Azure App Service Logic Apps özelliğine geçiş |
| Azure Media Services | Azure AD kimlik doğrulamasına geçiş |
| Azure Backup | Azure Backup aracısını yükseltme |
SharePoint müşterileri
SharePoint 2013, 2016 ve SharePoint Online müşterileri bulutta, şirket içinde ve karma senaryolarda kimlik doğrulaması amacıyla ACS'yi uzun süredir kullanıyor. Bazı SharePoint özellikleri ve kullanım örnekleri ACS'nin kullanımdan kaldırılmasından etkilenirken, diğerleri etkilenmez. Aşağıdaki tabloda ACS'yi kullanan en popüler SharePoint özelliklerinden bazıları için geçiş kılavuzu özetlenmiştir:
| Özellik | Rehber |
|---|---|
| Azure AD kullanıcıların kimliğini doğrulama | Daha önce, Azure AD kimlik doğrulaması için SharePoint tarafından gereken SAML 1.1 belirteçlerini desteklemiyordu ve ACS, SharePoint'in Azure AD belirteç biçimleriyle uyumlu olmasını sağlayan bir aracı olarak kullanılıyordu. Artık şirket içi SharePoint uygulama Azure AD Uygulama Galerisi'nde SharePoint'i doğrudan Azure AD bağlayabilirsiniz. |
| Şirket içi SharePoint'te sunucudan sunucuya kimlik doğrulaması & uygulama kimlik doğrulaması | ACS'nin kullanımdan kaldırılmasından etkilenmez; değişiklik gerekmez. |
| SharePoint eklentileri için düşük güven yetkilendirmesi (barındırılan sağlayıcı ve SharePoint barındırılan) | ACS'nin kullanımdan kaldırılmasından etkilenmez; değişiklik gerekmez. |
| SharePoint bulut karma araması | ACS'nin kullanımdan kaldırılmasından etkilenmez; değişiklik gerekmez. |
Pasif kimlik doğrulaması kullanan web uygulamaları
Kullanıcı kimlik doğrulaması için Access Control kullanan web uygulamaları için Access Control, web uygulaması geliştiricilerine ve mimarlarına aşağıdaki özellikleri ve özellikleri sağlar:
- Windows Identity Foundation (WIF) ile derin tümleştirme.
- Google, Facebook, Yahoo, Azure Active Directory ve AD FS hesapları ve Microsoft hesaplarıyla federasyon.
- Şu kimlik doğrulama protokolleri için destek: OAuth 2.0 Taslak 13, WS-Trust ve Web Hizmetleri Federasyonu (WS-Federasyon).
- Şu belirteç biçimleri için destek: JSON Web Belirteci (JWT), SAML 1.1, SAML 2.0 ve Basit Web Belirteci (SWT).
- WIF ile tümleştirilmiş, kullanıcıların oturum açmak için kullandıkları hesap türünü seçmesine olanak tanıyan bir ev bölgesi bulma deneyimi. Bu deneyim web uygulaması tarafından barındırılır ve tamamen özelleştirilebilir.
- Web uygulaması tarafından Access Control'dan alınan taleplerin zengin özelleştirmesine olanak tanıyan belirteç dönüşümü:
- Kimlik sağlayıcılarından gelen talepleri geçirin.
- Ek özel talepler ekleme.
- Belirli koşullar altında talep vermek için basit if-then mantığı.
Ne yazık ki, bu eşdeğer özelliklerin tümünü sunan tek bir hizmet yoktur. Access Control hangi özelliklerine ihtiyacınız olduğunu değerlendirmeli ve ardından Microsoft Entra kimliği, Azure Active Directory B2C (Azure AD B2C) veya başka bir bulut kimlik doğrulama hizmetini kullanma arasında seçim yapmalısınız.
Microsoft Entra Kimliğine geçiş
Dikkate alınması gereken bir yol, uygulamalarınızı ve hizmetlerinizi doğrudan Microsoft Entra kimliğiyle tümleştirmektir. Microsoft Entra kimliği, Microsoft iş veya okul hesapları için bulut tabanlı kimlik sağlayıcısıdır. Microsoft Entra Kimliği, Microsoft 365, Azure ve daha fazlası için kimlik sağlayıcısıdır. Access Control benzer federasyon kimlik doğrulama özellikleri sağlar, ancak tüm Access Control özelliklerini desteklemez.
Birincil örnek, Facebook, Google ve Yahoo gibi sosyal kimlik sağlayıcılarıyla federasyondur. Kullanıcılarınız bu tür kimlik bilgileriyle oturum açarsa, Microsoft Entra kimliği sizin için çözüm değildir.
Microsoft Entra kimliği de Access Control ile tam olarak aynı kimlik doğrulama protokollerini desteklemez. Örneğin, hem Access Control hem de Microsoft Entra kimliği OAuth'u desteklese de, her uygulama arasında küçük farklar vardır. Farklı uygulamalar, geçişin bir parçası olarak kodu değiştirmenizi gerektirir.
Ancak Microsoft Entra kimliği, Access Control müşterilerine çeşitli olası avantajlar sağlar. Bulutta barındırılan ve yaygın olarak Access Control müşteriler tarafından kullanılan Microsoft iş veya okul hesaplarını yerel olarak destekler.
bir Microsoft Entra kiracısı, AD FS aracılığıyla bir veya daha fazla şirket içi Active Directory örneğine de bağlanabilir. Bu şekilde, uygulamanız bulut tabanlı kullanıcıların ve şirket içinde barındırılan kullanıcıların kimliğini doğrulayabilir. Ayrıca, WIF kullanarak bir web uygulamasıyla tümleştirmeyi nispeten kolay hale getiren WS-Federation protokollerini de destekler.
Aşağıdaki tabloda, web uygulamalarıyla ilgili Access Control özellikleri, Microsoft Entra kimliğinde kullanılabilen özelliklerle karşılaştırılır.
Üst düzeyde, kullanıcıların yalnızca Microsoft iş veya okul hesaplarıyla oturum açmasına izin verirseniz Microsoft Entra kimliği geçişiniz için muhtemelen en iyi seçenektir.
| Özellik | Access Control desteği | Microsoft Entra Kimliği desteği |
|---|---|---|
| Hesap türleri | ||
| Microsoft iş veya okul hesapları | Desteklenir | Desteklenir |
| Windows Server Active Directory ve AD FS hesapları | - Microsoft Entra kiracı ile federasyon aracılığıyla desteklenir - AD FS ile doğrudan federasyon aracılığıyla desteklenir |
Yalnızca Microsoft Entra kiracı ile federasyon aracılığıyla desteklenir |
| Diğer kurumsal kimlik yönetim sistemlerinden hesaplar | - Microsoft Entra kiracı ile federasyon yoluyla mümkündür - Doğrudan federasyon aracılığıyla desteklenir |
Microsoft Entra kiracı ile federasyon yoluyla mümkündür |
| Kişisel kullanım için Microsoft hesapları | Desteklenir | Microsoft Entra v2.0 OAuth protokolü aracılığıyla desteklenir, ancak diğer protokoller üzerinden desteklenmez |
| Facebook, Google, Yahoo hesapları | Destekleniyor | Herhangi bir şekilde desteklenmez |
| Protokoller ve SDK uyumluluğu | ||
| WIF | Destekleniyor | Desteklenir, ancak sınırlı yönergeler sağlanır |
| WS-Federation | Desteklenir | Desteklenir |
| OAuth 2.0 | Taslak 13 desteği | En modern belirtim olan RFC 6749 desteği |
| WS-Trust | Desteklenir | Desteklenmez |
| Belirteç biçimleri | ||
| JWT | Beta sürümünde desteklenir | Destekleniyor |
| SAML 1.1 | Destekleniyor | Önizleme |
| SAML 2.0 | Desteklenir | Desteklenir |
| SWT | Desteklenir | Desteklenmez |
| Özelleştirmeler | ||
| Özelleştirilebilir ev bölgesi bulma/hesap çekme kullanıcı arabirimi | Uygulamalara eklenebilen indirilebilir kod | Desteklenmez |
| Özel belirteç imzalama sertifikalarını karşıya yükleme | Desteklenir | Desteklenir |
| Belirteçlerdeki talepleri özelleştirme | - Kimlik sağlayıcılarından gelen giriş taleplerini geçirme - Kimlik sağlayıcısından talep olarak erişim belirteci alma - Giriş taleplerinin değerlerine göre çıkış talepleri verme - Sabit değerlerle çıkış talepleri verme |
- Federasyon kimlik sağlayıcılarından gelen talepler geçirilemez - Kimlik sağlayıcısından talep olarak erişim belirteci alınamıyor - Giriş taleplerinin değerlerine göre çıkış talepleri verilemez - Sabit değerlerle çıkış talepleri verebilir - Microsoft Entra kimliğiyle eşitlenen kullanıcıların özelliklerine göre çıkış talepleri verebilir |
| Otomasyon | ||
| Yapılandırma ve yönetim görevlerini otomatikleştirme | Access Control Yönetim Hizmeti aracılığıyla desteklenir | Microsoft Graph API kullanılarak desteklenir |
Microsoft Entra Kimliğinin uygulamalarınız ve hizmetleriniz için en iyi geçiş yolu olduğuna karar verirseniz, uygulamanızı Microsoft Entra kimlikle tümleştirmenin iki yolunu bilmeniz gerekir.
Microsoft Entra kimliğiyle tümleştirmek üzere WS-Federation veya WIF kullanmak için, Galeri olmayan bir uygulama için federasyon çoklu oturum açmayı yapılandırma başlığında açıklanan yaklaşımı izlemenizi öneririz. Makale, SAML tabanlı çoklu oturum açma için Microsoft Entra kimliğini yapılandırmayı ifade eder, ancak WS-Federasyon'u yapılandırmak için de çalışır. Bu yaklaşımı izlemek için Microsoft Entra kimliği P1 veya P2 lisansı gerekir. Bu yaklaşımın iki avantajı vardır:
- Microsoft Entra belirteci özelleştirme esnekliğine sahip olursunuz. Microsoft Entra kimliğiyle verilen talepleri, Access Control tarafından verilen talepler ile eşleşecek şekilde özelleştirebilirsiniz. Bu özellikle kullanıcı kimliği veya Ad Tanımlayıcısı talebi içerir. Teknolojileri değiştirdikten sonra kullanıcılarınız için tutarlı kullanıcı Kimlik Belirleyicileri almaya devam etmek için, Microsoft Entra kimliği tarafından verilen kullanıcı kimliklerinin Access Control tarafından verilen kimliklerle eşleştiğinden emin olun.
- Uygulamanıza özgü ve denetlediğiniz bir yaşam süresine sahip bir belirteç imzalama sertifikası yapılandırabilirsiniz.
Not
Bu yaklaşım için Microsoft Entra kimliği P1 veya P2 lisansı gerekir. Access Control müşterisiyseniz ve bir uygulama için çoklu oturum açmayı ayarlamak için premium lisansa ihtiyacınız varsa bizimle iletişime geçin. Kullanmanız için geliştirici lisansları sağlamak istiyoruz.
Alternatif bir yaklaşım, WS-Federation'u ayarlamak için biraz farklı yönergeler sağlayan bu kod örneğini izlemektir. Bu kod örneği WIF kullanmaz, bunun yerine ASP.NET 4.5 OWIN ara yazılımını kullanır. Ancak uygulama kaydı yönergeleri WIF kullanan uygulamalar için geçerlidir ve Microsoft Entra Kimliği P1 veya P2 lisansı gerektirmez.
Bu yaklaşımı seçerseniz, Microsoft Entra kimliğinde anahtar geçişi imzalamayı anlamanız gerekir. Bu yaklaşım belirteçleri vermek için Microsoft Entra genel imzalama anahtarını kullanır. WiF varsayılan olarak imzalama anahtarlarını otomatik olarak yenilemez. Microsoft Entra Kimliği genel imzalama anahtarlarını döndürüyorsa, WIF uygulamanızın değişiklikleri kabul etmeye hazır olması gerekir. Daha fazla bilgi için bkz. Microsoft Entra kimliğinde anahtar geçişi imzalama hakkında önemli bilgiler.
OpenID Connect veya OAuth protokolleri aracılığıyla Microsoft Entra kimliğiyle tümleştirebiliyorsanız, bunu yapmanızı öneririz. Microsoft Entra geliştirici kılavuzumuzda bulunan Microsoft Entra kimliğini web uygulamanızla tümleştirme hakkında kapsamlı belgelere ve yönergelere sahibiz.
Azure Active Directory B2C'ye geçiş
Dikkate alınması gereken diğer geçiş yolu Azure AD B2C'dir. Azure AD B2C, Access Control gibi geliştiricilerin kimlik doğrulama ve kimlik yönetimi mantığını bulut hizmetine dış kaynak olarak kullanmalarına olanak tanıyan bir bulut kimlik doğrulama hizmetidir. Milyonlarca etkin kullanıcıya sahip olabilecek tüketiciye yönelik uygulamalar için tasarlanmış ücretli bir hizmettir (ücretsiz ve premium katmanlarla).
Access Control gibi, Azure AD B2C'nin en çekici özelliklerinden biri de birçok farklı hesap türünü desteklemesidir. Azure AD B2C ile, kullanıcıların Microsoft hesaplarını veya Facebook, Google, LinkedIn, GitHub veya Yahoo hesaplarını ve daha fazlasını kullanarak oturum açabilirsiniz. Azure AD B2C ayrıca kullanıcıların uygulamanız için özel olarak oluşturduğu "yerel hesapları" veya kullanıcı adını ve parolaları da destekler. Azure AD B2C, oturum açma akışlarınızı özelleştirmek için kullanabileceğiniz zengin genişletilebilirlik de sağlar.
Ancak Azure AD B2C, müşterilerin gerektirebileceği kimlik doğrulama protokollerinin ve belirteç biçimlerinin Access Control desteklemez. Ayrıca Azure AD B2C'yi kimlik sağlayıcısından, Microsoft'tan veya başka bir şekilde kullanıcı hakkında ek bilgi almak ve sorgulamak için kullanamazsınız.
Aşağıdaki tabloda, web uygulamalarıyla ilgili Access Control özellikleri Azure AD B2C'de bulunanlarla karşılaştırılır. Yüksek düzeyde Azure AD B2C, uygulamanız tüketiciyle karşılaşıyorsa veya birçok farklı hesap türünü destekliyorsa geçişiniz için muhtemelen doğru seçimdir.
| Özellik | Access Control desteği | B2C desteğini Azure AD |
|---|---|---|
| Hesap türleri | ||
| Microsoft iş veya okul hesapları | Destekleniyor | Özel ilkeler aracılığıyla desteklenir |
| Windows Server Active Directory ve AD FS'den hesaplar | AD FS ile doğrudan federasyon aracılığıyla desteklenir | Özel ilkeler kullanılarak SAML federasyonu aracılığıyla desteklenir |
| Diğer kurumsal kimlik yönetim sistemlerinden hesaplar | WS-Federation aracılığıyla doğrudan federasyon aracılığıyla desteklenir | Özel ilkeler kullanılarak SAML federasyonu aracılığıyla desteklenir |
| Kişisel kullanım için Microsoft hesapları | Desteklenir | Desteklenir |
| Facebook, Google, Yahoo hesapları | Desteklenir | Facebook ve Google yerel olarak desteklenir, Yahoo özel ilkeler kullanılarak OpenID Connect federasyonu aracılığıyla desteklenir |
| Protokoller ve SDK uyumluluğu | ||
| Windows Identity Foundation (WIF) | Desteklenir | Desteklenmez |
| WS-Federation | Desteklenir | Desteklenmez |
| OAuth 2.0 | Taslak 13 desteği | En modern belirtim olan RFC 6749 desteği |
| WS-Trust | Desteklenir | Desteklenmez |
| Belirteç biçimleri | ||
| JWT | Beta sürümünde desteklenir | Desteklenir |
| SAML 1.1 | Desteklenir | Desteklenmez |
| SAML 2.0 | Desteklenir | Desteklenmez |
| SWT | Desteklenir | Desteklenmez |
| Özelleştirmeler | ||
| Özelleştirilebilir giriş bölgesi bulma/hesap seçme kullanıcı arabirimi | Uygulamalara eklenebilen indirilebilir kod | Özel CSS aracılığıyla tamamen özelleştirilebilir kullanıcı arabirimi |
| Özel belirteç imzalama sertifikalarını karşıya yükleme | Desteklenir | Özel ilkeler aracılığıyla desteklenen sertifikalar değil, özel imzalama anahtarları |
| Belirteçlerdeki talepleri özelleştirme | - Kimlik sağlayıcılarından gelen giriş taleplerini geçirme - Kimlik sağlayıcısından erişim belirtecini talep olarak alma - Giriş taleplerinin değerlerine göre çıkış talepleri verme - Sabit değerlerle çıkış talepleri verme |
- Kimlik sağlayıcılarından talepleri geçirebilir; bazı talepler için gereken özel ilkeler - Kimlik sağlayıcısından erişim belirteci talep olarak alınamıyor - Özel ilkeler aracılığıyla giriş taleplerinin değerlerine göre çıkış talepleri verebilir - Özel ilkeler aracılığıyla sabit değerlerle çıkış talepleri verebilir |
| Otomasyon | ||
| Yapılandırma ve yönetim görevlerini otomatikleştirme | Access Control Yönetim Hizmeti aracılığıyla desteklenir | - Microsoft Graph API kullanarak izin verilen kullanıcıların oluşturulması - B2C kiracıları, uygulamaları veya ilkeleri program aracılığıyla oluşturulamıyor |
Azure AD B2C'nin uygulamalarınız ve hizmetleriniz için en iyi geçiş yolu olduğuna karar verirseniz, aşağıdaki kaynaklarla başlayın:
Ping Kimliğine veya Auth0'a geçiş
Bazı durumlarda, büyük kod değişiklikleri yapmadan web uygulamalarınızdaki Access Control değiştirmek için Microsoft Entra kimliği ve Azure AD B2C'nin yeterli olmadığını fark edebilirsiniz. Bazı yaygın örnekler şunlar olabilir:
- Google veya Facebook gibi sosyal kimlik sağlayıcılarıyla oturum açmak için WIF veya WS-Federation kullanan web uygulamaları.
- WS-Federation protokolü üzerinden bir kurumsal kimlik sağlayıcısına doğrudan federasyon gerçekleştiren web uygulamaları.
- Bir sosyal kimlik sağlayıcısı (Google veya Facebook gibi) tarafından Access Control tarafından verilen belirteçlerde talep olarak verilen erişim belirtecini gerektiren web uygulamaları.
- Kimliği veya B2C Azure AD Microsoft Entra karmaşık belirteç dönüştürme kurallarına sahip web uygulamaları yeniden üretemez.
- Birçok farklı kimlik sağlayıcısına federasyonu merkezi olarak yönetmek için ACS kullanan çok kiracılı web uygulamaları
Bu gibi durumlarda, web uygulamanızı başka bir bulut kimlik doğrulama hizmetine geçirmeyi düşünebilirsiniz. Aşağıdaki seçenekleri incelemenizi öneririz. Aşağıdaki seçeneklerin her biri Access Control benzer özellikler sunar:
Auth0, Access Control müşterileri için üst düzey geçiş kılavuzu oluşturan ve ACS'nin yaptığı neredeyse tüm özellikleri destekleyen esnek bir bulut kimliği hizmetidir.
Ping Identity , ACS'ye benzer iki çözüm sunar. PingOne, ACS ile aynı özelliklerin çoğunu destekleyen bir bulut kimlik hizmetidir ve PingFederate daha fazla esneklik sunan benzer bir şirket içi kimlik ürünüdür. Bu ürünleri kullanma hakkında daha fazla bilgi için Ping'in ACS kullanımdan kaldırma kılavuzuna bakın.
Ping Identity ve Auth0 ile çalışma amacımız, tüm Access Control müşterilerinin uygulamaları ve hizmetleri için Access Control geçmek için gereken çalışma miktarını en aza indiren bir geçiş yoluna sahip olmasını sağlamaktır.
Etkin kimlik doğrulaması kullanan web hizmetleri
Access Control tarafından verilen belirteçlerle güvenliği sağlanan web hizmetleri için Access Control aşağıdaki özellikleri ve özellikleri sunar:
- Access Control ad alanınıza bir veya daha fazla hizmet kimliği kaydedebilme. Hizmet kimlikleri belirteç istemek için kullanılabilir.
- Aşağıdaki kimlik bilgisi türlerini kullanarak belirteç istemek için OAuth WRAP ve OAuth 2.0 Taslak 13 protokolleri desteği:
- Hizmet kimliği için oluşturulan basit bir parola
- Simetrik anahtar veya X509 sertifikası kullanarak imzalı bir SWT
- Güvenilir kimlik sağlayıcısı (genellikle AD FS örneği) tarafından verilen saml belirteci
- Şu belirteç biçimleri için destek: JWT, SAML 1.1, SAML 2.0 ve SWT.
- Basit belirteç dönüştürme kuralları.
Access Control hizmet kimlikleri genellikle sunucudan sunucuya kimlik doğrulaması uygulamak için kullanılır.
Microsoft Entra Kimliğine geçiş
Bu tür bir kimlik doğrulama akışına yönelik önerimiz, Microsoft Entra kimliğine geçiş yapmaktır. Microsoft Entra kimliği, Microsoft iş veya okul hesapları için bulut tabanlı kimlik sağlayıcısıdır. Microsoft Entra Kimliği, Microsoft 365, Azure ve daha fazlası için kimlik sağlayıcısıdır.
OAuth istemci kimlik bilgilerinin Microsoft Entra uygulamasını kullanarak sunucudan sunucuya kimlik doğrulaması için Microsoft Entra kimliğini de kullanabilirsiniz. Aşağıdaki tabloda, sunucudan sunucuya kimlik doğrulamasındaki Access Control özellikleri, Microsoft Entra kimliğinde bulunanlarla karşılaştırılır.
| Özellik | Access Control desteği | Microsoft Entra Kimliği desteği |
|---|---|---|
| Web hizmetini kaydetme | Access Control yönetim portalında bağlı olan taraf oluşturma | Azure portal Microsoft Entra web uygulaması oluşturma |
| İstemci kaydetme | Access Control yönetim portalında hizmet kimliği oluşturma | Azure portal başka bir Microsoft Entra web uygulaması oluşturma |
| Kullanılan protokol | - OAuth WRAP protokolü - OAuth 2.0 Taslak 13 istemci kimlik bilgileri verme |
OAuth 2.0 istemci kimlik bilgileri verme |
| İstemci kimlik doğrulama yöntemleri | - Basit parola - İmzalı SWT - Federasyon kimlik sağlayıcısından SAML belirteci |
- Basit parola - İmzalı JWT |
| Belirteç biçimleri | -JWT - SAML 1.1 - SAML 2.0 -SWT |
Yalnızca JWT |
| Belirteç dönüştürme | - Özel talep ekleme - Basit if-then talep verme mantığı |
Özel talep ekleme |
| Yapılandırma ve yönetim görevlerini otomatikleştirme | Access Control Yönetim Hizmeti aracılığıyla desteklenir | Microsoft Graph API kullanılarak desteklenir |
Sunucudan sunucuya senaryoları uygulama hakkında rehberlik için aşağıdaki kaynaklara bakın:
- Microsoft Entra geliştirici kılavuzunun Hizmet-Hizmet bölümü
- Basit parola istemci kimlik bilgilerini kullanarak daemon kod örneği
- Sertifika istemci kimlik bilgilerini kullanarak daemon kod örneği
Ping Kimliğine veya Auth0'a geçiş
Bazı durumlarda, Microsoft Entra istemci kimlik bilgilerinin ve OAuth verme uygulamasının mimarinizdeki Access Control büyük kod değişiklikleri olmadan değiştirmek için yeterli olmadığını fark edebilirsiniz. Bazı yaygın örnekler şunlar olabilir:
- JWT'ler dışındaki belirteç biçimlerini kullanarak sunucudan sunucuya kimlik doğrulaması.
- Dış kimlik sağlayıcısı tarafından sağlanan giriş belirtecini kullanarak sunucudan sunucuya kimlik doğrulaması.
- kimlik Microsoft Entra belirteç dönüştürme kurallarıyla sunucudan sunucuya kimlik doğrulaması yeniden oluşturulamaz.
Bu durumlarda, web uygulamanızı başka bir bulut kimlik doğrulama hizmetine geçirmeyi düşünebilirsiniz. Aşağıdaki seçenekleri incelemenizi öneririz. Aşağıdaki seçeneklerin her biri Access Control benzer özellikler sunar:
Auth0, Access Control müşterileri için üst düzey geçiş kılavuzu oluşturan ve ACS'nin yaptığı hemen her özelliği destekleyen esnek bir bulut kimliği hizmetidir.
Identity , ACS'ye benzer iki çözüm sunar. PingOne, ACS ile aynı özelliklerin çoğunu destekleyen bir bulut kimliği hizmetidir ve PingFederate daha fazla esneklik sunan benzer bir şirket içi kimlik ürünüdür. Bu ürünleri kullanma hakkında daha fazla bilgi için Ping'in ACS kullanımdan kaldırma kılavuzuna bakın.
Ping Identity ve Auth0 ile çalışma amacımız, tüm Access Control müşterilerinin uygulamaları ve hizmetleri için Access Control geçmek için gereken çalışma miktarını en aza indiren bir geçiş yoluna sahip olduğundan emin olmaktır.
Geçiş kimlik doğrulaması
Rastgele belirteç dönüştürme ile geçiş kimlik doğrulaması için ACS ile eşdeğer bir Microsoft teknolojisi yoktur. Müşterilerinizin ihtiyacı buysa, Auth0 en yakın yaklaşık çözümü sağlayan kişi olabilir.
Sorular, endişeler ve geri bildirim
Birçok Access Control müşterinin bu makaleyi okuduktan sonra net bir geçiş yolu bulamayacağını anlıyoruz. Doğru planı belirleme konusunda yardıma veya rehberliğe ihtiyacınız olabilir. Geçiş senaryolarınızı ve sorularınızı tartışmak isterseniz lütfen bu sayfaya bir yorum bırakın.