2

양식 인증이있는 asp.net 웹 응용 프로그램이 있고 사용자 (자격 증명)가 활성 디렉토리와 비교하여 확인되면 사용자 이름은 실제로 AD의 samAccountName 속성입니다. 이제 사용자가 자신의 폴더가있는 파일 공유에있는 일부 파일에 액세스 할 수 있어야합니다.Asp.net - 인증 된 사용자를 기반으로 파일 공유에있는 일부 폴더에 액세스

개념의

첫 번째 증거는 다음과 같이 작동 :

  1. IIS에서 AppPool을 어떤 도메인 사용자로 실행되도록 구성되며,이 사용자는 공유 및 모든 사용자 폴더를 파일에 R/W 액세스 권한을 부여했다

  2. 사용자가 웹 응용 프로그램에 로그인 할 때 "\\ myFileServer \ username"경로의 폴더 내용 만 볼 수 있습니다. 그리고 파일을 업로드 할 때 "\\ myFileServer \ username"에 저장됩니다.

이 방법이 효과가있는 것은 아닙니다. 첫 번째 문제는 응용 프로그램 풀을 실행하는 사용자가 모든 사용자의 폴더에 액세스 할 수 있다는 것입니다. 더 큰 관심사는 사용자 이름 만 액세스 권한이있는 폴더를 결정한다는 것입니다.

그럼 내 질문은이 일을하는 올바른/더 좋은 방법은 무엇입니까? 나는 사용자를 가장하는 것에 대해 읽고 있었지만, 올바르게 이해하면 더 이상 권고하지 않습니다. 웹 응용 프로그램은 인터넷에서 액세스 할 수 있어야하므로 Windows 인증이 없습니다.

+0

https :를 통해 기본 인증을 사용하고 파일 공유에 대한 액세스를 가장 할 수 있습니다. –

+0

양식 인증을 사용하는 또 다른 이유는 브라우저가 자격 증명을 묻는 메시지가 아닌 사용자 지정 로그인 양식을 필요로하기 때문입니다. 그래서 우리는 그대로 폼 승인을 유지할 것입니다. 문제는 파일 시스템에 안전하게 액세스하는 방법에 있습니다. – Primoz

+0

당신은 위장이 더 이상 권고되지 않는다는 것을 어디에서 읽었습니까? 이 문제에 잘 맞는 것 같습니다. –

답변

1

나는 응용 프로그램을 사용자 계정으로 실행하지 않고 적절한 R/W 권한으로 실행되는 응용 프로그램 별 계정을 생성하고 이러한 권한을 부여한 사람과 개발 팀을 분리하는 것이 좋습니다.

응용 프로그램의 인증 내역 : GET/POST 요청을받은 후 현재 사용자가 데이터를 읽거나 쓸 수있는 경로를 확인하고 사용자가 읽고 쓸 수있는 경로와 상호 참조 할 수 있습니다 에서. 이것이 올바르지 않은 경우 401 NOT AUTHORIZED 응답을 반환하고, 그렇지 않으면 지금까지했던 것처럼 작업을 계속 수행하십시오.

엔드 포인트가 올바르게 보호되고 응용 프로그램이 자체 계정으로 실행되는 경우 설치 자체에 아무런 해가 없습니다. 그러나 여전히 개발자는 응용 프로그램을 통해 다른 사용자의 파일에 간접적으로 액세스 할 수 있습니다. 이러한 점검이 얼마나 긴밀한가에 따라 애플리케이션을 프로덕션 서버에서 연결하고 제어 방식으로 서버 전송 만 허용하는 등의 추가 컨트롤을 추가 할 수 있습니다.

+0

나는 시스템 자체에 최소한의 권한을 가진 "svcMyWebApp"와 같은 특정 계정 하에서 이미 응용 프로그램을 실행하고 있습니다. – Primoz

+0

나는 어떤 사용자가 이미 웹 응용 프로그램에 로그인 한 후 어떤 방법으로 그것을 이용하여 다른 사용자로 자신을 소개하고 그 사용자 폴더에 대한 액세스 권한을 얻게 될까 우려합니다. 웹 응용 프로그램은 공유 폴더의 모든 폴더에 액세스 할 수 있으므로 사용자 이름에 따라 사용자를 올바른 폴더로 제한 할 수 있습니다. – Primoz

+0

사용자 이름이 사용자가 직접 변경할 수 있습니까?이 경우 실제로 위험하며 각 사용자에 대해 ID와 같이 변경할 수없는 고유 한 식별자가 있는지 확인할 수 있습니다. –

1

당신의 문제 설명에서 나는 Custom HttpHandlers이 당신을위한 올바른 선택이라고 생각합니다. 당신은 어떤 유형의 파일이 귀하의 폴더에 존재하는지 언급하지 않았으며, 간결함을 위해 PDF 파일을 가지고 있다고 가정하여 대답 할 것입니다.

응용 프로그램에 다른 사용자가 있다고 언급 했으므로 .NET 기본 인증 관리자와 역할 공급자를 사용해야합니다. 간단한 보안 프레임 워크 설정을 통해 web.config protected 폴더 뒤에 PDF 파일을 웹 응용 프로그램에 배치합니다. 그런 다음 사용자 정의 HTTP 처리기를 만들어 정적 문서에 대한 액세스를 볼 수 있어야하는 사용자로만 제한합니다 그것.

샘플 HTTP 처리기 :

public class FileProtectionHandler : IHttpHandler 
{ 

    public void ProcessRequest(HttpContext context) 
    { 
     switch (context.Request.HttpMethod) 
     { 
      case "GET": 
      { 
       // Is the user logged-in? 
       if (!context.User.Identity.IsAuthenticated) 
       { 
        FormsAuthentication.RedirectToLoginPage(); 
        return; 
       } 
       string requestedFile = 
       context.Server.MapPath(context.Request.FilePath); 
       // Verify the user has access to the User role. 
       if (context.User.IsInRole("User")) 
       { 
        SendContentTypeAndFile(context, requestedFile); 
       } 
       else 
       { 
        // Deny access, redirect to error page or back to login 
        //page. 
        context.Response.Redirect("~/User/AccessDenied.aspx"); 
       } 
       break; 
     } 
    } 
} 

방법 SendContentTypeAndFile :

private HttpContext SendContentTypeAndFile(HttpContext context, String strFile) 
{ 
    context.Response.ContentType = GetContentType(strFile); 
    context.Response.TransmitFile(strFile); 
    context.Response.End(); 
    return context; 
} 
private string GetContentType(string filename) 
{ 
    // used to set the encoding for the reponse stream 
    string res = null; 
    FileInfo fileinfo = new FileInfo(filename); 
    if (fileinfo.Exists) 
    { 
     switch (fileinfo.Extension.Remove(0, 1).ToLower()) 
     { 
      case "pdf": 
      { 
       res = "application/pdf"; 
       break; 
      } 
     } 
     return res; 
    } 
    return null; 
} 

마지막 단계는의 webconfig에 을이 HTTP 처리기를 구성 할 필요가 있다는 것입니다 그리고 당신은 더 볼 수 있습니다 정보 here

여기에 완전한입니다. 0

+0

그것은 사용자 정의 이진 파일이지만, 그것은 중요하지 않습니다. – Primoz

+0

파일은 웹 서버에 저장되지 않고 파일 공유에 저장되며 각 사용자는이 파일 공유에 고유 폴더를 가지고 있습니다. 웹 설정으로이 설정을 보호 할 수 있습니까? 또한 사용자는 시간이 지남에 따라 추가되거나 제거되며 대개 1 또는 2 명의 사용자가 일주일에 추가되거나 제거됩니다. – Primoz

0

보안 수준이 낮은 경우에는 아키텍처가 유용하지만 데이터의 특성이 매우 중요하면 (의료 등) 보안에 대한 가장 큰 우려는 사용자 세션을 제어하는 ​​것입니다.

폼 인증을 사용하는 경우 인증 된 ID를 쿠키 또는 토큰에 저장합니다 (또는 끈적 세션을 사용하는 경우 세션 ID를 보내는 경우). 같은). 사용자 A가 작동하는 시스템에 사용자 B가 phisical 액세스 권한을 가지고있는 경우 문제가 발생합니다. 사용자 A가 직장을 떠날 때 (잠시 또는 영원히) 웹 앱에서 세션을 명시 적으로 닫지 않으면 그의 쿠키/토큰이 만료 될 때까지 신원이 남았습니다. 사용자 B는이 쿠키를 사용할 수 있습니다. ASP.NET의 ID 시스템이 SignOut을 수행하지 않았기 때문입니다. 사용자가 서명 할 때 Identity System의 모든 악명 높은 Microsoft 구현에서 이러한 토큰을 무효화하고 (클라이언트 시스템에서 해당 토큰이 사라지게하는) 방법을 제공해야하기 때문에 토큰을 사용하면 문제가 더욱 심각해집니다. 만료 될 때까지 유효합니다. 이 문제는 해결할 수 있지만 (보안 요구 사항이 높으면 만족스럽지는 않음) 생생한 짧은 새로 고침 토큰을 발행합니다.하지만 이는 또 다른 이야기이며, 귀하의 소송인지 여부는 알 수 없습니다. 쿠키를 사용하는 경우 사용자 A가 로그 아웃하면 쿠키가 무효화되고 요청/응답 큐클에서 제거되므로이 문제가 완화됩니다. 어쨌든 사용자는 웹 앱에서 세션을 닫거나 짧은 생명 또는 짧은 슬라이딩 만료로 쿠키를 구성해야합니다.

ASP.NET의 위장 방지 토큰 인프라를 사용하지 못하도록 할 수있는 다른 보안 문제가 CSRF와 관련 될 수 있지만 이런 종류의 공격은 팁을 사용하는 사용자와 매우 거리가 먼 방법입니다. 사용자의 특성 및 앱이 인터넷에 공개되거나 인트라넷에서만 액세스 할 수있는 경우) 그런 특수 공격을 걱정하고 민감한 데이터가있는 경우 폼 인증보다 복잡한 작업을 수행해야합니다 (두 요소, 생체 인식 등)