DDD 구현 : 사용자 및 권한

도메인 기반 디자인의 원칙을 파악하려는 작은 응용 프로그램을 만들고 있습니다. 성공하면 더 큰 프로젝트의 파일럿이 될 수 있습니다. Vaughn Vernon의 "도메인 기반 디자인 구현"책을 따라 가면서 유사하고 간단한 토론 포럼을 구현하려고합니다. 또한 github에서 IDDD 샘플을 확인했습니다. 본인의 사례에 대한 신원 및 액세스를 채택하는 데 어려움이 있습니다. 몇 가지 배경 정보를 제공하겠습니다.

• 필자는 사용자와 권한 논리를 분리하는 이유를 뒷받침합니다. 지원 도메인이며 다른 경계 컨텍스트입니다.
• 핵심 도메인에는 사용자, 작성자, 중재자 등이 없습니다. 서비스를 사용하여 ID 및 액세스 컨텍스트에 도달 한 후 수신 된 사용자 오브젝트를 중재자로 변환하여 작성됩니다.

• 도메인 작업은 관련 역할을 매개 변수로 사용하여 호출됩니다. 예 :

  ModeratePost( ..., moderator);

• 도메인 객체의 메서드는 지정된 중재자 인스턴스가 null이 아닌지 확인합니다 (ID 및 액세스 컨텍스트에서 요청한 사용자에게 중재자 역할이없는 경우 중재자 인스턴스는 null 임).

• 어떤 경우에는 게시물을 변경하기 전에 추가 검사를 수행합니다.

  if (forum.IsModeratedby(moderator))

내 질문은 :

• 후자의 경우 보안 문제가 핵심 영역에 다시 혼합되지 않습니까? 이전에는이 ​​책에 "제목을 게시 할 수있는 사람 또는 허용되는 조건하에있는 사람이 있습니다. 포럼은 저자가 지금 그 일을하고 있음을 알아야합니다".

• 이 책의 역할 기반 구현은 매우 간단합니다. 중재자가 핵심 도메인 인 경우 현재 userId를 필요한 경우 중재자 인스턴스 또는 작성자로 변환하려고합니다. 서비스는 적절한 인스턴스로 응답하거나 사용자에게 필요한 역할이 없으면 널입니다. 그러나이를보다 복잡한 보안 모델에 어떻게 적용 할 수 있는지 알 수 없습니다. 현재 파일럿하려는 프로젝트에는 그룹, ACL 등이있는 다소 복잡한 모델이 있습니다.

"소유자 나 편집자 만 게시물을 편집해야합니다"와 같이 매우 복잡하지 않은 규칙이 있더라도이 방법은 고장 나거나 적어도 그것을 구현하는 올바른 방법이 보이지 않습니다.

OwnerOrEditor 인스턴스에 대한 Identity 및 Access 컨텍스트를 요청하는 것이 옳지 않다고 생각하며 핵심 도메인에서 점점 더 많은 보안 관련 클래스로 끝날 것입니다. 또한 userId뿐만 아니라 보호 된 리소스의 식별자 (게시물, 포럼 등의 ID)를 보안 컨텍스트에 전달해야합니다.이 컨텍스트는 신경 쓰지 않아야합니다 (정확합니까? )

핵심 도메인에 대한 권한을 가져 와서 도메인 객체의 방법이나 서비스에서 확인함으로써 보안 문제를 도메인과 혼합하는 것입니다.

보안 및 권한이 핵심 도메인 자체가 아닌 한 이러한 권한 관련 사항이 핵심 도메인의 일부가되어서는 안된다는 것을 읽었습니다. 위에 주어진 것과 같은 간단한 규칙이 보안을 핵심 도메인의 일부로 만드는 것을 정당화합니까?

실제 액세스 제어 규칙과 액세스 제어에 경계를 두는 도메인 불변량을 구분하기가 어려운 경우가 있습니다.

특히, 특정 도메인 논리 과정에서 멀리 떨어진 데이터에만 의존하는 규칙은 도메인에서 쉽게 추출 할 수 없습니다. 일반적으로 액세스 제어는 도메인 작업이 수행되기 전이나 후에 호출되지만 호출 중에는 수행되지 않습니다.

본 버논의 assert (forum.IsModeratedBy(moderator))사례는 아마도 도메인 외부에 있었을 지 모르지만 항상 실현 가능한 것은 아닙니다.

userId뿐만 아니라 보호 된 리소스의 식별자 (게시물, 포럼 등의 ID)를 보안 컨텍스트에 전달해야합니다.이 컨텍스트는 신경 쓰지 않아야합니다 (정확합니까?)

Security BC가 있고 그 논리를 처리하기를 원한다면 포럼이 무엇인지 자세히 알아야 할 필요는 없지만 다음과 같습니다.

• "중재자"와 같은 개념에 대한 지식을 보유하고 이에 따라 액세스 권한을 부여하거나 거부 할 수 있습니다.
• 핵심 도메인 이벤트에 등록하고 Security BC가 저장하고 사용할 수있는 간단한 (자원, AuthorizedUsers) 키 값 쌍으로 변환하는 어댑터 논리를 가질 수 있습니다.

인증 및 권한 부여는 DDD에 대한 나쁜 예입니다.

회사에서 보안 제품을 만들지 않는 한이 두 가지가 도메인의 일부가 아닙니다.

비즈니스 또는 도메인 요구 사항은 "역할 기반 인증이 필요합니다"여야합니다.

그런 다음 도메인 기능을 호출하기 전에 역할을 확인하십시오.

당신은 '나는 내 자신의 게시물을 편집 할 수 있지만 다른 사람이'당신의 도메인에 편집 기능을 분리되도록 복잡한 요구 사항이 어디 EditOwnPost()과를 EditOthersPost()그래서 당신은 역할 매핑에 대한 간단한 기능을 가지고

당신은 또한 다음과 같은 도메인 개체로 기능을 분리 할 수 Poster.EditPost()및 Moderator.EditPost()당신의 선택은 당신의 방법은 도메인 서비스 또는 도메인 개체에 있는지 여부에 따라 달라질 수 있지만이 좀 더 OOP 방식이다.

그러나 역할 매핑이 도메인 외부에서 발생하는 코드를 분리하도록 선택합니다. 예를 들어 webapi 컨트롤러가있는 경우 :

PostController : ApiController
{
    [Authorize(Roles = "User")]
    public void EditOwnPost(string postId, string newContent)
    {
        this.postDomainService.EditOwnPost(postId, string newContent);
    }

    [Authorize(Roles = "Moderator")]
    public void EditOtherPost(string postId, string newContent)
    {
        this.postDomainService.EditOtherPost(postId, string newContent);
    }
}

역할 맵핑이 호스팅 계층에서 수행 되더라도 자신 또는 다른 게시물을 편집하는 구성의 복잡한 논리 는 도메인의 일부입니다.

도메인은 조치의 차이점을 인식하지만 보안 요구 사항은 단순히 "기능이 역할에 의해 제한 될 수 있음" 입니다.

이것은 아마도 도메인 객체 분리와 함께 더 명확하지만 본질적으로 서비스 메소드를 호출하는 메소드 대신 객체를 구성하는 메소드를 확인하고 있습니다. 도메인의 일부로 여전히 음성을 보내려면 '중재자 만 중재자 개체를 구성 할 수 있습니다.'