Azure의 페더레이션 인증

Azure의 페더레이션 인증

인증에 WIF(.net 4.5) 및 Azure Active 디렉토리를 사용하고 있습니다.그 웹사이트는 Azure에 위치할 것입니다.

모든 것이 현지에서 예상대로 작동하지만 zure에 놓으면 다음과 같은 오류가 발생합니다.

데이터 보호 작업에 실패했습니다.이 문제는 현재 스레드의 사용자 컨텍스트에 대한 사용자 프로필이 로드되지 않았기 때문일 수 있습니다. 스레드가 가장하는 경우일 수 있습니다.

앱이 DAPI를 사용할 수 없기 때문에 MAC로 앱을 보호하는 것으로 전환해야 하기 때문인 것으로 알고 있습니다.

로컬에서 웹 구성에 추가했습니다.

 <securityTokenHandlers>
    <remove type="System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
    <add type="System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
  </securityTokenHandlers>

설명서에서 권장하는 대로 정적 기계 키를 추가했지만 키 길이에 대한 조언을 찾을 수 없어서 256개로 가정했습니다.

그러나 이 구성은 다음과 같은 오류를 발생시킵니다.

[암호화 예외:암호화 작업 중 오류가 발생했습니다.]시스템.웹. 보안.암호학.암호화와 서비스 래퍼를 균질화합니다.균질화 오류(Func`2 func, 바이트[] 입력) +115 시스템.웹. 보안.암호학.암호화와 서비스 래퍼를 균질화합니다.보호 해제(바이트[] 보호된 데이터) +59 시스템.웹. 보안.컴퓨터 키.보호 해제(ICryptoServiceProvider cryptoServiceProvider, Byte[] protectedData, String[] 용도) +62 시스템.웹. 보안.컴퓨터 키.보호 해제(바이트[] 보호된 데이터, 문자열[] 목적) +122 시스템.아이덴티티 모델.서비스.컴퓨터 키 변환.디코딩(바이트[] 인코딩) +161 시스템.아이덴티티 모델.토큰.세션 보안토큰 핸들러.변환 적용(바이트[] 쿠키, 부울 아웃바운드) +123 시스템.아이덴티티 모델.토큰.세션 보안토큰 핸들러.ReadToken(XmlReaderReaderReaderReader, 보안)토큰리졸버 토큰리졸버) +575 시스템.아이덴티티 모델.토큰.세션 보안토큰 핸들러.읽기 토큰(바이트[] 토큰, 보안토큰리졸버 토큰리졸버) +76 시스템.아이덴티티 모델.서비스.세션 인증 모듈입니다.세션 읽기TokenFromCookie(Byte[] sessionCookie) +833 시스템.아이덴티티 모델.서비스.세션 인증 모듈입니다.TryRead 세션쿠키에서 토큰(세션 보안)토큰 & 세션토큰) +186 시스템.아이덴티티 모델.서비스.세션 인증 모듈입니다.인증 요청 시(개체 보낸 사람, EventArgs 이벤트 인수) +210 시스템.Web.SyncEvent실행단계.시스템. 웹.HttpApplication.실행 단계.() +136 시스템을 실행합니다.Web.Http 응용 프로그램.ExecuteStep(I ExecutionStep, Boolean & CompletedSynchronously) +69

올바른 형식의 키를 지정하지 않은 경우를 대비하여 기계 키 섹션을 제거했지만 오류가 사라지지 않습니다.

WIF가 얼마나 싸웠는지!

구성에서 machineKey를 지정하지 않으면 Azure가 machineKey를 추가합니다.그러나 VIP 스위칭을 사용하여 애플리케이션의 새 버전을 생성하고 이를 Azure에 배포하는 경우 Azure는 스테이징에서 배포를 위한 새 시스템 키를 생성합니다(첫 번째 배포가 운영 환경이었다고 가정).VIP 스위칭은 새 버전을 배포한 다음 운영 및 스테이징 간에 가상 IP 주소를 전환하는 데 유용합니다.

기본적으로 한 가지 해결책은 Azure가 키를 생성하도록 허용하는 것이지만 VIP 전환 후에는 문제가 다시 발생합니다.이를 방지하기 위해 Application_Error 핸들러의 Global.asax에 있는 CryptographicException을 다음과 같이 잡을 수 있습니다.

// Be sure to reference System.IdentityModel.Services
// and include using System.IdentityModel.Services; 
// at the start of your class
protected void Application_Error(object sender, EventArgs e)
{
    var error = Server.GetLastError();
    var cryptoEx = error as CryptographicException;
    if (cryptoEx != null)
    {
        FederatedAuthentication.WSFederationAuthenticationModule.SignOut();
        Server.ClearError();
    }
}

SignOut() 메서드는 쿠키를 제거합니다.

편집: @anjdreas에서 언급한 대로 machineKey 생성에 대한 정보가 업데이트되었습니다.

다른 솔루션은 machineKey를 생성하는 것입니다. IIS 관리자를 사용하여 이를 수행할 수 있습니다. 자세한 내용은 machineKey를 생성하는 가장 쉬운 방법을 참조하십시오.Azure 웹 역할 내의 모든 웹 응용 프로그램에 동일한 키를 입력하는 경우 Azure 배포 프로세스가 이 키를 대체하지 않습니다.

Windows Azure는 컴퓨터 키를 생성하여 역할의 모든 인스턴스에서 동일하게 설정합니다.

표시되는 오류: 쿠키를 지우시겠습니까?

쿠키를 지우는 것만으로 이 경우 모든 문제가 해결되었습니다.

양식 auth를 사용하는 경우.예외가 발생하면 로그아웃하고 사용자가 로그인하여 유효한 쿠키를 만들 수 있습니다.

catch (CryptographicException cex)
{
    FormsAuthentication.SignOut();
}

모든 사용자에게 모든 쿠키를 지우라고 하는 것은 제게 선택사항이 아니었습니다.이 사이트와 "Windows Identity Federation 프로그래밍"이라는 책에서 더 나은 솔루션을 찾았습니다.이미 SSL 인증서를 Azure에 업로드하고 있는 경우 해당 인증서를 사용하여 모든 Azure 인스턴스에서 쿠키를 암호화할 수 있으며 새 컴퓨터 키, IIS 사용자 프로필 등에 대해 걱정할 필요가 없습니다.

언급URL : https://stackoverflow.com/questions/14119965/federated-authentication-on-azure