6

인증이 필요한 영역이 있습니다. 지금은 해당 영역의 모든 컨트롤러에서 roles 속성을 사용하고 사용자 ID와 모든 설정을 검색하는 쿼리를 실행합니다.ASP.Net MVC 사이트에서 인증을 어떻게해야합니까?

해당 지역의 컨트롤러가로드 될 때마다 사용자 ID와 설정을 검색한다는 것이 코드 나 디자인 냄새처럼 보입니다. 나는 세션을 사용해야하는지, ASP.Net MVC 2.0이 이것을 처리 할 수있는 몇 가지 고유 한 방법을 제공하는지 잘 모르겠습니다. 또 다른 관심사는 보안입니다.

전반적으로 나는 어떤 방향으로 돌릴 지 실제로 알지 못합니다. 현명한 디자인 사용자가 로그인 할 때 userID와 설정을 한 번만 가져오고 싶습니다. 지금 컨트롤러를로드 할 때마다 userId를 가져오고 필요할 경우 매번 데이터베이스 설정을 쿼리합니다.

+2

제목을 설명하기 쉽게 만드는 것이 좋습니다. 이 제목은 솔직히 쓸모가 없습니다. "ASP.Net 사이트에서 인증을 어떻게해야합니까?" –

+0

질문과 같은 소리는 주로 성능에 관한 것입니다. 설정 데이터베이스를 너무 자주 사용하는 것처럼 느껴 집니까? –

+0

내가 생각하기에 세션을 사용하지 않고 데이터를 지속시키기위한 간단한 mvc (1 또는 2) 특정 솔루션이 있다고 생각합니다. – chobo

답변

11

보안에 관한 규칙 중 하나는 사용자가 직접 시도하지 말아야한다는 것입니다. 허점이나 뒷문을 떠나지 않고 인증 시스템을 올바르게 수행하는 데는 여러 가지 함정이 있습니다. 따라서 이와 관련하여 .NET과 함께 제공되는 SqlMembershipProvider를 고려할 수 있습니다. MVC와 함께 사용할 수 있으며 역할 및 현재 보안 컨텍스트를 얻는 방법을 제공하며 설치 및 구성이 쉽고 자신의 롤링보다 안전합니다.

SQL Server를 사용하지 않는 경우 몇 가지 옵션이 있습니다. 한 가지 해결책은 SQL Server Express 또는 SQL Server Compact Edition과 같은 것을 사용하여 자격 증명을 유지하는 것입니다. 또 다른 솔루션은 SqlMembrershipProvider 데이터베이스 스키마를 모방 한 다음 해당 스키마와 통신하는 사용자 지정 공급자를 작성하는 것입니다.

마지막으로 사용자 지정 MembershipProvider 클래스를 작성해야합니다. 이것은 여전히 ​​자신 만의 역할을 수행하고 있지만 MembershipProvider의 구조로 들어가서 나중에 다른 인스턴스 (예 : ActiveDirectoryMembershipProvider)로 바꿀 수 있으며 자격 증명 및 로그인과 상호 작용할 수있는 공통 인터페이스를 제공합니다 내장 로그인 컨트롤을 쉽게 사용할 수 있습니다.

이미 MembershipProvider를 사용 중이고 추가 사용자 별 데이터 저장에 대해 질문하는 경우 위에 언급 한 SqlMembershipProvider에 대한 모든주의 사항이 포함 된 SqlProfileProvider를 제안합니다. ProfileProvider는 현재 로그온 한 사용자와 사용자 별 데이터를 유지 관리하기위한 구조를 제공합니다.자세한 내용은

:

+0

현재 잘 작동하는 맞춤 멤버십 제공 업체를 사용하고 있습니다. 내가 알아낼 수있는 것은 userId와 설정을 처리하는 가장 좋은 방법입니다. 개인이 로그인 할 때 한 번만 userId 및 설정을 검색해야합니다. 해당 지역의 다른 컨트롤러에서 데이터를 유지하는 것이 가장 좋은 방법이 확실하지 않습니다. 또한 성능 및 보안을 고려합니다. – chobo

+0

@chobo - 커스텀 MembershipProvider를 사용한다면, GetUser로부터 리턴 된'MembershipUser' 클래스의'ProviderUserKey' 속성을 사용하여 UserId를 얻을 수 있어야합니다. 사용자 설정을 위해 ProfileProvider를 구현하는 것이 좋습니다. – Thomas

+0

@chobo : ProfileProvider를 사용하지 않는 것이 좋습니다. 오버 헤드를 필요로하지 않으며 상자 밖에서 구현하는 방식이 끔찍합니다.사용자 테이블 (또는 관련 테이블)에 설정 및 환경 설정을 추가하고 MembershipProvider에서 처리하는 자주 사용되는 정보 (인증 정보 아님)를 저장하는 세션에 저장된 작은 DTO/ViewData 객체를 만드는 것이 훨씬 쉽습니다. –

0

필요한 모든 사용자 정보를 보유하고있는 세션에 개체를 저장할 수 있습니다. 컨트롤러, 뷰 또는 사용자 정보/프로필을 검색하려는 다른 기본 클래스에 속성을 추가하기 만하면됩니다. 이것은 인증 정보 (예 : 폼 인증)와 대조되는 인증 정보입니다.

+0

나는 세션 사용에 관한 울타리에있다. 어떤 사람들은 당신이 그들을 사용해서는 안된다고 말하고 다른 사람들은 그들이 사용하는 것이 좋습니다. – chobo

+0

각 사용자에 대해 사용 된 스토리지의 양에주의를 기울이면 잘 수행해야합니다. 쿠키는 옵션이지만 웹/모바일 브라우저 제한을 탐색합니다. –

1

또한 사용자 정의 ID를 구현할 수도 있습니다. 그들은 매우 쉽게 구현할 수 있으며 Identity에서 원하는 사용자 정보를 저장하고 Identity가 내려 놓은 쿠키에 저장하므로 매번 DB를 치지 않고 정보를 얻을 수 있습니다.

GenericIdentity에서 상속받은 클래스를 새로 작성하면됩니다.

당신은 쿠키에 들어 있기 때문에 거기에 얼마나 많은 정보를 넣을 지주의해야합니다. 그러나 여기에서 이야기하는 경우 일반적으로 사용자 관련 정보는 그렇게 크지 않습니다.

우리는 사용자에 대한 정보를 저장하기 위해 사용자 정의 ID를 사용하며 꽤 잘 작동합니다.

+0

정보를 설정하면 쿠키가 좋은 선택 일 수 있다고 생각합니다. – chobo

0

당신은 "윈도우 신원 재단"을 시도 할 수 있습니다. 나는 잠시 동안 내 프로젝트 중 하나에서 그것을 사용 해왔다. 기본적으로 사용자가 로그온 할 때 사용자를 설명하는 정보 문자열 인 "클레임"을 지정한다는 의미의 "클레임 기반 인증"을 허용합니다.

일단 사용자의 주장은 HttpContext.Current.User 필드에서 읽을 수 있습니다, 로그인. 역할 기반 인증 스키마와 완벽하게 통합되는 "역할"클레임을 사용할 수도 있습니다. 이는 사용자에게 "관리자"역할 클레임을 부여한 다음`if (User.IsInRole ("manager"))를 사용할 수 있음을 의미합니다.

추가 보너스로 WIF는 다른 응용 프로그램에서 로그인 화면을 매우 쉽게 다시 사용할 수있게합니다.

모두 매우 유연하지만 문서는 매우 열악합니다. StackOverflow의 "Windows Identity Foundation"에 대한 여러 가지 질문에 답했습니다.

0

우리는 과거에 이것을 꽤 많이했습니다. Thomas가 언급 한 것과 비슷하게 우리가 일반적으로 수행 한 작업은이를 수행하기 위해 Microsoft SQL Memberhsip 공급자를 기반으로하는 새 멤버쉽 공급자를 구현하는 것입니다. 기본 MembershipUser 클래스에서 상속 받고 사용자 객체에 대해 원하는 모든 사용자 정의 속성을 추가합니다. GetUser 구현에서 멤버 자격 공급자에 대해 읽은 데이터베이스를 구현해야하므로 필요한 추가 속성을 해당 데이터베이스에 통합 할 수 있습니다.

SQL 서버를 사용하는 경우 Microsoft는 2.0 코드를 릴리스합니다. Scott Gu의 블로그에서 자세한 정보를 얻을 수 있습니다. 처음부터 시작하려면

http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx

, 그들은 또한 MSDN에서 좋은 자원을 가지고있다. 당신이 당신의 공급자를 구현하면

http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx

http://msdn.microsoft.com/en-us/library/6tc47t75.aspx

, 당신은 다음 코드에서에 액세스하려면 현재 웹 컨텍스트의 항목 컬렉션에 회원 사용자를 추가 할 수 있습니다 . 기본 기본 사용자 클래스의 확장되지 않은 속성은 일반처럼 요청 스레드에서도 사용할 수 있습니다. 소스 코드의 2.0 버전의 마이크로 소프트의 출시와 함께

, 우리는 우리가 개혁에 대해 존재하는 몇 가지 우려를 완화 도움을 발견했다. 구현을 위해 고려해야 할 또 다른 사항은 시나리오를 기반으로하며 일부 코드는 무시할 수 있습니다. 예를 들어 이미 자격 증명 정보가있는 백엔드 시스템을 치는 경우 CreateUser 코드가됩니다.

0

인증 프로세스가 비교적 만족 스럽지만 세션/설정에 대한 다른 옵션을 탐색하려고합니다.

내 제안은 설정 (역할, 환경 설정 등)과 관련이 있습니다.)

내 의견으로는 UI에서 비즈니스 계층으로 DB 계층으로 전체 기술 스택을 트래버스해야하는 경우가 종종 있습니다. 세션 중에 변경 될 가능성이없는 데이터의 경우 많은 오버 헤드가 발생합니다. 잠재적으로 여러 가지 데이터 변환이 발생합니다 (DB (관계형 형식) -> ORM -> 웹 서비스 XML 직렬화 -> 웹 계층 직렬화 해제).

무거운 RDBMS 시스템이나 ASP.NET 캐싱/세션 모델에 의존하지 않는 세션 시스템을 고려해보십시오. 매우 성과가 있고 확장 성이 좋은 옵션이 있습니다.

Ayende Rahien (.NET 용)은 RavenDB을 사용할 수 있습니다. 주요 목표는 낮은 대기 시간, 스키마가없는 JSON 문서에 대한 고성능 액세스를 제공하는 것입니다.

이 솔루션을 사용하면 데이터에 대한 액세스가 매우 빠르도록 웹 계층에서 ravenDB를 설정할 수 있습니다. 처음으로 설정을 인증하고 검색 할 때이 세션 DB에 사용자 ID 및 설정 정보를 저장합니다. 그 후에 컨트롤러를로드 할 때마다 RDBMS로 되돌아 가지 않고 설정 데이터에 액세스 할 수 있습니다. 이 DB는 다른 웹 관련 데이터를 캐시하는 데 사용될 수도 있습니다.

보안의 경우 설정 데이터는 사용하는 방법에 관계없이 웹 계층으로 연결합니다. 이 솔루션은 다른 옵션 (암호화되지 않은 쿠키보다 안전함)보다 안전하거나 보안 수준이 낮습니다. 필요한 경우 세션 데이터를 암호화 할 수 있지만 오버 헤드가 다시 증가합니다.

백만 가지 옵션 중 하나만 고려하십시오.

행운을 빕니다,

우리는 당신이 결정을 알려주십시오!

패트릭.

+0

인증에 만족합니다. 세션을 사용할 필요없이 사용자 설정을 유지하기위한 asp.net mvc 프레임 워크에서 간단한 방법이나 기술이있을 것이라고 생각했습니다. 어떤 이유로 mvc에서 세션이 필요하지 않거나 이에 대한 몇 가지 다른 기술이 있다고 생각했습니다. – chobo