JAAS 인증 확인을 Shiro에 위임하려면 어떻게해야합니까?

JAAS 인증 확인을 Shiro에 위임하려면 어떻게해야합니까?

---

개체 기반 인증 및 권한 부여가 필요한 서버 측 응용 프로그램을 개발 중입니다. 나는 Shiro의 단순함을 좋아하지만 JAAS와 호환되기 위해 Apache Shiro를 기본 메커니즘으로 사용하는 LoginModule을 작성했습니다.

하지만 내 문제는 JAAS 인증 검사를 Shiro에 위임하는 방법을 찾을 수 없다는 것입니다. 이것을 어떻게 달성 할 수 있습니까?

---

참고 : 대답은 표준 보안 프레임 워크를 통해 외부 권한 부여 시스템이 JVM과 통합되는 일반적인 경우를 다룹니다. 나는 어느 쪽에도 익숙하지 않기 때문에 Shiro 또는 JMX 특정이 아닙니다.

---

개념적으로는 권한 부여 쿼리 ( "엔티티 X가 Y를 수행 할 수 있습니까?" )가 평가 되는 기능인 정책 결정 지점 (PDP) 뒤에있는 것으로 보입니다 . JDK는 다음 중 몇 가지를 제공합니다.

1. 효과적인 SecurityManager, 특히 checkXXX방법 그룹.
2. ProtectionDomain클래스, 특히 그 implies(Permission)방법에 관한 것이다.
3. 주요 implies(ProtectionDomain, Permission)효과적인 방법 Policy.
4. 둘째로는 implies방법 CodeSource, PermissionCollection, Permission,와 Principal.

개념적 PDP의 기능을 오름차순으로 사용자 정의하기 위해 앞서 언급 한 방법 중 하나를 재정의 할 수 있습니다. JAAS는 (그 이름이 암시하는 것과는 달리) 실제로 자체 PDP를 가져 오지 않았다는 점에 유의해야합니다. 오히려 도메인과 정책이 코드 원본의 원래 신뢰 요인에 추가하여 주체 기반 쿼리를 지원 하는 수단 을 제공했습니다 . 따라서, 내 눈에, "JAAS 호환"남아있는 귀하의 요구 사항은 기본적으로 일명 (원본 플러스 JAAS) 자바 SE 권한 부여 모델을 사용하고자로 변환 내가 당신이 원하는 어떤 것으로 의심 샌드 박스. Shiro와 같은 프레임 워크는 표준 모델이 너무 낮거나 성능 집약적 인 것으로 간주 될 때 사용되는 경향이 있습니다. 즉, 권한 부여 논리가특정 신뢰 요인 집합에 대해 모든 단일 스택 프레임을 평가할 필요는 없습니다. 이러한 요인은 그렇지 않은 경우보다 상황에 민감하지 않기 때문입니다. 내 가정의 타당성에 따라 세 가지 주요 사례가 검토됩니다.

1. 권한은 AccessControlContext독립적입니다. SNAA (Shiro-native Authorization Attribute)는 무엇이든 전체 스레드에 적용됩니다. 코드 출처는 관련이 없습니다.
2. 코드 출처가 중요하므로 샌드 박스를 사용해야합니다. SNAA는 여전히 AccessControlContext독립적입니다.
3. 코드의 기원과 SNAAs은 모두 적절하고 있습니다 AccessControlContext- 의존 .

---

1. SNAA만을 기반으로 한 권한

1. 적합하다고 판단되는 방식으로 인증을 관리하십시오. javax.security.auth인증을 위해 JAAS의 SPI 를 계속 사용 Subject하려면 인증 결과로 표준 을 설정하는 것을 잊어 버리십시오 . 대신 Shiro 고유의 것을 스레드 로컬 스토리지에 직접 연결하십시오. 이렇게하면 SNAA에보다 편리하게 액세스 할 수 있으며 검색을 위해 사용할 필요가 없으며 AccessControlContext잠재적 인 성능 저하 를 피할 수 있습니다.

2. Subclass SecurityManager, 최소한 두 개의 checkPermission메서드를 재정 의하여

   1. 필요한 경우, Permission논쟁을 Shiro의 PDP (SPDP)가 이해하기 전에
   2. 스레드 로컬 SNAA 및 권한을 사용하여 SPDP에 위임 (그리고 SecurityExceptionSPDP 신호 액세스 거부시 a 를 던짐 ).

   보안 컨텍스트 수신 오버로드는 해당 인수를 무시할 수 있습니다. 애플리케이션 초기화시 System::setSecurityManager구현을 인스턴스화하고 설치 ( )합니다.

---

2. 코드 출처와 문맥에 민감하지 않은 SNAA를 결합하는 하이브리드 인증

1. 적절하다고 판단되는 방식으로 인증을 관리하십시오. 다시 한 번 Shiro 특정 Subject을 스레드 자체와 연관시킵니다 .
2. Subclass SecurityManager, 적어도 두 checkPermission메서드를 재정의 합니다. 이번에는 SPDP 및 / 또는 재정의 된 구현 ( checkPermission그에 따라 현재 또는 제공된 액세스 제어 컨텍스트를 호출 함) 모두에 위임합니다 . 주어진 허가에 대해 어떤 것 (들)과 어떤 순서로 상담해야하는지는 물론 구현에 따라 다릅니다. 둘 다 호출 될 때 SPDP는 액세스 제어 컨텍스트보다 더 빠르게 응답 할 수 있으므로 먼저 쿼리해야합니다.
3. SPDP가 특정 위치 및 / 또는 코드 서명자 집합에서 발생하는 코드에 부여 된 권한 평가를 추가로 처리하려면 위와 같이 도메인의 일부 이해하기 쉬운 표현을 전달 하도록 Policy구현 하여 하위 클래스를 만들어야 합니다 (일반적으로 에만 ) 및 권한 인수 -하지만 논리적으로 하지 SNAAs - SPDP합니다. 구현은 한 번에 액세스 제어 컨텍스트마다 도메인 당 한 번씩 호출되므로 가능한 한 효율적이어야합니다 . 구현을 인스턴스화하고 설치 ( )합니다.implies(ProtectionDomain, Permission)SecurityManager::checkPermissionCodeSourcecheckPermissionPolicy::setPolicy

---

3. 코드 원본과 SNAA를 결합하는 하이브리드 권한 부여 (둘 다 상황에 맞는)

1. 적합하다고 판단되는 방식으로 인증을 관리하십시오. 불행히도 주제 처리 부분은 ThreadLocal이 경우 를 만드는 것만 큼 사소하지 않습니다 .
2. 두 번째 경우에 개별적으로 설명 된대로 및 Policy의 결합 된 임무를 수행 하는 을 서브 클래스, 인스턴스화 및 설치합니다 .SecurityManager::checkPermissionPolicy::implies
3. 표준 SecurityManager.
4. ProtectionDomainSNAA를 저장하고 노출 할 수 있는 하위 클래스를 만듭니다 .

5. 저자 ¹ a DomainCombinerthat

   1. SNAA로 구성됩니다.

   2. combine(ProtectionDomain[], ProtectionDomain[])그런 구현

      1. 첫 번째 ( "현재"컨텍스트) 배열 인수의 도메인을 사용자 정의 구현의 동등한 인스턴스로 대체합니다.
      2. 그런 다음 두 번째 ( "할당 된"또는 "상속 된"컨텍스트) 인수의 인수 (있는 경우)를 이전 그대로에 추가합니다. 그리고 마지막으로
      3. 연결을 반환합니다.

   와 같이 Policy::implies구현은 getContext및 checkPermission AccessController메소드가 있을 때마다 호출되므로 효율적이어야합니다 (예 : 중복 제거) .

6. 인증이 성공 AccessControlContext하면 사용자 지정 인스턴스와 함께 현재 항목을 래핑 하는 새 항목 을 만들고 DomainCombiner차례로 SNAA를 래핑합니다. AccessController::doPrivilegedWithCombiner호출 "내에서"해당 지점을 넘어서 실행될 코드를 래핑 하고 대체 액세스 제어 컨텍스트도 함께 전달합니다.

---

_{1    Instead of using custom domains and your own combiner implementation, there is also the seemingly simpler alternative of translating the SNAAs into Principals and, using the standard SubjectDomainCombiner, binding them to the current AccessControlContext's domains (as above, or simply via Subject::doAs). Whether this approach reduces the policy's efficiency depends primarily on the call stack's depth (how many distinct domains the access control context comprises). Eventually the caching optimizations you thought you could avoid implementing as part of the domain combiner will hit you back when authoring the policy, so this is essentially a design decision you will have to make at that point.}

참고URL : https://stackoverflow.com/questions/5736077/how-can-i-delegate-jaas-authorization-checks-to-shiro