2013-02-23 2 views
2

ACS (http://msdn.microsoft.com/en-us/library/ee706734.aspx)에 대한 일반 텍스트 및 서명 된 토큰 요청 방법 중에서 선택하려고합니다.ACS 토큰 요청 평문 대 서명 됨

내가이 두 가지 방법을 구별하기 위해 생각해 낸 유일한 점은 다른 사람이 내 암호를 얻기 위해 HTTPS 트래픽을 해독하려고 시도 할 때 서명 된 방법이 도청 자에 대한 추가 완화를 제공한다는 것입니다. Signed의 경우 HTTPS를 해독하는 것 외에도 (서명 키를 배우기 위해) 서명을 해독해야하기 때문에 더 어려울 것입니다.

그렇다면 HTTPS는 충분히 강하다고 간주되어 아무도 내 메일을 읽을 수 없도록 추가로 필요하지 않아야합니까?

일반 텍스트와 서명 된 ACS에 대한 토큰 요청 방법을 선택하는 데있어 필자의 주장은 무엇일까요?

+0

더 이상 지원되지 않는 ACS 1.0에 대한 설명서가 있습니다. "이 콘텐트는 구형입니다 .ACS (Windows Azure Access Control Service)에 대한 자세한 내용은 액세스 제어 서비스 2.0을 참조하십시오." –

답변

2

일반 텍스트 및 서명 된 요청은 모두 HTTPS 전송으로 보호됩니다. ACS에서 발급 한 토큰은 신뢰 당사자 (범위)에 대해 구성된 웹 토큰 형식을 따르며 발급 된 ACS 토큰의 클레임에는 변환 규칙 엔진에서 생성 된 클레임 결과가 포함됩니다.

평문 요청에는 서비스 ID의 사용자 이름과 암호를 ACS에 보내고 액세스 토큰을 받기 원하는 신뢰 당사자를 나타내는 범위가 포함됩니다. 이 시나리오에서 호출자는 토큰을 수신하기 위해 서비스 신임 자격 증명 만 알고 있어야합니다. 일반 텍스트 요청에서 클레임 정보 엔진이 사용할 수있는 유일한 클레임은 이름 식별자입니다.

한편 서명 된 요청은 서비스 소비자가 클레임 정보 엔진에 더 많은 클레임 집합을 제공하려고 할 때입니다. 서비스 소비자는 지정된 어설 션 형식 (일반적으로 SWT 또는 JWT)을 사용하여 인코딩 된 어설 션을 생성하고 어설 션을 디지털 서명하여 대칭 또는 비대칭 서명 키를 사용하여 일련의 클레임을 어설 션합니다.

SWT는 HMAC SHA-256 알고리즘을 사용하는 대칭 서명 만 지원하며 JWT는 대칭 및 비대칭 서명 알고리즘을 모두 지원합니다. 이 시나리오에서 서비스 소비자는 어설 션에 디지털 서명하는 데 사용되는 서명 키가 있어야합니다. ACS는 호출자가 신뢰할 수 있고 (서명 키를 소유하고 있음을 보장하기 위해) 어설 션의 디지털 서명을 확인하고 어설 션이 변경되지 않았 음을 확인합니다. 클레임 변환 엔진은 신뢰 당사자 규칙을 적용하여 액세스 토큰을 생성합니다.

클레임 변환 엔진 (이름 식별자가 충분 함)에 제공된 풍부한 클레임 집합이 필요하지 않거나 서비스 소비자가 어설 션의 암호화 서명을 지원하지 않을 때 일반 텍스트 요청을 사용합니다.

출력 청구 클레임을 수행하기 위해 클레임 변환 규칙에 여러 클레임이 필요할 때 또는 서비스 소비자가 이미 사용하려는 SAML 어설 션을 가지고있을 때 서명 된 요청을 사용하십시오.

OAUTH WRAP 프로토콜에 대한 자세한 설명은 OAuth WRAP을 참조하십시오.