이 설명서는 보관되지만 유지 되지 않습니다.

릴리스 정보

게시: 2011년 4월

업데이트 날짜: 2015년 6월

적용 대상: Azure

이 항목에서는 각 Microsoft Azure Active Directory 액세스 제어(액세스 제어 서비스 또는 ACS라고도 함) 릴리스의 새로운 기능 및 각 제품 릴리스와 이전 릴리스의 차이점에 대해 설명하고 이전 릴리스용으로 작성된 코드에 영향을 줄 수 있는 새로운 변경 내용을 강조합니다.

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

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 오류 페이지로 리디렉션됩니다.

새 ACS 네임스페이스 및 Google 오류

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

새로운 기능

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.0wreply 메시지를 인식하고 그에 대한 응답으로 ID 공급자에게 wsignout1.0 메시지를 보내고 신뢰 당사자 응용 프로그램에 wsignoutcleanup1.0 메시지를 보냅니다.

자세한 내용은 코드 샘플: 페더레이션 로그아웃이 포함된 ASP.NET MVC 4WIF의 ASP.NET에 대한 수동 인증(영문)을 참조하세요.

ACS 1.0 지원 중단

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

새로운 Azure 관리 포털에서 액세스 제어 네임스페이스로 이동

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

ACS 관리 포털로 이동하려면

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

  2. 액세스 제어 네임스페이스를 클릭한 후 관리를 클릭합니다.

액세스 제어 네임스페이스를 만들려면 새로 만들기, 앱 서비스, Access Control, 빠른 생성을 차례로 클릭합니다. 또는 새로 만들기를 클릭하기 전에 액세스 제어 네임스페이스를 클릭합니다.

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

서비스 버스에 대한 액세스 제어 네임스페이스로 이동

에서 서비스 버스 네임스페이스를 만드는 경우 포털이 서비스 버스에 대한 액세스 제어 네임스페이스를 자동으로 만듭니다.

서비스 버스에 대한 액세스 제어 네임스페이스를 구성 및 관리하려면

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

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

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

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

자세한 내용은 방법: Service Bus의 액세스 제어 네임스페이스 관리를 참조하세요.

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

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

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

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

디렉터리 테넌트 및 액세스 제어 네임스페이스 페더레이션 기능

이제 액세스 제어 네임스페이스에서 Azure Active Directory 테넌트를 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 액세스 제어(액세스 제어 서비스 또는 ACS라고도 함) 업데이트에서 다음과 같은 알려진 문제가 식별되었습니다.

이제 Azure 공동 관리자가 액세스 제어 네임스페이스를 관리할 수 있습니다. 그러나 기존 공동 관리자를 기존 액세스 제어 네임스페이스에 전파하기 위한 작업이 필요합니다.

2012년 11월 업데이트 이전에 기본적으로 Azure 주 서비스 관리자만 구독에 생성된 액세스 제어 네임스페이스를 관리할 수 있었던 문제를 해결했습니다. Azure 공동 관리자가 액세스 제어 네임스페이스에 대한 ACS 관리 포털에 액세스하려고 하면 다음 ACS 오류 코드 중 하나가 표시되었습니다.

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

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

  • ACS60001: 규칙을 처리하는 동안 출력 클레임이 생성되지 않았습니다.

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

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

  2. Azure 구독에 대해 공동 관리자를 추가 및 제거하는 방법(http://msdn.microsoft.com/en-us/library/windowsazure/gg456328.aspx)의 지침에 따라 공동 관리자를 제거하고 다시 추가합니다.

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

2012년 9월에 Microsoft Azure Active Directory 액세스 제어(액세스 제어 서비스 또는 ACS라고도 함)는 다음 변경 내용이 포함된 업데이트를 받았습니다.

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

이제 액세스 제어 네임스페이스가 게시한 WS-Federation 메타데이터의 "entityID" 특성이 항상 소문자로 표시됩니다. 이전 릴리스에서는 Azure 포털에서 네임스페이스를 만들 때 입력된 대/소문자를 사용했습니다. "entityID" 특성은 신뢰 당사자 응용 프로그램에 대한 액세스 제어 네임스페이스를 식별하며 특성의 예는 다음과 같습니다.

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

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

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

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

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

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

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

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

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

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

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

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

  • 액세스 제어 네임스페이스에 할당된 대칭 서명 키

  • 액세스 제어 네임스페이스에 할당된 X.509 서명 인증서

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

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

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

  • 액세스 제어 네임스페이스에 할당된 X.509 서명 인증서

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

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

이 업데이트는 ACS에 JWT(JSON Web Token) 베타 형식 지원을 도입합니다. JWT는 X.509 인증서 또는 대칭 키를 사용하여 서명할 수 있는 JSON 인코드된 경량 토큰 형식으로, 다음 프로토콜을 통해 ACS가 신뢰 당사자 응용 프로그램에 발급할 수 있습니다.

  • OAuth 2.0

  • WS-Federation

  • WS-Trust

이제 ACS 관리 포털의 신뢰 당사자 응용 프로그램 섹션에서 JWT 토큰 형식이 선택 가능한 옵션으로 제공되며 ACS 관리 서비스를 통해 구성할 수도 있습니다.

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

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

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월 25일에 ACS 2.0은 다음 변경 내용이 포함된 업데이트를 받았습니다.

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

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

 

인증 응답 이전 이러한

존재하지 않는 발급자

ACS50026 IssuerNotFound

ACS50008 InvalidSwt,

ACS50009 InvalidSaml 또는

ACS50012 AuthenticationFailed

잘못된 자격 증명

ACS50006 InvalidSignature

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

 

인증 응답 이전 이러한

존재하지 않는 발급자

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

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

모든 액세스 제어 네임스페이스는 자동으로 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 관리 서비스를 사용하여 액세스 제어 네임스페이스에 발급자 레코드가 생성되며 이 발급자에는 연결된 ID 공급자가 없습니다.

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

이 릴리스를 기준으로 ACS는 지정된 액세스 제어 네임스페이스에 대해 만들 수 있는 ID 공급자, 신뢰 당사자 응용 프로그램, 규칙 그룹, 규칙, 서비스 ID, 클레임 유형, 위임 레코드, 발급자, 키 및 주소 수를 제한하지 않습니다.

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

표시: