다음을 통해 공유


ACS 네임스페이스를 Google OpenID Connect로 마이그레이션

이 항목은 현재 Google을 ID 공급자로 사용하는 ACS(Access Control Service) 2.0 네임스페이스의 소유자를 위한 것입니다. ACS는 Google의 OpenID 2.0 구현을 사용하여 이 기능을 제공합니다. Google은 2015년 4월 20일까지 OpenID 2.0 지원을 중단할 계획입니다. ACS 네임스페이스는 2015년 6월 1일까지 Google의 OpenID 2.0 구현에서 계속 작동하며, 이때 Google의 OpenID Connect 구현을 사용하려면 이러한 네임스페이스의 마이그레이션을 완료해야 합니다. 그렇지 않으면 사용자는 더 이상 Google 계정으로 애플리케이션에 로그인할 수 없습니다. ACS 네임스페이스를 OpenID Connect로 마이그레이션해도 애플리케이션 가동 중지 시간이 발생하지 않습니다. 한 가지 예외를 제외하고(아래 참고 참조) 애플리케이션 코드를 변경하지 않고도 이 마이그레이션이 가능합니다. OpenID Connect를 사용하도록 ACS 네임스페이스를 마이그레이션한 후에는 백 엔드의 사용자 식별자를 OpenID Connect 식별자로 마이그레이션해야 합니다. 이 마이그레이션은 2017년 1월 1일까지 완료해야 합니다. 백 엔드에서 코드를 변경해야 합니다. 두 마이그레이션 단계에 대한 자세한 내용은 아래의 중요한 참고 사항을 참조하세요.

중요하다

다음 중요한 날짜를 확인하고 각 날짜에 필요한 작업을 완료하여 Google을 ID 공급자로 사용하는 ACS 네임스페이스가 계속 작동하도록 합니다.

  • 2015년 6월 1일 - ACS 네임스페이스는 Google의 OpenID 2.0 구현 작업을 중지합니다. 이 날짜까지 Google OpenID Connect를 사용하려면 ACS 네임스페이스 마이그레이션을 완료해야 합니다. 이 날짜 이전에 마이그레이션 중에 문제가 발생하는 경우 OpenID 2.0으로 롤백할 수 있습니다. 이 날짜까지 마이그레이션되지 않은 네임스페이스의 경우 사용자는 더 이상 Google 계정으로 로그인할 수 없으며 Google 계정의 OpenID 2.0이 사라졌음을 나타내는 페이지가 표시됩니다. Google 계정으로 로그인 기능을 복원하려면 네임스페이스를 마이그레이션해야 합니다.

    대부분의 경우 애플리케이션 코드 변경이 필요하지 않습니다. "통과한 모든 클레임" 규칙이 애플리케이션과 연결된 규칙 그룹의 ID 공급자로 Google에 대한 규칙인 경우 코드를 변경해야 할 수 있습니다. 마이그레이션 시 Google의 ACS에서 새 클레임 유형(Subject)을 사용할 수 있게 되고, 애플리케이션이 새 클레임 형식의 존재를 정상적으로 처리할 수 있도록 코드를 변경해야 할 수 있기 때문입니다. 마이그레이션을 성공적으로 완료하려면 애플리케이션에서 새 클레임 유형을 처리할 필요가 없습니다.

  • 2017년 1월 1일 – Google의 OpenID 2.0 및 OpenID Connect 구현은 다른 식별자를 사용하여 Google 사용자를 고유하게 식별합니다. ACS 네임스페이스를 마이그레이션할 때 ACS는 현재 OpenID 2.0 식별자와 새 OpenID Connect 식별자를 애플리케이션에서 사용할 수 있는 두 개의 식별자를 만듭니다. 백 엔드 시스템의 사용자 식별자를 이 날짜까지 OpenID Connect 식별자로 전환하고 앞으로 OpenID Connect 식별자만 사용하기 시작해야 합니다. 이렇게 하려면 애플리케이션 코드를 변경해야 합니다.

Stack Overflow 마이그레이션에 대한 질문을 게시하고 'acs-google'으로 태그를 지정할 수 있습니다. 우리는 가능한 한 빨리 응답 할 것입니다.

Google의 계획에 대한 자세한 내용은 OpenID 2.0 마이그레이션 가이드참조하세요.

마이그레이션 검사 목록

다음 표에는 Google의 OpenID Connect 구현을 사용하기 위해 ACS 네임스페이스를 마이그레이션하는 데 필요한 단계를 요약한 검사 목록이 포함되어 있습니다.

걸음 묘사 다음으로 완료해야 합니다.

1

Google 개발자 콘솔Google+ 애플리케이션을 만듭니다.

2015년 6월 1일

2

애플리케이션과 연결된 규칙 그룹에서 Google에 대한 "모든 클레임통과" 규칙이 있는 경우 애플리케이션을 테스트하여 마이그레이션이 준비되었는지 확인합니다. 그렇지 않으면 이 단계는 선택 사항입니다.

2015년 6월 1일

3

ACS 관리 포털 사용하여 Google+ 애플리케이션의 매개 변수(클라이언트 ID 및 클라이언트 암호)를 제공하여 GOOGLE의 OpenID Connect 구현을 사용하도록 ACS 네임스페이스를 전환합니다. 마이그레이션에 문제가 발생하는 경우 2015년 6월 1일까지 OpenID 2.0으로 롤백할 수 있습니다.

2015년 6월 1일

4

백 엔드 시스템의 사용자 식별자를 현재 Google OpenID 2.0 식별자에서 새 Google OpenID Connect 식별자로 마이그레이션합니다. 이렇게 하려면 코드를 변경해야 합니다.

2017년 1월 1일

마이그레이션 연습

Google의 OpenID Connect 구현을 사용하도록 ACS 네임스페이스를 마이그레이션하려면 다음 단계를 완료합니다.

  1. Google+ 애플리케이션 만들기

    이 작업을 수행하는 방법에 대한 자세한 지침은 방법: Google+ 애플리케이션 만들기 섹션을 참조하세요.

  2. 애플리케이션이 마이그레이션할 준비가 되었는지

    애플리케이션과 연결된 규칙 그룹에서 Google에 대한"모든 클레임통과" 규칙이 있는 경우 방법: ACS 애플리케이션의 마이그레이션 준비 상태 섹션의 지침에 따라 애플리케이션의 마이그레이션 준비 상태를 테스트합니다. 이는 마이그레이션 시 Google에서 ACS에서 새 클레임 유형(주체)을 사용할 수 있게 되기 때문입니다.

    메모

    "모든 클레임통과" 규칙은 입력 클레임 유형입력 클레임 값 모든 설정되는 규칙입니다. 출력 클레임 유형출력 클레임 값 첫 번째 입력 클레임 유형 통과하고 입력 클레임 값 통과하도록 설정됩니다. 규칙은 아래와 같이 ACS 관리 포털 나열되며 출력 클레임 열은 통과설정됩니다.

    통과 규칙통과 규칙

    이전에 애플리케이션과 연결된 규칙 그룹에서 Google에 대한 규칙을 수동으로 생성하거나 ID 공급자로 추가한 경우 이 단계를 건너뛸 수 있습니다. 이러한 경우 마이그레이션 시 새 주체 클레임 유형이 애플리케이션으로 전송되지 않기 때문입니다.

    이러한 옵션에 대한 자세한 내용은 규칙 그룹 및 규칙참조하세요.

  3. Google의 OpenID Connect 구현 사용하도록 ACS 네임스페이스 전환

    1. microsoft Azure 관리 포털이동하여 로그인하고 Active Directory클릭합니다. 마이그레이션해야 하는 ACS 네임스페이스를 선택하고 관리를 클릭하여 ACS 관리 포털시작합니다.

    2. ACS 관리 포털왼쪽 트리에서 ID 공급자 클릭하거나 시작 섹션 아래의 ID 공급자 링크를 클릭합니다. Google클릭합니다.

      Access Control Service ID 공급자 대화Access Control Service ID 공급자 대화 상자

    3. Google ID 공급자 편집 페이지에서 OpenID Connect사용을 선택합니다.

      Google ID 공급자 편집 대화Google ID 공급자 편집 대화 상자

    4. 클라이언트 ID클라이언트 비밀 필드(현재 사용)에서 Google+ 애플리케이션의 해당 값을 복사합니다.

      Google ID 공급자 편집 대화Google ID 공급자 편집 대화 상자

      메모

      이때저장을 클릭하면 ACS 네임스페이스의 모든 Google ID 공급자 요청이 Google의 OpenID Connect 구현을 자동으로 사용합니다. 롤백해야 하는 경우 OpenID Connect선택을 취소할 수 있습니다. 클라이언트 ID 및 클라이언트 비밀은 저장 상태로 유지되며 나중에 다시 사용할 수 있습니다.

    5. 저장을 클릭합니다.

    6. Google ID로 로그인하여 OpenID Connect 사용으로 전환이 성공했는지 확인합니다. 로그인하는 데 문제가 있는 경우 Google ID 공급자 편집 페이지로 돌아가서 OpenID Connect 사용하여 OpenID 2.0으로 롤백할 확인 취소합니다. 롤백한 후 Google 개발자 콘솔 복사한 클라이언트 ID비밀 네임스페이스에 대해 올바르게 입력되었는지 확인합니다. 예를 들어 오타가 있는지 확인합니다.

  4. 백 엔드 시스템의 사용자 식별자를 Open ID 2.0에서 OpenID Connect 마이그레이션

    2017년 1월 1일 이전에 백 엔드 시스템의 사용자 식별자를 기존 Google Open ID 2.0 식별자에서 새 Google OpenID Connect 식별자로 마이그레이션해야 합니다. 이 단계에서는 코드를 변경해야 합니다. 자세한 내용은 방법: 사용자의 기존 Open ID 2.0 식별자를 새 OpenID Connect 사용자 식별자로 마이그레이션

방법: Google+ 애플리케이션 만들기

다음 단계를 수행하려면 Google 계정이 필요합니다. 없는 경우 https://accounts.google.com/SignUp가져올 수 있습니다.

  1. 브라우저 창에서 Google 개발자 콘솔 이동하여 Google 계정 자격 증명으로 로그인합니다.

  2. 프로젝트만들기 클릭하고 프로젝트 이름 입력하고 프로젝트 ID. 서비스 약관 확인란을 선택합니다. 그런 다음 만들기클릭합니다. 그러면 애플리케이션이 Google에 등록됩니다.

    Google 개발자 콘솔 새 프로젝트 대화Google 개발자 콘솔 새 프로젝트 대화 상자

  3. 왼쪽 창에서 API & 인증 클릭합니다. 그런 다음 자격 증명클릭합니다. OAuth아래에서 새 클라이언트 ID만들기 클릭합니다. 웹 애플리케이션 선택하고 동의 구성 화면클릭합니다. 제품 이름 입력하고 저장을 클릭합니다.

    Google 개발자 콘솔 동의 화면Google 개발자 콘솔 동의 화면

  4. 왼쪽 창에서 API & 인증 클릭합니다. 그런 다음 API클릭합니다. 찾아보기 APIGoogle+ API검색하고 찾습니다. 상태 설정하여.

    Google 개발자 콘솔 찾아보기 APIGoogle 개발자 콘솔 찾아보기 API

  5. 클라이언트 ID 만들기 대화 상자에서 애플리케이션 유형웹 애플리케이션 선택합니다.

    권한 있는 Javascript 원본 필드에서 선행 "HTTPS://" 및 후행 포트 번호를 포함하여 네임스페이스의 FQDN(정규화된 도메인 이름) URL을 지정합니다. 예를 들어 https://contoso.accesscontrol.windows.net:443.

    권한 있는 리디렉션 URI 필드에서 네임스페이스의 FQDN(정규화된 도메인 이름) URL(앞에 오는 "HTTPS://" 및 후행 포트 번호, "/v2/openid")이 포함된 URI를 지정합니다. 예를 들어 https://contoso.accesscontrol.windows.net:443/v2/openid.

    클라이언트 ID 만들기클릭합니다.

    Google 개발자 콘솔 클라이언트 ID 만들기 화면Google 개발자 콘솔 클라이언트 ID 만들기 화면

  6. 웹 애플리케이션 페이지의 클라이언트 ID에서 클라이언트 ID클라이언트 비밀 값을 적어둡니다. ACS 관리 포털Google의 OpenID Connect 구현을 구성하려면 해당 구현이 필요합니다.

    웹앱용 Google 개발자 콘솔 클라이언트 ID웹앱용 Google 개발자 콘솔 클라이언트 ID

    중요하다

    클라이언트 암호 중요한 보안 자격 증명입니다. 비밀을 유지합니다.

방법: 사용자의 기존 Open ID 2.0 식별자를 새 OpenID Connect 사용자 식별자로 마이그레이션

Google의 OpenID Connect 구현을 사용하도록 ACS 네임스페이스를 성공적으로 마이그레이션한 후에는 2017년 1월 1일까지(Google의 OpenID 2.0 마이그레이션 가이드따라) 백 엔드 시스템의 사용자 식별자를 현재 OpenID 2.0 식별자에서 새 OpenID Connect 식별자로 마이그레이션해야 합니다.

다음 표에서는 ACS 네임스페이스가 Google의 OpenID Connect 구현을 사용하도록 마이그레이션되면 Google에서 ACS에서 사용할 수 있는 클레임 유형을 보여 줍니다.

클레임 유형 URI 묘사 프로토콜 가용성

이름 식별자

https://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier

Google에서 제공하는 사용자 계정에 대한 고유 식별자입니다. 이는 (기존) OpenID 2.0 식별자입니다.

OpenID 2.0, OpenID Connect

제목

https://schemas.microsoft.com/identity/claims/subject

Google에서 제공하는 사용자 계정에 대한 고유 식별자입니다. (새로운) OpenID Connect 식별자입니다.

OpenID Connect

이름

https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

Google에서 제공하는 사용자 계정의 표시 이름입니다.

OpenID 2.0, OpenID Connect

(아래 참고 사항 참조)

전자 메일 주소

https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

Google에서 제공하는 사용자 계정의 이메일 주소

OpenID 2.0, OpenID Connect

ID 공급자

https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/IdentityProvider

사용자가 기본 Google ID 공급자를 사용하여 인증했음을 신뢰 당사자 애플리케이션에 알리는 ACS에서 제공하는 클레임입니다. 이 클레임의 값은 ID 공급자 편집 페이지의 영역 필드를 통해 ACS 관리 포털에 표시됩니다.

OpenID 2.0, OpenID Connect

메모

(등록된) Google+ 프로필이 없는 Google 사용자의 경우 이름 클레임 유형의 값은 OpenID Connect에서 전자 메일 주소 클레임 유형의 값과 동일합니다.

이름 식별자주체 클레임 유형을 사용하여 (이전) OpenID 2.0 식별자를 (새) OpenID Connect 식별자에 매핑하여 백 엔드에서 기존 사용자의 고유 식별자를 추적하고 전환할 수 있습니다.

애플리케이션과 연결된 규칙 그룹의 ID 공급자로 Google에 대한 "모든 클레임통과" 규칙이 "있는 경우 애플리케이션은 자동으로 주체 클레임 유형을 받기 시작합니다.

이전에 애플리케이션과 연결된 규칙 그룹에서 Google에 대한 규칙을 생성하거나 ID 공급자로 수동으로 규칙을 추가한 경우 주체 클레임 유형을 수동으로 추가해야 합니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 규칙 그룹 및 규칙참조하세요.

입력 클레임 구성입력 클레임 구성

예를 들어 이전에 Google에 대한 규칙을 규칙 그룹에서 ID 공급자로 생성한 다음 위와 같이 새 Subject 클레임 유형을 추가한 경우 다음이 표시됩니다.

Google 통과 클레임

이 규칙 그룹을 사용하는 애플리케이션은 다른 클레임 유형과 함께 주체 클레임 유형을 받습니다.

메모

2017년 1월 1일 이후 Google이 식별자 매핑 지원을 중단하면 ACS는 NameIdentifierSubject 클레임 유형을 동일한 OpenID Connect 사용자 식별자를 사용하여 채웁니다.

방법: ACS 애플리케이션의 마이그레이션 준비 상태 확인

한 가지 예외를 제외하고 애플리케이션 코드를 변경하지 않고도 Google의 OpenID Connect 구현을 사용하도록 ACS 네임스페이스를 마이그레이션할 수 있습니다. 예외 사례는 애플리케이션과 연결된 규칙 그룹에서 Google에 대한 "모든 클레임통과" 규칙이 있는 경우입니다. 이 경우 마이그레이션 시 새 클레임 유형(주체)이 애플리케이션에 자동으로 전송되므로

이 섹션에서는 마이그레이션의 영향을 받는 모든 애플리케이션이 새 클레임 유형을 처리할 준비가 되었는지 확인하기 위해 수행할 수 있는 권장 변경 및 테스트 절차를 간략하게 설명합니다.

이 방법의 목적을 위해 사용자가 ns-contoso 호출된 ACS 네임스페이스의 소유자이며 프로덕션의 애플리케이션을 prodContosoApp호출한다고 가정합니다. 또한 이 애플리케이션은 Google을 ID 공급자로 사용하고 Google에 대해 "모든 클레임통과" 규칙을 사용하도록 설정했다고 가정합니다.

설치

  1. 시작하려면 Microsoft Azure 관리 포털이동하여 로그인한 다음 Active Directory클릭합니다. ACS 네임스페이스(ns-contoso)를 선택한 다음 관리를 클릭하여 ACS 관리 포털시작합니다.

  2. ACS 관리 포털왼쪽 트리에서 신뢰 당사자 애플리케이션 클릭하거나 시작 섹션 아래의 신뢰 당사자 애플리케이션 링크를 클릭합니다. 그런 다음 프로덕션 애플리케이션(ProdContosoApp)을 클릭합니다.

  3. ProdContosoApp속성을 적어둡니다. 나중에 필요합니다.

    신뢰 당사자 애플리케이션 편집 대화신뢰 당사자 애플리케이션 편집 대화 상자

  4. 규칙 그룹 ProdContosoApp에 대한 기본 규칙 그룹을 클릭하여 Google에 대해 "모든 클레임통과" 규칙을있는지 확인합니다.

    Google 통과 클레임

1단계: 프로덕션 ACS 네임스페이스에서 애플리케이션의 테스트 인스턴스 설정

다른 루트 URI에서 TestContosoApp애플리케이션의 테스트 인스턴스를 설정합니다. 예를 들어 . ns-contoso 네임스페이스에서 신뢰 당사자 애플리케이션(신뢰 당사자 애플리케이션)으로 등록해야 합니다.

  1. ACS 관리 포털왼쪽 트리에서 신뢰 당사자 애플리케이션 클릭하거나 시작 섹션 아래의 신뢰 당사자 애플리케이션 링크를 클릭합니다. 그런 다음 신뢰 당사자 애플리케이션 페이지에서 추가를 클릭합니다.

  2. 신뢰 당사자 애플리케이션 추가 페이지에서 다음을 수행합니다.

    • 이름테스트 애플리케이션의 이름을 입력합니다. 다음은 TestContosoApp.

    • 모드설정을 수동으로선택합니다.

    • 영역테스트 애플리케이션의 URI를 입력합니다. 여기에 https://contoso-test.com:7777/.

    • 이 방법의 목적을 위해 오류 URL(선택 사항) 비워 둘 수 있습니다.

    • 토큰 형식, 토큰 암호화 정책토큰 수명(초) 속성 및 토큰 서명 설정 섹션의 경우 prodContosoApp데 사용한 것과 동일한 값을 사용합니다.

    • Google ID 공급자선택했는지 확인합니다.

    • 규칙 그룹아래에서 새 규칙 그룹 만들기선택합니다.

    신뢰 당사자 애플리케이션 추가 대화신뢰 당사자 애플리케이션 추가 대화 상자

  3. 페이지 아래쪽에서 저장을 클릭합니다.

2단계: 네임스페이스가 Google의 OpenID Connect 구현을 사용하도록 마이그레이션된 후 애플리케이션이 받을 ACS 토큰의 형식을 시뮬레이션하는 규칙 그룹 만들기

  1. ACS 관리 포털왼쪽 트리에서 규칙 그룹 클릭하거나 시작 섹션 아래의 규칙 그룹 링크를 클릭합니다. 그런 다음 규칙 그룹 페이지에서 추가를 클릭합니다.

  2. 규칙 그룹 추가 페이지에서 새 규칙 그룹의 이름을 입력합니다(예: ManualGoogleRuleGroup). 저장을 클릭합니다.

    규칙 그룹 추가 대화 상자

  3. 규칙 그룹 편집 페이지에서 추가 링크를 클릭합니다.

    규칙 그룹 편집 대화 상자

  4. 클레임 규칙 추가 페이지에서 다음 값이 있는지 확인하고 저장을 클릭합니다. 그러면 Google에 대한 "모든 클레임통과" 규칙이 생성됩니다.

    • if 섹션:

      • ID 공급자 Google.

      • 입력 클레임 유형 선택은 모든.

      • 입력 클레임 값 모든.

    • 다음 섹션:

      • 출력 클레임 유형첫 번째 클레임 유형통과합니다.

      • 출력 클레임 값첫 번째 입력 클레임 값통과합니다.

    • 규칙 정보 섹션:

      • 설명(선택 사항) 필드를 비워 둡니다.

    클레임 규칙 추가 대화클레임 규칙 추가 대화 상자

  5. 규칙 그룹 편집 페이지에서 추가 링크를 다시 클릭합니다.

  6. 클레임 규칙 추가 페이지에서 다음 값이 있는지 확인하고 저장을 클릭합니다. 이렇게 하면 Google에서 마이그레이션 시 애플리케이션을 보내는 새 사용자 OpenID Connect 식별자인 새 클레임 유형 주체추가를 시뮬레이션하는 Google에 대한 "정적" 클레임 규칙이 생성됩니다.

    • if 섹션:

      • ID 공급자 Google.

      • 입력 클레임 유형 선택은 모든.

      • 입력 클레임 값 모든.

    • 다음 섹션:

    • 규칙 정보 섹션:

      • 설명(선택 사항) 필드를 비워 둡니다.

    클레임 Rull 추가 대화클레임 Rull 추가 대화

  7. 편집 규칙 그룹 페이지에서 저장을 클릭합니다.

3단계: 새 규칙 그룹을 애플리케이션의 테스트 인스턴스와 연결

  1. ACS 관리 포털왼쪽 트리에서 신뢰 당사자 애플리케이션 클릭하거나 시작 섹션 아래의 신뢰 당사자 애플리케이션 링크를 클릭합니다. 그런 다음 신뢰 당사자 애플리케이션 페이지에서 TestContosoApp 클릭합니다.

  2. 신뢰 당사자 편집 페이지의 인증 설정 섹션에서 ManualGoogleRuleGroup 선택하고저장 클릭합니다.

    인증 설정

이 시점에서 테스트 애플리케이션에 대한 모든 Google 로그인 요청에는 새 클레임 유형이 포함됩니다.

4단계: 애플리케이션이 주체 클레임 유형의 추가를 처리할 수 있는지 테스트

애플리케이션을 테스트하여 새 클레임 유형(Subject)의 존재를 정상적으로 처리할 수 있는지 확인합니다. 일반적으로 잘 작성된 애플리케이션은 토큰에 추가되는 새 클레임 유형에 대해 강력해야 합니다. 문제를 찾아서 해결합니다. 필요에 따라 사용자의 기존 Open ID 2.0 식별자를 새 OpenID Connect 사용자 식별자 섹션으로 마이그레이션하여 사용자 식별자 매핑을 수행할 수도 있습니다.

5단계: 프로덕션 환경 마이그레이션

프로덕션 애플리케이션(ProdContosoApp)을 다시 빌드하고 배포합니다. 마이그레이션 연습의 단계에 따라 네임스페이스(ns-contoso)를 마이그레이션하여 Google의 OpenID Connect 구현을 사용합니다. ProdContosoApp 예상대로 작동하는지 확인합니다.