Sürüm Notları

Güncelleştirme: 19 Haziran 2015

Şunlar için geçerlidir: Azure

Bu konu başlığı altında, Microsoft Azure Active Directory Access Control'ın her sürümündeki yeni özellikler (Access Control Hizmeti veya ACS olarak da bilinir) açıklanır, ürünün her sürümünün öncüllerinden nasıl farklı olduğu açıklanır ve önceki bir sürüm için yazılmış kodu etkileyebilecek hataya neden olabilecek değişiklikler vurgulanır.

• Mart 2015 - ACS Ad Alanlarını Google OpenID'ye geçirme Bağlan

• Haziran 2014 – Google Kimlik Sağlayıcısı Desteği

• Temmuz 2013 Güncelleştirme Sürüm Notları

• Aralık 2012 Güncelleştirme Sürüm Notları

• Eylül 2012 Güncelleştirme Sürüm Notları

• Haziran 2012 Güncelleştirme Sürüm Notları

• Mayıs 2012 Güncelleştirme Sürüm Notları

• Ocak 2012 Güncelleştirme Sürüm Notları

• Temmuz 2011 Güncelleştirme Sürüm Notları

Mart 2015 - ACS Ad Alanlarını Google OpenID'ye geçirme Bağlan

ACS, ACS ad alanı sahiplerinin Google kimlik sağlayıcısı yapılandırmalarını OpenID 2.0'dan OpenID Bağlan geçirmesine yardımcı olan bir özellik uygulamıştır. Müşterilerin ACS ad alanlarını OpenID Bağlan'a geçirmeleri için 1 Haziran 2015'e kadar ve arka uç kodlarını OpenID Bağlan tanımlayıcılarını kullanacak şekilde geçirmek için 1 Ocak 2017'ye kadar beklemeleri gerekir. Her son tarihten önce uygun eylemin gerçekleştirilememesi, uygulamalarınızda kesintiye neden olur. Ayrıntılı yönergeler için bkz. ACS Ad Alanlarını Google OpenID'ye Geçirme Bağlan.

Haziran 2014 – Google Kimlik Sağlayıcısı Desteği

19 Mayıs 2014 itibarıyla yeni ACS ad alanları Google'ı kimlik sağlayıcısı olarak kullanamaz. Google kullanan ve 19 Mayıs 2014'den önce kaydedilen ACS ad alanları etkilenmez. Bu yeni sınırlamanın nedeni, Google'ın ACS'nin bağımlı olduğu OpenID 2.0 desteğini kullanıma sunup yeni uygulamalar için kaydı kapatmasıdır. Google kullanan mevcut ACS ad alanları 20 Nisan 2015'e kadar çalışmaya devam edecektir. Uygulamanız Google hesapları için destek gerektiriyorsa, uygulamanızı doğrudan bu hesaplara kaydetmenizi öneririz.

Bir kullanıcı Google hesabını kullanarak yeni bir ACS ad alanında oturum açmayı denerse, bir HTTP 400 hata sayfasına yönlendirilir.

Temmuz 2013 Güncelleştirme Sürüm Notları

ACS'nin tüm kullanıcılar için kullanılabilirliğini ve performansını artırmak için ACS, her ad alanı için saniyede 30 belirteç isteği sınırı uygulamıştır. Ad alanı uzun bir süre boyunca bu sınırı aşarsa, ACS ad alanından gelen belirteç isteklerini aralık boyunca reddeder ve HTTP 429 / ACS90055 "Çok fazla istek var" hatası döndürür. Daha fazla bilgi için bkz. ACS Hizmet Sınırlamaları ve ACS Hata Kodları.

Aralık 2012 Güncelleştirme Sürüm Notları

Yeni Özellikler

ACS'nin Aralık 2012 güncelleştirmesi aşağıdaki yeni özellikleri içerir:

WS-Federation protokolü kullanılarak federasyon çoklu oturumu kapatma desteği

WS-Federation protokolünün kullanıldığı kimlik sağlayıcılarıyla çoklu oturum açmayı (SSO) etkinleştirmek için ACS kullanan web uygulamaları artık çoklu oturum kapatma özelliklerinden yararlanabilir. Bir kullanıcı bir web uygulamasının oturumunu kapattığında ACS, kullanıcıyı otomatik olarak kimlik sağlayıcısının ve aynı kimlik sağlayıcısını kullanan diğer bağlı olan taraf uygulamalarının oturumunu kapatabilir.

Bu özellik, Active Directory Federasyon Hizmetleri (AD FS) 2.0 ve Windows Live ID (Microsoft hesabı) dahil olmak üzere WS-Federation kimlik sağlayıcıları için etkinleştirilir. Çoklu oturumu kapatmayı etkinleştirmek için ACS, WS-Federation protokol uç noktaları için aşağıdaki görevleri gerçekleştirir:

• ACS, kimlik sağlayıcılarından wsignoutcleanup1.0 iletilerini tanır ve bağlı olan taraf uygulamalarına wsignoutcleanup1.0 iletileri göndererek yanıt verir.

• ACS, bağlı olan taraf uygulamalarından wsignout1.0'ıtanır ve bağlı olan taraf uygulamalarına wsignout1.0 iletileri ve bağlı olan taraf uygulamalarına wsignout1.0 iletileri göndererek yanıt verir.

Daha fazla bilgi için bkz. Kod Örneği: ASP.NET MVC 4 veWIF'de ASP.NET için Federasyon Oturumu Kapatma ve Pasif Kimlik Doğrulaması.

ACS 1.0 desteğini sonlandır

Access Control Service 1.0'dan Access Control Service 2.0'a geçiş desteği de dahil olmak üzere Access Control Service 1.0 desteği bu sürümde sona erer.

Yeni Azure Yönetim Portalı'nda Access Control ad alanlarına gezinme

Yeni Azure Yönetim Portalı (https://manage.WindowsAzure.com), Access Control ad alanlarını oluşturup yönettiğiniz tanıdık ACS Yönetim portalına bir yol içerir.

ACS Yönetim portalına gitmek için:

1. Microsoft Azure Yönetim Portalına ()https://manage.WindowsAzure.com gidin, oturum açın ve Active Directory'ye tıklayın. (Sorun giderme ipucu: "Active Directory" öğesi eksik veya kullanılamıyor)

2. bir Access Control ad alanına tıklayın ve ardından Yönet'e tıklayın.

Access Control ad alanı oluşturmak için Yeni'ye tıklayın, Uygulama Hizmetleri'ne tıklayın, Access Control'a tıklayın ve ardından Hızlı Oluştur'a tıklayın. (Veya Yeni'ye tıklamadan önce ad alanları Access Control tıklayın.)

Microsoft Azure Yönetim Portalı'nda ACS yönetim görevleriyle ilgili yardım için Active Directory'ye ve ardından Yardım (?) öğesine tıklayın. (Veya Active Directory'ye tıklayın, Ad Alanları'Access Control ve ardından Yardım'a tıklayın.)

Service Bus için Access Control ad alanına gezinme

içinde bir Service Bus ad alanı oluşturduğunuzda portal, service bus için otomatik olarak bir Access Control ad alanı oluşturur.

Bir hizmet veri yolu için Access Control ad alanını yapılandırmak ve yönetmek için:

1. Azure Yönetim Portalı'nda oturum açın.

2. Service Bus'e tıklayın ve bir hizmet veri yolu seçin.

3. Erişim Anahtarı'nın ardından ACS Yönetim Portalını Aç'a tıklayın.

Access Control ad alanının hizmet veri yolu ile ilişkili olduğunu doğrulamak için Access Control Hizmeti sayfasının üst kısmındaki Hizmet Ad Alanı alanına bakın. Ad alanı adı, "-sb" soneki ile service bus adından oluşur.

Daha fazla bilgi için bkz. Nasıl yapılır: Service Bus için Access Control Ad Alanını Yönetme.

WS-Federation kimlik sağlayıcısı anahtarlarını görüntülemeye, parolaları gizlemeye yönelik ACS yönetim portalı iyileştirmeleri

Bu sürüm, ACS 2.0 yönetim portalında sertifikaları, anahtarları ve parolaları görüntüleme ve bunlarla çalışmayla ilgili bir çift geliştirme içerir:

• İmzalama sertifikaları artık WS-Federation Kimlik Sağlayıcısını Düzenle bölümünde görünür durumdaydı – Daha önce, bu kimlik sağlayıcısından verilen belirteçlerin imzasını doğrulamak için kullanılan WS-Federation meta verilerinden içeri aktarılan sertifikalar ACS Yönetim portalında görünmüyordu. WS-Federation Kimlik Sağlayıcısını Düzenle bölümünde artık içeri aktarılan sertifikalarla ilgili son kullanma tarihleri ve durumları da dahil olmak üzere bilgiler görüntülenir. Bu sertifikalar artık yeni bir "Kaydetme sırasında WS-Federation meta veri URL'sinden verileri yeniden içeri aktar" onay kutusu kullanılarak yenilenebilir.

• Parolalar ve simetrik imzalama anahtarları artık varsayılan olarak gizlidir – Parolaların ve simetrik anahtarların yanlışlıkla açıklanmasını önlemek için, bu değerler artık portal genelindeki Düzenle ekranlarında varsayılan olarak gizlenir. Parolanın veya simetrik anahtarın değerini bilerek görüntülemek için (örneğin, bir uygulamaya kopyalanabilir), "Parolayı Göster" veya "Anahtarı Göster" düğmesine basılmalıdır.

Dizin Kiracılarını Access Control ad alanlarıyla federasyon özelliği

Azure Active Directory kiracıları artık Access Control ad alanında kimlik sağlayıcısı olarak kullanılabilir. Bu, web uygulamanızın hem dizin kiracılarından kurumsal kimlikleri hem de Facebook, Google, Yahoo!, Microsoft hesapları veya başka bir OpenID sağlayıcısı gibi sosyal sağlayıcılardan gelen tüketici kimliklerini kabul etmesini sağlama gibi birçok senaryoya olanak tanır. Senaryonun nasıl uygulanabileceğine ilişkin ayrıntılı yönergeleri bu gönderide bulabilirsiniz: ACS Ad Alanında Kimlik Sağlayıcısı olarak Azure Active Directory Kiracı Sağlama.

Bağlı Taraf Uygulamaları için SAML 2.0 Protokol Desteği (Geliştirici Önizlemesi)

ACS artık bağlı olan taraf uygulamalarına belirteçler vermek için SAML 2.0 protokolunu destekliyor. SAML 2.0 protokol desteği geliştirici önizlemesi olarak kullanıma sunulmuştur, yani SAML 2.0 protokol uygulamasının ayrıntıları hala değiştirilebilir. Diğer ayrıntılar için bkz. Geliştirici Önizlemesi: SAMLProtocol.

Bilinen Sorunlar

Aralık 2012 Microsoft Azure Active Directory Access Control (Access Control Hizmeti veya ACS olarak da bilinir) güncelleştirmesinde, aşağıdaki bilinen sorunlar belirlenmiştir:

Azure Co-Administrators artık Access Control ad alanlarını yönetebilir. Ancak, önceden var olan ortak yöneticileri önceden var olan bir Access Control ad alanlarına yaymak için bir eylem gereklidir.

Kasım 2012 güncelleştirmesinin öncesinde, varsayılan olarak abonelikte oluşturulan Access Control ad alanlarını yalnızca birincil Azure hizmet yöneticisinin yönetebildiği bir sorunu çözdük. Azure ortak yöneticisi bir Access Control ad alanı için ACS Yönetim Portalı'na erişmeye çalışsa aşağıdaki ACS hata kodlarından birini alır:

• ACS50000: Belirteç verme hatası oluştu.

• ACS60000: 'uri:WindowsLiveID' veren kullanılarak bağlı olan taraf için kurallar işlenirken bir hata oluştu

• ACS60001: Kural işleme sırasında hiçbir çıkış talebi oluşturulmadı.

Bu sorun artık herhangi bir Azure hizmet yöneticisi veya ortak yönetici tarafından oluşturulan yeni Access Control ad alanları için çözülür. Ancak, düzeltmeden önce var olan ad alanlarına sahip müşterilerin, ortak yönetici verilerinin bu ad alanlarına yayılması için aşağıdaki geçici çözümü gerçekleştirmesi gerekir:

1. Hizmet yöneticisi veya hesap yöneticisi kimlik bilgilerini kullanarak Azure portal (https://windows.azure.com/) oturum açın.

2. Azure Abonelikleriniz için Co-Administrators Ekleme ve Kaldırma (https://msdn.microsoft.com/library/windowsazure/gg456328.aspx) bölümündeki yönergeleri kullanarak ortak yöneticiyi kaldırın ve yeniden ekleyin

3. Ortak yönetici kimlik bilgilerini kullanarak oturumu kapatın ve Azure portal oturum açın. Daha sonra Access Control ad alanlarını yönetebileceksiniz.

Eylül 2012 Güncelleştirme Sürüm Notları

Eylül 2012'de Microsoft Azure Active Directory Access Control (Access Control Hizmeti veya ACS olarak da bilinir) aşağıdaki değişiklikleri içeren bir güncelleştirme aldı:

ACS tarafından yayınlanan WS-Federation meta verilerinde yayımlanan entityID artık tutarlı olarak küçük harfe ayrılmıştır

Access Control ad alanları tarafından yayımlanan WS-Federation meta verilerindeki "entityID" özniteliği artık her zaman küçük harftir. Önceki sürümlerde, Azure portal ad alanı oluşturulduğunda girilen harf büyük/küçük harfini kullanıyordu. "entityID" özniteliği, bağlı olan taraf uygulamalara Access Control ad alanını tanımlar ve aşağıdaki özniteliğin bir örneğidir:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

Bu değişiklik, ACS tarafından verilen belirteçteki Access Control ad alanının (her zaman küçük harftir) bağlı olan taraf tarafından içeri aktarılan Access Control ad alanının harf örneğiyle eşleşmediği olası belirteç doğrulama sorunlarını gidermek için gerekliydi. Windows Identity Foundation kullanan bağlı olan taraflar büyük/küçük harf duyarlılığı sorunlarından etkilenmez.

ACS'ye yüklenen X.509 Sertifikaları artık 4096 bit ortak anahtar boyutu kısıtlamasına sahip

ACS yönetim portalı veya yönetim hizmeti aracılığıyla bir Access Control ad alanına yüklenen tüm X.509 sertifikalarının artık 4096 bitten büyük olmayan bir ortak anahtar boyutuna sahip olması gerekir. Buna belirteç imzalama, belirteç şifreleme ve belirteç şifre çözme için kullanılan sertifikalar dahildir.

Windows bir sertifikanın ortak anahtar boyutu, sertifika açılarak denetlenebilir (. CER) dosyasını seçin, "Ayrıntılar" sekmesini seçin ve "Ortak anahtar" alanının değerini denetleyin. Güvenli sha256RSA imza algoritmasını kullanan sertifikaların 2048 bit ortak anahtarı olacaktır.

Anahtar boyutu 4096 bitten büyük olan tüm mevcut sertifikalar ACS ile çalışmaya devam eder, ancak uyumlu bir sertifikayla değiştirilene kadar bu sertifikalar ACS'de yeniden kaydedilemez.

ACS X.509 sertifikası kullanarak belirteç imzaladığında kullanılan "birincil anahtar" seçim algoritmasında küçük bir değişiklik

ACS yönetim portalında ve yönetim hizmetinde, seçildiğinde ACS'nin bu sertifikayı kullanarak belirteçleri imzalamasına neden olan belirteç imzalama sertifikaları için bir "Birincil Yap" alanı vardır. Bu sürümde yapılandırılmış belirteç imzalama sertifikalarında "Birincil Yap" alanı işaretli değilse, Access Control ad alanı belirteci imzalamak için en erken geçerli başlangıç tarihine sahip olan birincil olmayan belirteç imzalama sertifikasını kullanır. AcS, birincil sertifika varsa, ancak geçersizse veya süresi dolmuşsa, birincil olmayan belirteç imzalama sertifikasıyla belirteçleri imzalamaz.

JWT Beta: Bir JWT belirtecini imzalamak için genel ad alanı sertifikası veya anahtarı kullanılırken imzalama davranışında değişiklik yapma

JSON Web Belirteci (JWT) biçimi için beta desteği Haziran 2012'de yayımlandığında ACS, bağlı olan her bir taraf uygulamasına verilen her JWT belirtecini imzalamak için hangi anahtarın kullanılması gerektiğini belirlemek için aşağıdaki öncelik sırasını kullandı:

• Varsa bağlı olan tarafa atanan simetrik imzalama anahtarı

• Varsa, bağlı olan tarafa atanan X.509 imzalama sertifikası

• Access Control ad alanına atanan simetrik imzalama anahtarı

• Access Control ad alanına atanan X.509 imzalama sertifikası

Bu sürümden itibaren ad alanı genelindeki simetrik anahtarlar artık JWT belirteçlerinin imzalanması için desteklenmemektedir. JWT belirteçlerini imzalamaya yönelik yeni öncelik sırası aşağıdadır:

• Varsa bağlı olan tarafa atanan simetrik imzalama anahtarı

• Varsa, bağlı olan tarafa atanan X.509 imzalama sertifikası

• Access Control ad alanına atanan X.509 imzalama sertifikası

Haziran 2012 Güncelleştirme Sürüm Notları

Haziran 2012'de ACS, aşağıdaki yeni özelliği içeren bir güncelleştirme aldı:

JWT biçimi artık bağlı olan taraf uygulamaları için kullanılabilir (Beta)

Bu güncelleştirme, ACS'de JSON Web Belirteci (JWT) BETA biçimi için destek sağlar. JWT, X.509 sertifikası veya simetrik anahtar kullanılarak imzalanabilen ve ACS tarafından aşağıdaki protokollerden herhangi biri üzerinden bağlı olan taraf uygulamalara düzenlenebilen hafif, JSON kodlu bir belirteç biçimidir:

• OAuth 2.0

• WS-Federation

• WS-Trust

JWT belirteci biçimi artık ACS Yönetim Portalı'nın Bağlı Taraf Uygulamaları bölümünde seçilebilir bir seçenektir ve ACS Yönetim Hizmeti aracılığıyla da yapılandırılabilir.

JWT belirteci biçimi hakkında daha fazla bilgi edinmek için bkz. JSON Web Belirteci belirtimi. JWT belirteçlerini içeren ACS kod örnekleri gelecek bir tarihte kullanıma sunulacaktır.

Önemli

JWT desteği ACS'de "Beta" olarak işaretlenir, yani JWT uygulamasının tüm ayrıntıları değiştirilebilir. Geliştiricilerin bu belirteç biçimiyle denemeleri teşvik edilir. Ancak davranış bildirimde bulunmaksızın değişebileceğinden JWT üretim hizmetlerinde kullanılmamalıdır.

Mayıs 2012 Güncelleştirme Sürüm Notları

Mayıs 2012'nin başlarında ACS aşağıdaki değişikliği içeren bir güncelleştirme aldı:

Yönetim hizmeti aracılığıyla sunulan varlık kimliği özelliklerinde yapılan değişiklikler

ACS Yönetim Hizmeti şu anda ACS Yönetim Hizmeti API Başvurusu'nda açıklandığı gibi desteklediği varlık türlerinin her biri için bir KIMLIK özelliği kullanıma sunar. Bu kimlik özellikleri ACS tarafından otomatik olarak ayarlanır ve yönetilir.

Bu hizmet güncelleştirmesinde ACS farklı bir veritabanı şemasına geçiriliyor ve bunun sonucunda yönetim hizmeti aracılığıyla kullanıma sunulan bu kimlikler tüm varlık türleri için değişecektir.

Uygulamaların yönetim hizmeti aracılığıyla belirli varlıkları sorgulamak için bu kimlikleri depolaması veya sabit kodlanmış bir bağımlılık alması yaygın değildir ve genellikle önerilmez. Bunun yerine, RelyingParty, ServiceIdentity, RuleGroup ve Issuer varlık türlerinin Name özelliği kullanılarak sorgulanması ve diğer varlık türlerinin üst varlık kimliği (ör. kurallar söz konusu olduğunda RuleGroupId veya kimlik sağlayıcıları söz konusu olduğunda IssuerId) kullanılarak sorgulanması önerilir.

Kural işleme için veritabanı harmanlama değişiklikleri

AcS'nin bu sürümü, uluslararası diller için desteği genişletmek ve güvenliği artırmak için SQL_Latin1_General_CP1_CI_AS gelen giriş taleplerini Latin1_General_100_BIN2 karşılaştırmak için kullanılan temel SQL veritabanı harmanlamasını güncelleştirir. Bu değişiklik, ACS'nin ek karakter kümelerini ve karakter kümelerinin birleşimlerini desteklemesini sağlar. SQL_Latin1_General_CP1_CI_AS tarafından desteklenmeyen, birden çok karakter kümesine sahip dizeler içeren giriş taleplerine dayanan uygulamalar, bu yeni harmanlamanın sonucunda farklı veya ek talepler görebilir. Bu yeni özellikten yararlanmak isteyen müşterilerin, uygulamalarını yeni SQL harmanlama ile uyumluluk açısından doğrulamaları önerilir.

Ocak 2012 Güncelleştirme Sürüm Notları

25 Ocak 2012'de ACS 2.0 aşağıdaki değişiklikleri içeren bir güncelleştirme aldı:

• Başarısız kimlik doğrulama istekleri için ACS hata yanıtlarında değişiklik

• Başarısız kimlik doğrulama istekleri için OAuth 2.0 hata kodlarında değişiklik

Başarısız kimlik doğrulama istekleri için ACS hata yanıtlarında değişiklik

Önceki sürümde, bir istemci var olmayan bir verenle (hata kodu: ACS50026) veya yanlış kimlik bilgileriyle (hata kodu: ACS50006) kimlik doğrulaması yapıldığında ACS farklı hata kodlarıyla yanıt verdi. Bu hata kodları daha önce bir istemci geçersiz bir hizmet kimliği adı veya geçersiz bir kimlik sağlayıcısından verilen BIR SWT veya SAML belirteci kullanarak kimlik doğrulaması yapmaya çalıştığında belirtiliyordu.

ACS sırasıyla SWT, SAML ve kullanıcı adı/parola gibi durumlarda başarısız kimlik doğrulaması için ACS50008, ACS50009 veya ACS50012 hata kodları döndürür. Ayrıntılar için aşağıdaki tabloya bakın:

Kimlik Doğrulama Yanıtı	Önce	Sonra
Var olmayan Veren	ACS50026 IssuerNotFound	ACS50008 InvalidSwt, ACS50009 InvalidSaml, OR ACS50012 AuthenticationFailed
Yanlış Kimlik Bilgileri	ACS50006 InvalidSignature

Başarısız kimlik doğrulama istekleri için OAuth 2.0 hata kodlarında değişiklik

Ayrıca önceki sürümde, bir istemci varolmayan bir verenle (invalid_client) veya yanlış kimlik bilgileriyle (invalid_grant) kimlik doğrulaması yapıldığında ACS farklı OAuth 2.0 hata kodlarıyla yanıt verdi. Bu davranış da güncelleştirilmiştir ve OAuth 2.0 isteği yanlış biçimlendirilmişse ACS invalid_request döndürür, invalid_client istemci kimlik doğrulaması başarısız olursa veya kimlik doğrulaması için sağlanan onay yanlış biçimlendirilmiş veya geçersizse ve yetkilendirme kodunun yanlış biçimlendirilmiş veya geçersiz olup olmadığını invalid_grant. Ayrıntılar için aşağıdaki tabloya bakın:

Kimlik Doğrulama Yanıtı	Örnekler	Önce	Sonra
Var olmayan Veren		invalid_client	invalid_client
Yanlış Kimlik Bilgileri	SWT yanlış bir anahtarla imzalandı. İstemci kimliği ve kimlik bilgileri ACS'de yapılandırılan kimlik bilgileriyle eşleşmektedir.	invalid_grant
Kimlik Doğrulaması Başarısız Oldu	İzleyici URI'sini doğrulama başarısız oldu. Sertifika doğrulaması başarısız oldu. Bir Hizmet Kimliğinden onay, kendi kendine verilen talepleri içerir.	invalid_grant
Hatalı Biçimlendirilmiş Onaylama	SWT'de imza eksik. SAML onaylaması geçerli XML değil.	invalid_request
Yetkilendirme Kodu Hatalı Biçimlendirilmiş		invalid_grant	invalid_grant
Yetkilendirme Kodu Geçersiz		invalid_grant
Hatalı Biçimlendirilmiş OAuth2 İsteği		invalid_request	invalid_request

Temmuz 2011 Güncelleştirme Sürüm Notları

ACS 2.0'ın Temmuz 2011 güncelleştirmesinin sürüm notları aşağıdaki öğeleri içerir:

• Önkoşullar

• Yeni Özellikler

• Değişiklikler

• Bilinen Sorunlar

• Bilinen Sorunlar

Önkoşullar

Tüm Access Control ad alanları Temmuz 2011 güncelleştirmesini otomatik olarak alır. Bu güncelleştirme, yeni veya mevcut müşteriler için ACS önkoşullarında değişiklik içermez. Geçerli ACS önkoşulları hakkında daha fazla bilgi için bkz. ACS Önkoşulları.

Yeni Özellikler

ACS'nin Temmuz 2011 güncelleştirmesi aşağıdaki yeni özellikleri içerir:

1. Kurallar artık en fazla iki giriş beyanlarını destekliyor

ACS kural altyapısı artık yalnızca bir giriş talebi yerine en fazla iki giriş talebi yapılandırılmasına izin veren yeni bir kural türünü destekliyor. İki giriş talebi olan kurallar, karmaşık kullanıcı yetkilendirme işlevlerini gerçekleştirmek için gereken kuralların toplam sayısını azaltmak için kullanılabilir.

ACS Yönetim Portalı'nda, kural düzenleyicisinde İkinci bir giriş talebi ekle'ye tıklayarak yeni bir kuralda ikinci bir giriş talebi belirtilebilir. Yönetim hizmetinde, iki giriş talebi olan kurallar , ConditionalRule varlık türü kullanılarak yapılandırılabilir. Bir giriş talebi olan kurallar, geriye dönük uyumluluk için Kural varlık türü kullanılarak yapılandırılmaya devam eder.

İki giriş talebi olan kurallar hakkında daha fazla bilgi için bkz. Kural Grupları ve Kurallar.

2. On bir dilde yerelleştirme

Bağlı olan taraf uygulamaları için ACS Yönetim Portalı ve ACS tarafından barındırılan oturum açma sayfası artık İngilizce, Fransızca, Almanca, İtalyanca, Japonca, Korece, Rusça, İspanyolca, Portekizce (Brezilya), Basitleştirilmiş Çince ve Geleneksel Çince dahil olmak üzere on bir yazılı dilde yerelleştirmeyi destekliyor. Anahtarlar için geçerlilik/son kullanma tarihlerini ayarlamak ve görüntülemek için alternatif bir tarih biçimi kullanan bir "İngilizce (Uluslararası)" seçeneği de mevcuttur. Bu kullanıcı arabirimleri için görüntülenen yazılı dil aşağıdaki üç yoldan biriyle değiştirilebilir:

• Dil Seçici – ACS Yönetim Portalı'nda görüntülenen dil, portalın sağ üst köşesinde görünen yeni bir dil seçici menüsü kullanılarak anında değiştirilebilir.

• URL – ACS Yönetim Portalı'nda görüntülenen dil, istek URL'sinin sonuna bir "lang" parametresi eklenerek değiştirilebilir. Bu parametrenin yasal değerleri, desteklenen bir dile karşılık gelen ISO 639-1/3166 dil kodlarıdır. En, de, es, fr, it, ja, ko, ru, pt-br, zh-cn ve zh-tw değerleri örnek olarak verilebilir. Aşağıda, görüntülenen dili Fransızca olarak ayarlı bir parametreye sahip örnek bir ACS Yönetim Portalı URL'si verilmiştir:

  https://your-namespace.accesscontrol.windows.net/?lang=fr

• Web Tarayıcısı Tercihleri – Dil tercihini ayarlamak için "lang" URL parametresi veya dil seçicisi hiç kullanılmadıysa, ACS Yönetim Portalı ve ACS tarafından barındırılan oturum açma sayfaları, web tarayıcısı ayarlarında ayarlanan dil tercihlerine göre görüntülenecek varsayılan dili belirler.

Değişiklikler

Bu sürümdeki önemli hizmet davranışı değişiklikleri şunlardır:

1. Kodlama artık tüm OAuth 2.0 yanıtları için UTF-8'dir

ACS'nin ilk sürümünde, OAuth 2.0 uç noktasından gelen tüm HTTP yanıtları için ayarlanan karakter kodlaması US-ASCII idi. Temmuz 2011 güncelleştirmesinde, genişletilmiş karakter kümelerini desteklemek için tüm HTTP yanıtlarının karakter kodlaması UTF-8 olarak ayarlanmıştır.

Bilinen Sorunlar

Bu sürümde bilinen bir sorun aşağıda verilmiştir:

Kural düzenleyicisi, kimlik sağlayıcılarıyla ilişkilendirilmemiş özel verenleri görüntüleyemez

Şu anda ACS Yönetim Portalı'ndaki kural düzenleyicisi yalnızca bir kimlik sağlayıcısı veya ACS ile ilişkili talep verenleri görüntüleyebilir. Bu öğelerden herhangi biriyle ilgili olmayan bir verene başvuran bir kural yüklenirse aşağıdaki hata görüntülenir:

• ACS80001: Bu kural, yönetim portalı tarafından desteklenmeyen bir Talep Veren türü kullanacak şekilde yapılandırılır. Bu kuralı görüntülemek ve düzenlemek için lütfen yönetim hizmetini kullanın.

AcS'de bir verenin ilişkili kimlik sağlayıcısı olmadan var olabileceği iki desteklenen senaryo vardır:

• OAuth 2.0 temsil senaryosunda, ACS Yönetim Hizmeti kullanılarak Access Control ad alanında bir veren kaydı oluşturulur ve bu verenin ilişkili bir kimlik sağlayıcısı yoktur.

• OAuth WRAP protokolü üzerinden bir belirteç isteğinde talepleri onaylama amacıyla bir veren oluşturulduğunda, ACS ile kimlik doğrulaması için aynı adlı hizmet kimliği kullanılır.

Kotalar

Bu sürümden itibaren ACS, belirli bir Access Control ad alanı için oluşturulabilecek kimlik sağlayıcıları, bağlı olan taraf uygulamaları, kural grupları, kurallar, hizmet kimlikleri, talep türleri, temsilci kayıtları, verenler, anahtarlar ve adres sayısına sınırlama getirmez.

Hizmet Sınırlamaları

Hizmet sınırlamaları hakkında daha fazla bilgi için bkz. ACS Hizmet Sınırlamaları.