ASP 닷넷 MVC 코어 사용자는

Question

여기에 모든 페이지를 탐색 Active Directory에서로드 사용자 데이터 내 개발 환경 :

• 인트라넷 웹 사이트
• Active Directory의 인증/권한 부여
• ASP 닷넷 코어

사용자가 응용 프로그램의 모든 페이지를 처음 입력 할 때 Active Directory 특성에 저장된 데이터를 가져 오려고합니다. 모든 사용자 권한과 사용 권한, employeeid, studentid 등은 AD 특성 값이 및 인 보안 그룹에 저장됩니다. 일부 속성은 웹 사이트에도 표시되어야합니다.

의 내 웹 사이트는 다음 URL을 가지고 있다고 가정 해 봅시다

...

• http://mysite/Home/Index
• http://mysite/Student/Index
• http://mysite/Student/MyJobs
• http://mysite/Staff/Applications

등 ....

모든 사용자는 다른 인트라넷 포털에서 자유롭게 웹 사이트의 일부 영역/URL을 방문 할 수 있으며 해당 기준을 충족하기 위해 코드를 어디에 작성해야하는지 모르겠습니다. 문제는 응용 프로그램에 http://mysite/Login 또는 인증 등의 특정 진입 점이 없다는 것입니다.있는 경우 해당 단일 진입 점에서 AD의 모든 사용자 세부 정보 및 권한을로드 할 수 있습니다.

MVC5 시대에는 Custom Global Authorize Attribute를 사용하고 BaseController에 올려 놓으면 다른 모든 컨트롤러에서 상속되어 AD 데이터를로드합니다. 첫 번째 히트에서 AD의 데이터를 Session에 넣고 뷰에 표시하고 컨트롤러에서 사용하려면 정적 클래스를 사용합니다. 그러나 MVC Core에서 몇 가지 연구를 해보니, 구식이라고 나와서, 사용자 정의 권한 부여 대신 권한 부여 정책을 사용해야합니다.

Active Directory에서 데이터를 가져 오는 작업은 이미 이전 웹 서비스를 사용하여 이루어 졌으므로 AD를 아직 지원하지 않는 .Net 코어에 대해서는 걱정할 필요가 없습니다.

정책에 대한 자습서를 살펴본 결과 클레임 및 맞춤형 사용자 관리자에 대해 알아 보았습니다. Active Directory에서 전체 사용자의 세션 동안 지속되는 개체 (Scoped Object DI)로 데이터를로드하는 데 사용해야 할 작업을 결정할 수 없습니다. 주장 예 속성에

나는 ...

var claims = new List<Claim>(); 
claims.Add(new Claim("UserName", "John.Smith", ClaimValueTypes.String, Issuer)); 
claims.Add(new Claim("RefNo", "02343001", ClaimValueTypes.String, Issuer)); 
claims.Add(new Claim("Email", "MyEmail@email.com", ClaimValueTypes.String, Issuer)); 

을 데이터를로드해야 아니면 내가 SignInManager 및 IdentityUser 사용자 정의 작성해야? 예 ...

public class ApplicationUser : IdentityUser 
{ 
    public string RefNo { get; set; } 
    public string Email { get; set; } 
} 

내가 AD 및로드 데이터를 확인하려면 코드를 넣을 수 있습니다 어디 있습니까? 그리고 세션 데이터를 사용하는 대신 해당 소유권 주장 데이터에 데이터를 저장해야합니까?

제발 저에게 조언 해 주시겠습니까? 내가 무엇이든 놓치고 제 아이디어가 효과가 없다면 비판 해주십시오.

Answer 1

아직 System.DirectoryServices가 없다는 것이 맞습니다 (백 로그에 있습니다. 약속드립니다). 이렇게해야 할 일이 몇 군데 있습니다.

이미 통합 인증을 사용중인 경우 IsInRole()을 호출 할 때 해결되는 그룹 구성원 자격에 대한 SID가 있으므로 기본 인증 문제를 해결하기 위해 자격 기반이 아닌 역할 기반 멤버 자격을 사용할 수 있습니다.

그러나 양식 기반 메커니즘을 지원하려면 the cookie middleware, raw을 사용하여 최소한 간단한 로그인을 제공하고 웹 서비스를 호출하여 로그인을 확인해야합니다. 컨트롤러 코드에서 API를 쿼리하고 ID 쿠키를 작성할 수 있습니다. 이 쿠키는 자동으로 암호화되고 서명되므로 변조 할 수 없습니다.

역할과 특성을 원할 때 문제가 발생합니다. 쿠키 경로를 따라 가면 신분을 쿠키로 작성하기 전에 그 모든 것을 소유권 주장에 넣으려는 유혹을받을 수 있습니다. 쿠키가 너무 많지 않으면 쿠키가 최대 크기 (브라우저에 따라 다르지만 일반적으로 4K 미만)입니다. 청크 쿠키를 사용할 수 있지만 여기에는 성능에 영향이 있습니다. 대신 참조 쿠키를 사용할 수 있습니다. 여기서 실제 완전히 채워진 ID가 저장되는 다른 저장소 (세션, redis 또는 기타 항목)에 대한 참조를 넣을 수 있습니다.

그런 다음 the claims transformation middleware에서 참조를 풀어 상점에 가서 ID를 다시 수 있습니다.

솔직히이 모든 것을 ASP.NET ID로 병합하지 마십시오. 이는 응용 프로그램에서 사용자 정보를 얻는 유일한 소스이며 사용자의 경우 사실이 아님을 의미합니다. 귀하의 유일한 출처는 광고이어야합니다.

코어에도 Novell's ldap library 포트가 있습니다.이 포트는 웹 서비스 접근을 피하려는 경우 DirectoryServices에 적합해야합니다.