|통합 프록시 인증: 서비스 계정과 가장
|동일한 애플리케이션이 대화형으로는 작동하지만 웹 서비스나 예약된 프로세스로는 실패할 때 통합 프록시 인증 뒤에 있는 보안 컨텍스트를 살펴봅니다.
“내 Windows 자격 증명 사용”에는 주체가 필요합니다. 데스크톱 프로그램에서는 이를 실행하는 사람이 주체일 수 있습니다. 서비스에서는 서비스의 계정이 주체일 수 있습니다. 웹 애플리케이션에서는 방문자의 성공적인 로그인이 아웃바운드 요청의 보안 컨텍스트를 자동으로 대체하지 않습니다.
이것은 같은 머신의 브라우저와 서버 측 코드가 통합 인증 프록시로부터 서로 다른 결과를 받을 수 있는 이유를 설명합니다. 두 주체가 서로 다른 ID를 제시하고 있을 수 있습니다.
코드를 변경하기 전에 ID를 이름 붙이세요
- 데스크톱 브라우저에 로그인한 사람.
- 애플리케이션 프로세스를 호스팅하는 계정.
- 아웃바운드 작업에 대해 활성화된 가장된 ID.
- 프록시가 실제로 허용하거나 거부한 계정.
.NET이 지원하는 통합 인증 경로에서 DefaultCredentials는 현재 보안 컨텍스트를 가리킵니다. 다른 머신에서 페이지를 연 모든 사람을 위한 전역 별칭이 아닙니다.
제품이 의도적으로 사용자로 동작한다면 가장과 네트워크 위임 요구 사항에는 각자의 지원되는 설계가 필요합니다. 일반적인 기본 자격 증명 사용 스위치를 켜는 것만으로는 그 설계가 확립되지 않습니다. 반대로 서비스 ID로 실행하도록 의도된 백그라운드 작업은 누군가 먼저 브라우저를 여는 것에 의존해서는 안 됩니다.
비밀을 제거한 상태에서 대화형 시작과 배포된 시작을 비교하세요. 계정 컨텍스트, 프록시 엔드포인트, 알려진 메서드, 거부된 ID입니다. 일회성 요청이 성공했다는 이유만으로 데스크톱 암호를 애플리케이션에 복사하지 마세요. 애플리케이션이 사용해야 하는 계정을 구성한 다음 그 소유권을 배포 기록에 가시적으로 유지하세요.