인증은 계층 구조에서 어디에 적합합니까?

일반적으로 서버 측 컨트롤러에 권한 부여 결정을 내립니다. 이것들은 최근 RESTful 끝점이지만, MVC 유형 아키텍처도 마찬가지라고 생각합니다. 논증을 위해 역할 기반 인증이라고 가정합니다. 보호 된 방법에 주석을 달거나 점검하고 필요한 경우 403을 반환합니다.

예를 들어, 권한 부여가 실제로 비즈니스 규칙이라는 점을 고려하면, 예를 들어 "관리자 만 X를 나열 할 수 있습니다"라고 생각합니다. 컨트롤러가 비즈니스 계층에 작업 수행을 요청하면 서비스 또는 비즈니스 계층은 컨트롤러에게 권한이 없음을 알려줍니다.

이것이 합리적인 접근입니까? 이것에 단점이 있습니까?

본질적 으로이 작업을 수행하기 위해 많은 정적 절차 코드 규칙을 보유하는 AuthorisationService를 가지고 싶지는 않지만 모든 액세스 논리를 한 곳에 보관하는 것이 좋습니다. 분리해야하는 교차 절단 문제입니까?

그래서 나는 누군가가 이것을했는지, 그들이 어떻게 깨끗한 방법으로 그것을 달성했는지 또는 내가 읽을 수있는 좋은 자료가 있는지 묻습니다. Java fwiw를 사용하고 있지만 언어에 구애받지 않는 질문입니다.

나는 여기에서 관련 질문을 확인했으며 그 질문에 대한 답은 매우 얇습니다. 예를 들면 다음과 같습니다. 도메인 모델의 유효성 검사 및 권한 부여 및 서비스 계층을 통해 MVC에이를 수행

나는 교차 보안 문제로 좋은 주장을 하는 스프링 보안 문서 를 읽고 있지만 그것이 "봄의 길"이고 더 넓은 관점을 원 할까 걱정됩니다. 또한 응용 프로그램을 특정 프레임 워크에 연결합니다.

사용자에게 권한이 부여 된 옵션 만 공개하는 것이 좋습니다.

이로 인해 승인이 교차 절단 문제가됩니다. "보기"는 표시 할 옵션 및 메뉴를 빌드하기 전에 사용자가 수행 할 수있는 작업을 알아야합니다.

백엔드는 보안 결정을 내릴 때 프런트 엔드를 신뢰해서는 안되므로 권한 자체를 확인해야합니다.

데이터에 따라 승인에 영향을 미치는 비즈니스 규칙이있을 수 있습니다 (예 : "5,000 달러 이상의 잔액을 가진 사용자 만 외화 송금을 호출 할 수 있음"또는 "본사에있는 사용자 만이 계정을 볼 수 있음"). 따라서 비즈니스 로직 내에 일부 권한 부여 로직이 필요합니다.

고려해야 할 기술 승인도 있습니다-로그를 볼 수있는 사람, 데이터베이스를 백업 / 복원 할 수있는 사람 등

따라서 결국 모든 구성 요소에는 특정 보안 및 / 또는 인증 요구 사항이있을 수 있으며 실제로이를 별도의 "인증 계층"으로 묶는 것은 거의 불가능합니다.

서비스 계층에 권한을 부여하는 것이 절대적으로 합리적인 방법이라고 생각합니다. 무단 활동 (특히 데이터 수정)을 수행하지 않도록 서비스를 보호해야합니다. 서비스 계층은 하나의 라이브러리에 상주 할 수 있으며 다른 프리젠 테이션 계층에서 사용할 수 있습니다 (동일한 서비스 계층을 사용하는 다른 UI 응용 프로그램이있을 수 있음). 또한 특정 프레젠테이션 레이어가 필요한 유효성 검사를 수행한다는 사실에 의존 할 수 없습니다. 나중에 서비스 계층을 별도의 프로세스로 이동하기로 결정하는 경우 (예 : SOA 접근 방식) 특히 중요합니다.

이제 이것을 "깨끗한 방법으로"달성하는 방법에 대해 설명합니다. 권한 부여 검사를 통해 비즈니스 로직을 버리는 아이디어가 마음에 들지 않기 때문에 측면 지향 프로그래밍 접근법의 특정 구현이 도움이 될 수 있습니다.

그리고 중요한 것은 매우 단순한 프로젝트에서 삶의 단순화를 위해 별도의 검증없이 살 수 있다는 점을 인정해야합니다. 그러나 "간단한 프로젝트"가 "복잡한 프로젝트"가되기 시작한 순간을 놓치지 않는 것이 중요합니다.

권한 부여 확인을 가능한 한 적게 내리는 것을 좋아합니다! (하지만 더 이상은 없습니다!)

"위"에있는 레이어에 대해 자동 인증 테스트를 자유롭게 작성할 수 있습니다. 또한 일부 규칙은 서비스 계층 (CanView / CanSerialize?)과 같은 상위 계층에서만 적용되거나 의미가있을 수 있습니다. 그러나 일반적으로 가장 안전한 인증 전략은 " 가장 건조한"전략 이라고 생각합니다 . 인증 규칙을 복잡하게하지 않고 최대한 "공통"또는 "공유"코드로 인증을 가능한 한 낮게 유지하십시오.

대안에 대해 생각하십시오. 권한 부여 규칙이 서비스 계층 에서만 테스트되고 시행 되어 불량 도메인 개체가 기분 좋은 서비스 개체의 의지에 구부러지는 경우 종종 여러 개체 및 여러 개체에서 각 개별 규칙을 두 번 이상 시행해야합니다 각 객체와 더 복잡한 코드에 배치합니다.

또한 분석 팀이 도메인 개체를 사용하여보고 서비스를 작성하기 위해 컨설팅 회사를 고용 할 때 해당 개발자를 신뢰할 필요는 없습니다! (또는 무엇이든. 어떤 이유로 든 동일한 서비스를 통해 추가 서비스를 구축하거나 호출 할 수 있습니다.) 비즈니스 규칙의 큰 책을 열지 않고 이러한 규칙을 다시 올바르게 적용 하기 를 희망 합니다 . 도메인에서 이미이를 알고 시행하기를 원합니다.