다음을 통해 공유

릴리스 정보

  • 아티클

업데이트: 2015년 6월 19일

Azure에 적용합니다.

이 항목에서는 각 Microsoft Azure Active Directory Access Control 릴리스(Access Control Service 또는 ACS라고도 함)의 새로운 기능에 대해 설명하고, 제품의 각 릴리스가 이전 릴리스와 어떻게 다른지 설명하고, 이전 릴리스에 대해 작성된 코드에 영향을 줄 수 있는 주요 변경 내용을 강조 표시합니다.

  • 2015년 3월 – ACS 네임 스페이스를 Google OpenID Connect로 마이그레이션

  • 2014년 6월 – Google ID 공급자 지원

  • 2013년 7월 업데이트 릴리스 정보

  • 2012년 12월 업데이트 릴리스 정보

  • 2012년 9월 업데이트 릴리스 정보

  • 2012년 6월 업데이트 릴리스 정보

  • 2012년 5월 업데이트 릴리스 정보

  • 2012년 1월 업데이트 릴리스 정보

  • 2011년 7월 업데이트 릴리스 정보

2015년 3월 – ACS 네임 스페이스를 Google OpenID Connect로 마이그레이션

ACS는 ACS 네임 스페이스 소유자가 Google ID 제공자 구성을 OpenID 2.0에서 OpenID Connect로 마이그레이션하는 데 도움이 되는 기능을 구현했습니다. 고객은 2015년 6월 1일까지 ACS 네임 스페이스를 OpenID Connect로 마이그레이션하고 2017년 1월 1일까지 OpenID Connect 식별자를 사용하도록 백엔드 코드를 마이그레이션합니다. 각 최종 기한 전에 적절한 작업을 수행하지 못하면 응용 프로그램이 중단됩니다. 자세한 지침은 ACS 네임스페이스를 Google OpenID 커넥트 마이그레이션을 참조하세요.

2014년 6월 – Google ID 공급자 지원

2014년 5월 19일 현재 새 ACS 네임스페이스에서 Google을 ID 공급자로 사용할 수 없습니다. 2014년 5월 19일 이전에 Google을 사용하여 등록된 ACS 네임스페이스는 영향을 받지 않습니다. 이 새로운 제한은 Google이 ACS에서 사용하는 OpenID 2.0에 대한 지원을 단계별로 중단하고 있으며 새 응용 프로그램 등록을 마감했기 때문에 발생합니다. Google을 사용한 기존 ACS 네임스페이스는 2015년 4월 20일까지 계속 작동합니다. 애플리케이션에 Google 계정에 대한 지원이 필요한 경우 애플리케이션을 직접 등록하는 것이 좋습니다.

사용자가 Google 계정을 사용하여 새 ACS 네임스페이스에 로그인하려고 하면 HTTP 400 오류 페이지로 리디렉션됩니다.

New ACS namespace and Google error

2013년 7월 업데이트 릴리스 정보

모든 사용자에 대해 ACS의 가용성과 성능을 향상하기 위해 ACS에서는 각 네임스페이스에 대한 토큰 요청을 초당 30개로 제한했습니다. 네임스페이스가 오랫동안 이 제한을 초과할 경우 ACS는 간격 기간에 네임스페이스의 토큰 요청을 거부하고 HTTP 429/ACS90055 "요청이 너무 많음" 오류를 반환합니다. 자세한 내용은 ACS 서비스 제한 사항 및ACS 오류 코드를 참조하세요.

2012년 12월 업데이트 릴리스 정보

새 기능

ACS의 2012년 12월 업데이트에는 다음과 같은 새로운 기능이 포함되어 있습니다.

WS-Federation 프로토콜을 사용하여 페더레이션 Single Sign-Out 지원

ACS를 사용하여 WS-Federation 프로토콜을 사용하는 ID 공급자에서 SSO(Single Sign-On)를 사용하도록 설정하는 웹 애플리케이션은 이제 Single Sign-Out 기능을 활용할 수 있습니다. 사용자가 웹 애플리케이션에서 로그아웃하면 ACS는 ID 공급자와 동일한 ID 공급자를 사용하는 다른 신뢰 당사자 애플리케이션에서 사용자를 자동으로 로그아웃할 수 있습니다.

이 기능은 Active Directory Federation Services 2.0 및 Windows Live ID(Microsoft 계정)를 비롯한 WS-Federation ID 공급자에 사용할 수 있습니다. Single Sign out을 사용하도록 설정하기 위해 ACS는 WS-Federation 프로토콜 엔드포인트에 대해 다음 작업을 수행합니다.

  • ACS는 ID 공급자로부터 wsignoutcleanup1.0 메시지를 인식하고 신뢰 당사자 애플리케이션에 wsignoutcleanup1.0 메시지를 보내 응답합니다.

  • ACS는 신뢰 당사자 애플리케이션에서 wsignout1.0 및 wreply 메시지를 인식하고 wsignout1.0 메시지를 ID 공급자로 보내고 wsignoutcleanup1.0 메시지를 신뢰 당사자 애플리케이션에 전송하여 응답합니다.

자세한 내용은 코드 샘플을 참조하세요. ASP.NET MVC 4와 페더레이션 로그아웃, WIF의 ASP.NET 수동 인증을 참조하세요.

ACS 1.0 지원 중단

이 릴리스에서는 액세스 제어 서비스 1.0에서 액세스 제어 서비스 2.0으로의 마이그레이션 지원을 포함하여 액세스 제어 서비스 1.0 지원이 중단되었습니다.

새 Azure 관리 포털에서 Access Control 네임스페이스로 이동

새 Azure 관리 포털(https://manage.WindowsAzure.com)에는 Access Control 네임스페이스를 만들고 관리하는 친숙한 ACS 관리 포털에 대한 경로가 포함되어 있습니다.

ACS 관리 포털로 이동하려면

  1. Microsoft Azure 관리 포털(https://manage.WindowsAzure.com)로 이동하여 로그인한 다음 Active Directory를 클릭합니다. (문제 해결 팁: "Active Directory" 항목이 없거나 사용할 수 없음)

  2. Access Control 네임스페이스를 클릭한 다음 관리를 클릭합니다.

Access Control 네임스페이스를 만들려면 새로 만들기, App Services, Access Control, 빨리 만들기를 차례로 클릭합니다. 또는 새로 만들기를 클릭하기 전에 Access Control 네임스페이스를 클릭합니다.

Microsoft Azure 관리 포털의 ACS 관리 태스크에 대한 도움말을 얻으려면 Active Directory를 클릭한 다음 도움말(?)을 클릭하세요. 또는 Active Directory, Access Control 네임스페이스, 도움말을 차례로 클릭합니다.

Service Bus의 Access Control 네임스페이스로 이동

Service Bus 네임스페이스를 만들면 포털에서 Service Bus에 대한 Access Control 네임스페이스를 자동으로 만듭니다.

Service Bus에 대한 Access Control 네임스페이스를 구성하고 관리하려면 다음을 수행합니다.

  1. Azure 관리 포털에 로그인합니다.

  2. 서비스 버스를 클릭하고 서비스 버스를 선택합니다.

  3. 액세스 키를 클릭한 후 ACS 관리 포털 열기를 클릭합니다.

Access Control 네임스페이스가 Service Bus와 연결되어 있는지 확인하려면 Access Control 서비스 페이지의 맨 위에 있는 서비스 네임스페이스 필드를 참조하세요. 네임스페이스 이름은 서비스 버스 이름 및 "-sb" 접미사로 구성됩니다.

자세한 내용은 방법: Service Bus 대한 Access Control 네임스페이스 관리를 참조하세요.

암호를 숨기고 WS-Federation ID 공급자 키를 보기 위한 향상된 ACS 관리 포털 기능

이 릴리스에는 ACS 2.0 관리 포털에서 인증서, 키 및 암호를 보고 작업하기 위한 한 쌍의 향상된 기능이 포함되어 있습니다.

  • 이제 WS-Federation ID 공급자 편집 섹션에 서명 인증서가 표시됨 – 이전에는 WS-Federation 메타데이터에서 가져온 인증서가 ACS 관리 포털에 표시되지 않았습니다. 이 인증서는 해당 ID 공급자에서 발급된 토큰 서명의 유효성 검사에 사용되었습니다. 이제 WS-Federation ID 공급자 편집 섹션에 만료 날짜 및 상태를 포함하여 가져온 인증서에 대한 정보가 표시됩니다. 새로운 "저장 시 WS-Federation 메타데이터 URL에서 데이터 다시 가져오기" 확인란을 사용하여 이러한 인증서를 새로 고칠 수 있습니다.

  • 이제 암호 및 대칭 서명 키가 기본적으로 숨겨짐 – 암호 및 대칭 키가 의도하지 않게 공개되지 않도록 이제 포털 전체의 편집 화면에서 이러한 값이 기본적으로 숨겨집니다. 응용 프로그램에 복사할 수 있게 하려는 경우 등 암호 또는 대칭 키의 값을 의도적으로 표시하려면 이제 "암호 표시" 또는 "키 표시" 단추를 눌러야 합니다.

Access Control 네임스페이스를 사용하여 디렉터리 테넌트 페더레이션 기능

이제 Azure Active Directory 테넌트는 Access Control 네임스페이스에서 ID 공급자로 사용할 수 있습니다. 이렇게 하면 웹 애플리케이션이 디렉터리 테넌트에서 조직 ID와 Facebook, Google, Yahoo!, Microsoft 계정 또는 기타 OpenID 공급자와 같은 소셜 공급자의 소비자 ID를 모두 수락할 수 있도록 하는 등의 많은 시나리오가 가능합니다. 이 게시물에서 시나리오를 구현하는 방법에 대한 자세한 지침을 찾을 수 있습니다. ACS 네임스페이스에서 Azure Active Directory 테넌트를 ID 공급자로 프로비전합니다.

신뢰 당사자 응용 프로그램에 대한 SAML 2.0 프로토콜 지원(개발자 미리 보기)

이제 ACS가 신뢰 당사자 응용 프로그램에 토큰을 발급하기 위한 SAML 2.0 프로토콜을 지원합니다. SAML 2.0 프로토콜 지원은 개발자 미리 보기로 릴리스되었으므로 SAML 2.0 프로토콜 구현의 세부 정보가 변경될 수 있습니다. 자세한 내용은개발자 미리 보기: SAMLProtocol을 참조하세요.

알려진 문제

2012년 12월 Microsoft Azure Active Directory Access Control(Access Control 서비스 또는 ACS라고도 함) 업데이트에서 다음과 같은 알려진 문제가 확인되었습니다.

이제 Azure Co-Administrators Access Control 네임스페이스를 관리할 수 있습니다. 그러나 기존 공동 관리자를 기존 Access Control 네임스페이스로 전파하려면 작업이 필요합니다.

2012년 11월 업데이트 이전에는 기본적으로 기본 Azure 서비스 관리자만 구독에서 만든 Access Control 네임스페이스를 관리할 수 있는 문제를 해결했습니다. Azure 공동 관리자가 Access Control 네임스페이스에 대한 ACS 관리 포털에 액세스하려고 하면 다음 ACS 오류 코드 중 하나가 수신됩니다.

  • ACS50000: 토큰을 발급하는 동안 오류가 발생했습니다.

  • ACS60000: 발급자 'uri:WindowsLiveID'를 사용하여 신뢰 당사자에 대한 규칙을 처리하는 동안 오류가 발생했습니다.

  • ACS60001: 규칙 처리 중에 출력 클레임이 생성되지 않았습니다.

이제 Azure 서비스 관리자 또는 공동 관리자가 만든 새 Access Control 네임스페이스에 대해 이 문제가 해결되었습니다. 그러나 수정 전에 존재한 네임스페이스가 있는 고객은 공동 관리자 데이터가 해당 네임스페이스로 전파되도록 다음 해결 방법을 수행해야 합니다.

  1. 서비스 관리자 또는 계정 관리자 자격 증명을 사용하여 Azure Portal(https://windows.azure.com/)에 로그인합니다.

  2. Azure 구독에 대한 Co-Administrators 추가 및 제거하는 방법(https://msdn.microsoft.com/library/windowsazure/gg456328.aspx)의 지침을 사용하여 공동 관리자를 제거하고 다시 추가합니다.

  3. 로그아웃한 후 공동 관리자 자격 증명을 사용하여 Azure 포털에 로그인합니다. 그러면 Access Control 네임스페이스를 관리할 수 있습니다.

2012년 9월 업데이트 릴리스 정보

2012년 9월, Microsoft Azure Active Directory Access Control(Access Control 서비스 또는 ACS라고도 함)는 다음과 같은 변경 내용이 포함된 업데이트를 받았습니다.

이제 ACS가 내보낸 WS-Federation 메타데이터에 게시된 entityID가 일관성 있게 소문자로 표시됨

Access Control 네임스페이스에서 게시한 WS-Federation 메타데이터의 "entityID" 특성은 이제 항상 소문자입니다. 이전 릴리스에서는 Azure 포털에서 네임스페이스를 만들 때 입력된 대/소문자를 사용했습니다. "entityID" 특성은 신뢰 당사자 애플리케이션에 대한 Access Control 네임스페이스를 식별하며, 다음은 특성의 예입니다.

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

이 변경은 ACS 발급 토큰에 있는 Access Control 네임스페이스의 문자 대/소문자(항상 소문자)가 신뢰 당사자가 가져온 Access Control 네임스페이스의 문자 대/소문자와 일치하지 않는 잠재적 토큰 유효성 검사 문제를 해결하기 위해 필요했습니다. Windows Identity Foundation을 사용하는 신뢰 당사자는 대/소문자 문제의 영향을 받지 않습니다.

이제 ACS로 업로드된 X.509 인증서에 4096비트의 공개 키 크기 제한이 있습니다.

ACS 관리 포털 또는 관리 서비스를 통해 Access Control 네임스페이스에 업로드된 모든 X.509 인증서는 이제 4096비트 이하의 공개 키 크기를 포함해야 합니다. 여기에는 토큰 서명, 토큰 암호화 및 토큰 암호 해독에 사용되는 인증서가 포함됩니다.

Windows에서 인증서의 공개 키 크기를 확인하려면 인증서(.CER) 파일을 열고 "세부 정보" 탭을 선택한 다음 "공개 키" 필드의 값을 확인합니다. 보안 sha256RSA 서명 알고리즘을 사용하는 인증서에는 2048비트 공개 키가 포함됩니다.

키 크기가 4096비트를 초과하는 기존 인증서는 ACS에서 계속 작동하지만 규격 인증서로 바꿀 때까지 ACS에서 다시 저장할 수 없습니다.

ACS가 X.509 인증서를 사용하여 토큰에 서명할 때 사용되는 "기본 키" 선택 알고리즘의 사소한 변경

ACS 관리 포털 및 관리 서비스에는 토큰 서명 인증서에 대한 "기본으로 설정" 필드가 있으며, 이 필드를 선택하면 ACS가 해당 인증서를 사용하여 토큰에 서명합니다. 이 릴리스에서 구성된 토큰 서명 인증서에 "기본으로 설정" 필드가 선택되지 않은 경우 Access Control 네임스페이스는 가장 빠른 유효한 시작 날짜가 있는 기존의 기본이 아닌 토큰 서명 인증서를 사용하여 토큰에 서명합니다. 기본 인증서가 있지만 잘못되었거나 만료된 경우에는 ACS에서 비기본 토큰 서명 인증서로 토큰에 서명하지 않습니다.

JWT 베타: 전역 네임스페이스 인증서 또는 키를 사용하여 JWT 토큰에 서명할 때 서명 동작 변경

JWT(JSON Web Token) 형식에 대한 베타 지원이 2012년 6월에 릴리스되었을 때 ACS는 다음과 같은 우선 순위를 사용하여 각 신뢰 당사자 응용 프로그램에 발급된 각 JWT 토큰 서명에 사용할 키를 결정했습니다.

  • 신뢰 당사자에 할당된 대칭 서명 키(사용 가능한 경우)

  • 신뢰 당사자에 할당된 X.509 서명 인증서(사용 가능한 경우)

  • Access Control 네임스페이스에 할당된 대칭 서명 키

  • Access Control 네임스페이스에 할당된 X.509 서명 인증서

이 릴리스를 기준으로 네임스페이스 전체 대칭 키는 JWT 토큰 서명에 더 이상 지원되지 않습니다. JWT 토큰 서명의 새 우선 순위는 다음과 같습니다.

  • 신뢰 당사자에 할당된 대칭 서명 키(사용 가능한 경우)

  • 신뢰 당사자에 할당된 X.509 서명 인증서(사용 가능한 경우)

  • Access Control 네임스페이스에 할당된 X.509 서명 인증서

2012년 6월 업데이트 릴리스 정보

2012년 6월 ACS는 다음과 같은 새로운 기능이 포함된 업데이트를 받았습니다.

신뢰 당사자 응용 프로그램에 JWT 형식 사용 가능(베타)

이 업데이트에서는 ACS에서 JWT(JSON Web Token) BETA 형식에 대한 지원을 도입했습니다. JWT는 X.509 인증서 또는 대칭 키를 사용하여 서명할 수 있는 간단한 JSON 인코딩 토큰 형식이며 ACS에서 다음 프로토콜을 통해 신뢰 당사자 애플리케이션에 발급할 수 있습니다.

  • OAuth 2.0

  • WS-Federation

  • WS-Trust

JWT 토큰 형식은 이제 ACS 관리 포털의 신뢰 당사자 애플리케이션 섹션에서 선택할 수 있는 옵션이며 ACS 관리 서비스를 통해 구성할 수도 있습니다.

JWT 토큰 형식에 대한 자세한 내용은 JSON 웹 토큰 사양을 참조하세요. JWT 토큰을 처리하는 ACS 코드 샘플은 이후에 제공될 예정입니다.

중요

JWT 지원은 ACS에서 "베타"로 표시되므로 JWT 구현의 모든 세부 정보가 변경될 수 있습니다. 개발자는 이 토큰 형식을 시험해 보셔도 됩니다. 그러나 동작이 통지 없이 변경될 수 있으므로 프로덕션 서비스에서는 JWT를 사용하면 안 됩니다.

2012년 5월 업데이트 릴리스 정보

2012년 5월 초, ACS는 다음과 같은 변경 내용이 포함된 업데이트를 받았습니다.

관리 서비스를 통해 노출되는 엔터티 ID 속성 변경

ACS 관리 서비스는 현재 ACS 관리 서비스 API 참조에 설명된 대로 지원하는 각 엔터티 형식에 대한 ID 속성을 노출합니다. 이러한 ID 속성은 ACS에서 자동으로 설정 및 관리됩니다.

이 서비스 업데이트에서 ACS는 다른 데이터베이스 스키마로 마이그레이션되므로 관리 서비스를 통해 노출되는 이러한 ID는 모든 엔터티 형식에 대해 변경됩니다.

응용 프로그램이 관리 서비스를 통해 특정 엔터티를 쿼리하기 위해 이러한 ID를 저장하거나 하드 코드된 종속성을 수행하는 것은 드문 경우이며 일반적으로 권장되지 않습니다. 대신, Name 속성을 사용하여 RelyingParty, ServiceIdentity, RuleGroup 및 Issuer 엔터티 형식을 쿼리하고 부모 엔터티 ID(예: 규칙의 경우 RuleGroupId 또는 ID 공급자의 경우 IssuerId)를 사용하여 기타 엔터티 형식을 쿼리하는 것이 좋습니다.

규칙 처리를 위한 데이터베이스 데이터 정렬 변경

국제 언어에 대한 지원을 확장하고 보안을 개선하기 위해 이 ACS 릴리스는 SQL_Latin1_General_CP1_CI_AS 입력 클레임을 Latin1_General_100_BIN2 비교하는 데 사용되는 기본 SQL 데이터베이스 데이터 정렬을 업데이트합니다. 이 변경을 통해 ACS는 문자 집합의 추가 문자 집합과 조합을 지원할 수 있습니다. SQL_Latin1_General_CP1_CI_AS에서 지원하지 않는 여러 문자 집합이 있는 문자열을 포함하는 입력 클레임을 사용하는 응용 프로그램에서는 이 새로운 데이터 정렬의 결과로 다른 클레임이나 추가 클레임이 표시될 수 있습니다. 이 새로운 기능을 활용하려는 고객은 응용 프로그램이 새 SQL 데이터 정렬과 호환되는지 확인하는 것이 좋습니다.

2012년 1월 업데이트 릴리스 정보

2012년 1월 25일 ACS 2.0에서 다음과 같은 변경 내용이 포함된 업데이트를 받았습니다.

  • 실패한 인증 요청에 대한 ACS 오류 응답 변경

  • 실패한 인증 요청에 대한 OAuth 2.0 오류 코드 변경

실패한 인증 요청에 대한 ACS 오류 응답 변경

이전 릴리스에서 ACS는 클라이언트가 존재하지 않는 발급자(오류 코드: ACS50026) 또는 잘못된 자격 증명(오류 코드: ACS50006)으로 인증될 때 다른 오류 코드로 응답했습니다. 이러한 오류 코드는 이전에 클라이언트가 잘못된 서비스 ID 이름을 사용하거나 잘못된 ID 공급자에서 발급된 SWT 또는 SAML 토큰을 사용하여 인증을 시도할 때 발생했습니다.

ACS는 SWT, SAML 및 사용자 이름/암호의 경우 각각 실패한 인증에 대해 ACS50008, ACS50009 또는 ACS50012 오류 코드를 반환합니다. 자세한 내용은 아래 표를 참조하세요.

인증 응답 이전 After

존재하지 않는 발급자

ACS50026 IssuerNotFound

ACS50008 InvalidSwt,

ACS50009 InvalidSaml, OR

ACS50012 AuthenticationFailed

잘못된 자격 증명

ACS50006 InvalidSignature

실패한 인증 요청에 대한 OAuth 2.0 오류 코드 변경

또한 이전 릴리스에서 ACS는 클라이언트가 존재하지 않는 발급자(invalid_client) 또는 잘못된 자격 증명(invalid_grant)으로 인증했을 때 다른 OAuth 2.0 오류 코드로 응답했습니다. 이 동작도 업데이트되었으며, 클라이언트가 인증에 실패하거나 인증에 제공된 어설션이 잘못된 경우 invalid_client OAuth 2.0 요청이 잘못된 경우 ACS가 invalid_request 반환하고 권한 부여 코드의 형식이 잘못되었거나 잘못된 경우 invalid_grant. 자세한 내용은 아래 표를 참조하세요.

인증 응답 예 이전 After

존재하지 않는 발급자

invalid_client

invalid_client

잘못된 자격 증명

SWT가 잘못된 키로 서명되었습니다. 클라이언트 ID 및 자격 증명은 ACS에 구성된 것과 일치합니다.

invalid_grant

인증 실패

대상 그룹 URI 유효성 검사에 실패했습니다. 인증서 유효성 검사에 실패했습니다. 서비스 ID의 어설션에 자체 발급된 클레임이 포함되어 있습니다.

invalid_grant

어설션 형식이 잘못됨

SWT에 서명이 없습니다. SAML 어설션이 유효한 XML이 아닙니다.

invalid_request

권한 부여 코드 형식이 잘못됨

invalid_grant

invalid_grant

권한 부여 코드가 잘못됨

invalid_grant

OAuth2 요청 형식이 잘못됨

invalid_request

invalid_request

2011년 7월 업데이트 릴리스 정보

ACS 2.0의 2011년 7월 업데이트 릴리스 정보에는 다음 항목이 포함되어 있습니다.

  • 사전 요구 사항

  • 새로운 기능

  • 변경

  • 알려진 문제

  • 알려진 문제

사전 요구 사항

모든 Access Control 네임스페이스는 2011년 7월 업데이트를 자동으로 받습니다. 이 업데이트에는 신규 또는 기존 고객을 위한 ACS 필수 구성 요소가 변경되지 않습니다. 현재 ACS 필수 구성 요소에 대한 자세한 내용은 ACS 필수 구성 요소를 참조하세요.

새로운 기능

ACS에 대한 2011년 7월 업데이트에는 다음과 같은 새로운 기능이 포함되어 있습니다.

1. 이제 규칙이 최대 두 개의 입력 클레임 지원

이제 ACS 규칙 엔진은 하나의 입력 클레임 대신 최대 두 개의 입력 클레임을 구성할 수 있는 새로운 유형의 규칙을 지원합니다. 두 개의 입력 클레임이 있는 규칙을 사용하면 복잡한 사용자 권한 부여 기능을 수행하는 데 필요한 전체 규칙 수를 줄일 수 있습니다.

ACS 관리 포털에서 규칙 편집기에서 두 번째 입력 클레임 추가를 클릭하여 새 규칙에서 두 번째 입력 클레임을 지정할 수 있습니다. 관리 서비스에서는 ConditionalRule 엔터티 형식을 사용하여 두 개의 입력 클레임이 있는 규칙을 구성할 수 있습니다. 이전 버전과의 호환성을 위해 하나의 입력 클레임이 있는 규칙도 규칙 엔터티 형식을 사용하여 구성됩니다.

두 개의 입력 클레임이 있는 규칙에 대한 자세한 내용은 규칙 그룹 및 규칙을 참조하세요.

2. 11개 언어로 지역화

신뢰 당사자 애플리케이션에 대한 ACS 관리 포털 및 ACS 호스팅 로그인 페이지는 이제 영어, 프랑스어, 독일어, 이탈리아어, 일본어, 한국어, 러시아어, 스페인어, 포르투갈어(브라질), 중국어 간체 및 중국어 번체를 포함한 11개의 서면 언어로 지역화를 지원합니다. 키의 유효/만료 날짜 설정 및 표시를 위해 대체 날짜 형식을 사용하는 "영어(국제)" 옵션도 사용할 수 있습니다. 이러한 사용자 인터페이스에 대해 표시되는 문자 언어는 다음 세 가지 방법 중 하나로 변경할 수 있습니다.

  • 언어 선택기 – ACS 관리 포털에서 표시되는 언어는 포털의 오른쪽 위 모서리에 표시되는 새 언어 선택기 메뉴를 사용하여 즉시 변경할 수 있습니다.

  • URL – 요청 URL의 끝에 "lang" 매개 변수를 추가하여 ACS 관리 포털에 표시되는 언어를 변경할 수 있습니다. 이 매개 변수에 적합한 값은 지원되는 언어에 해당하는 ISO 639-1/3166 언어입니다. 이러한 값의 예로 en, de, es, fr, it, ja, ko, ru, pt-br, zh-cn, zh-tw 등이 있습니다. 다음은 표시된 언어를 프랑스어로 설정하는 매개 변수가 있는 ACS 관리 포털 URL 예제입니다.

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

  • 웹 브라우저 기본 설정 – 언어 기본 설정을 위해 "lang" URL 매개 변수 또는 언어 선택기를 사용한 적이 없는 경우 ACS 관리 포털 및 ACS 호스팅 로그인 페이지에서 웹 브라우저 설정에 설정된 언어 기본 설정에 따라 표시할 기본 언어를 결정합니다.

변경

이 릴리스에서 주목할 만한 서비스 동작 변경 내용은 다음과 같습니다.

1. 이제 모든 OAuth 2.0 응답에 대한 인코딩이 UTF-8로 설정됨

ACS의 초기 릴리스에서 OAuth 2.0 엔드포인트의 모든 HTTP 응답에 대한 문자 인코딩 집합은 US-ASCII였습니다. 2011년 7월 업데이트에서는 확장된 문자 집합을 지원하기 위해 모든 HTTP 응답의 문자 인코딩이 UTF-8로 설정되었습니다.

알려진 문제

이 릴리스의 알려진 문제는 다음과 같습니다.

규칙 편집기에서 ID 공급자와 연결되지 않은 사용자 지정 발급자를 표시할 수 없음

현재 ACS 관리 포털의 규칙 편집기에서는 ID 공급자 또는 ACS와 연결된 클레임 발급자만 표시할 수 있습니다. 여기에 해당하지 않는 발급자를 참조하는 규칙을 로드하면 다음 오류가 표시됩니다.

  • ACS80001: 이 규칙은 관리 포털에서 지원되지 않는 클레임 발급자 유형을 사용하도록 구성됩니다. 관리 서비스를 사용하여 이 규칙을 보고 편집하세요.

ACS에서 연결된 ID 공급자 없이 발급자가 존재할 수 있는 두 가지 지원되는 시나리오가 있습니다.

  • OAuth 2.0 위임 시나리오에서 발급자 레코드는 ACS 관리 서비스를 사용하여 Access Control 네임스페이스에 생성되며 이 발급자에는 연결된 ID 공급자가 없습니다.

  • 동일한 이름의 서비스 ID를 사용하여 ACS를 인증하는 동안 OAuth WRAP 프로토콜을 통해 토큰 요청에서 클레임을 어설션하기 위해 발급자가 만들어지는 경우.

할당량

이 릴리스를 기준으로 ACS는 지정된 Access Control 네임스페이스에 대해 만들 수 있는 ID 공급자, 신뢰 당사자 애플리케이션, 규칙 그룹, 규칙, 서비스 ID, 클레임 형식, 위임 레코드, 발급자, 키 및 주소 수에 제한을 두지 않습니다.

서비스 제한 사항

서비스 제한 사항에 대한 자세한 내용은 ACS 서비스 제한 사항을 참조하세요.