WebSphere Application Server에서 JACC 지원

WebSphere® Application Server는 JACC(Java™ Authorization Contract for Containers) 스펙을 지원하며 이를 사용하여 서드파티 보안 제공자는 Java EE(Java Platform, Enterprise Edition) 권한 부여를 처리할 수 있습니다.

JACC 스펙의 경우 컨테이너에 애플리케이션 서버와 제공자 보안의 일부 요구사항이 모두 필요합니다. 특히, 컨테이너는 보안 정책 정보를 제공자에게 애플리케이션 배치 중에 전파하고 모든 권한 부여 의사결정을 위해 제공자를 호출해야 합니다. 제공자는 정책 정보를 애플리케이션 배치 중에 저장소에 저장해야 합니다. 그러면 제공자는 이 정보를 사용하여 컨테이너에서 호출될 때 권한 부여 의사결정을 수행합니다.

JACC 액세스 의사결정

보안이 사용되고 엔터프라이즈 Bean이나 웹 자원에 액세스하는 경우, EJB(Enterprise JavaBeans) 컨테이너 또는 웹 컨테이너는 보안 런타임을 호출하여 액세스 허가 여부에 대한 권한 부여 의사결정을 수행합니다. 외부 제공자를 사용하는 경우 액세스 의사결정은 제공자에게 위임됩니다.

JACC(Java Authorization Contract for Containers) 스펙에 따라 적절한 권한 오브젝트가 작성되고 적절한 정책 컨텍스트 핸들러가 등록되며 적절한 정책 컨텍스트 ID(contextID)가 설정됩니다. 제공자가 액세스 의사결정을 수행하기 위해 구현하는 java.security.Policy 오브젝트 메소드가 호출됩니다.

다음 절에서는 제공자가 엔터프라이즈 Bean 및 웹 자원 모두에 대해 호출되는 방법에 대해 설명합니다.

엔터프라이즈 Bean에 대한 액세스 의사결정

보안이 사용되며 EJB 메소드에 액세스되면 EJB 컨테이너는 권한 검사를 보안 런타임에 위임합니다. JACC가 사용되는 경우 보안 런타임은 다음 프로세스를 사용하여 권한 검사를 수행합니다.
  1. Bean 이름, 메소드 이름, 인터페이스 이름, 메소드 서명을 사용하여 EJBMethodPermission 오브젝트를 작성합니다.
  2. PolicyContext.setContextID(contextID) 메소드를 사용하여 컨텍스트 ID를 작성하고 이를 스레드에 설정합니다.
  3. 주제(Subject) 정책 컨텍스트 핸들러를 사용하여 필수 정책 컨텍스트 핸들러를 등록합니다.
  4. 주제(Subject)의 프린시펄이 포함된 ProtectionDomain 오브젝트를 작성합니다. 프린시펄이 없는 경우 널이 프린시펄 이름으로 전달됩니다.
  5. 액세스 의사결정은 제공자로 구현되는 정책 오브젝트의 implies 메소드를 호출하여 JACC 제공자에 위임됩니다. EJBMethodPermission 및 ProtectionDomain 오브젝트가 이 메소드에 전달됩니다.
  6. isCallerInRole 액세스 검사도 동일한 프로세스를 사용하며 EJBRoleRefPermission 오브젝트가 EJBMethodPermission 오브젝트 대신 작성되는 점은 제외됩니다.

웹 자원에 대한 액세스 의사결정

보안이 사용되고 JACC 제공자를 사용하도록 구성되는 경우 서블릿이나 JSP(JavaServer Pages) 파일과 같은 웹 자원이 액세스되면 보안 런타임은 권한 부여 의사결정을 다음 프로세스에 따라 JACC 제공자에 위임합니다.
  1. WebResourcePermission 오브젝트는 URI가 지워졌는지 확인하기 위해 작성됩니다. 제공자가 Everyone 주제(Subject)를 사용하는 경우 여기에서 선택됩니다.
    1. WebResourcePermission 오브젝트는 액세스된 urlPattern 및 HTTP 메소드로 구성됩니다.
    2. 널 프린시펄 이름이 포함된 ProtectionDomain 오브젝트가 작성됩니다.
    3. JACC 제공자 Policy.implies 메소드는 권한 및 보호 도메인으로 호출됩니다. URI 액세스가 지워지거나 지정된 Everyone 주제(Subject)에 액세스가 부여되는 경우 제공자는 implies 메소드에 액세스를 허용합니다(true 리턴). 그런 다음 더 이상의 검사없이 액세스가 부여됩니다.
  2. 이전 단계에서 액세스가 부여되지 않으면 WebUserDataPermission 오브젝트가 작성되고 URI(Uniform Resource Identifier)가 금지, 제외 또는 HTTPS 프로토콜을 사용하여 경로 재지정되는지 확인하기 위해 사용됩니다.
    1. WebUserDataPermission 오브젝트는 액세스된 urlPattern, 호출된 HTTP 메소드, 요청의 전송 유형으로 구성됩니다. 요청이 HTTPS를 통해 전송되면 전송 유형은 CONFIDENTIAL로 설정되며 그렇지 않으면 널이 전달됩니다.
    2. 널 프린시펄 이름이 포함된 ProtectionDomain 오브젝트가 작성됩니다.
    3. JACC 제공자 Policy.implies 메소드는 권한 및 보호 도메인으로 호출됩니다. 요청이 HTTPS 프로토콜을 사용 중이고 implies 메소드가 false를 리턴하면 HTTP 403 오류가 리턴되어 제외 및 금지 권한을 내포합니다. 이런 경우, 더 이상의 검사는 수행되지 않습니다. 요청이 HTTPS 프로토콜을 사용하지 않고 implies가 false를 리턴하면 요청은 HTTPS를 통해 경로 재지정됩니다.
  3. 보안 런타임은 사용자 인증을 시도합니다. 인증 정보가 이미 있는 경우(예: LTPA 토큰) 사용됩니다. 그렇지 않으면 사용자의 신임 정보를 입력해야 합니다.
  4. 사용자 신임 정보가 유효성 검증된 후 최종 권한 검사가 수행되어 사용자에게 URI에 대한 액세스 권한이 부여되었는지 확인합니다.
    1. 단계 1에서 WebResourcePermission 오브젝트가 작성됩니다. ProtectionDomain 오브젝트는 이제 URI 액세스를 시도하는 프린시펄을 포함합니다. 주제(Subject) 정책 컨텍스트 핸들러도 사용자 정보를 포함하며 이는 액세스 검사에 사용 가능합니다.
    2. 제공자 implies 메소드가 권한 오브젝트 및 이전에 작성된 ProtectionDomain 오브젝트를 사용하여 호출됩니다. 사용자에게 자원 액세스 권한이 부여되면 implies 메소드는 true를 리턴합니다. 사용자에게 액세스가 부여되지 않으면 implies 메소드는 false를 리턴합니다.
이전에 나열된 순서가 나중에 변경되더라도(예를 들어 성능 향상을 위해) 종료 결과는 동일합니다. 예를 들어, 자원이 금지 또는 제외되는 경우, 결과는 자원에 액세스할 수 없습니다.

이 액세스 권한에 대한 자세한 정보는 JSR-000115 Java Authorization Contract for Containers(버전 1.5 유지보수 릴리스)를 참조하십시오.

액세스 의사결정에 대한 주제(Subject)의 정보 사용

제공자가 액세스 의사결정에 대해 WebSphere Application Server에서 생성된 주제(Subject)에 의존하는 경우 제공자는 주제(Subject)에서 공개 신임 정보를 조회하여 WSCredential 신임 정보를 확보할 수 있습니다. WSCredential API는 이름 및 사용자가 속하는 그룹을 포함하여 사용자에 대한 정보 확보에 사용됩니다. 이 정보는 액세스 의사결정 수행에 사용됩니다.

제공자가 필요한 정보를 주제(Subject)에 추가하면 WebSphere Application Server는 정보를 사용하여 액세스 의사결정을 내립니다. 제공하는 신뢰 연관 인터페이스 기능을 사용하거나 애플리케이션 서버에 플러그 가능한 로그인 모듈을 사용하여 정보를 추가할 수도 있습니다.

보안 속성 전파 절에는 WebSphere Application Server에 필요한 정보를 주제(Subject)에 추가하는 방법에 대한 추가 문서가 있습니다. 자세한 정보는 Application Server 간에 보안 속성 전파의 내용을 참조하십시오.

JACC에서 동적 모듈 업데이트

WebSphere Application Server는 특정 조건에서 웹 모듈에 대한 동적 업데이트를 지원합니다. 애플리케이션에 대해 웹 모듈이 업데이트, 삭제 또는 추가되는 경우 적절하게 해당 모듈만 중지되고 시작됩니다. 애플리케이션의 다른 기본 모듈은 영향을 받지 않으며 애플리케이션 자체는 중지되고 다시 시작되지 않습니다.

기본 권한 부여 엔진을 사용하는 경우 모든 보안 정책이 웹 모듈에서 수정되고 애플리케이션은 중지된 후에 다시 시작됩니다. JACC(Java Authorization Contract for Containers) 기반의 권한 부여를 사용하는 경우 동작은 제공자가 지원하는 기능에 따라 다릅니다. 제공자가 웹 모듈에 대한 동적 변경을 처리할 수 있는 경우 웹 모듈만 영향을 받습니다. 그렇지 않으면 전체 애플리케이션이 웹 모듈의 새 변경사항이 적용되도록 중지되고 다시 시작됩니다.

제공자는 동적 모듈 업데이트 지원 옵션을 JACC 구성 모델에 구성하여 동적 업데이트를 지원하는지 표시할 수 있습니다(자세한 정보는 Tivoli Access Manager를 사용하여 Java EE 자원에 대한 액세스 권한 부여의 내용 참조). 이 옵션은 관리 콘솔이나 스크립팅을 사용하여 사용하거나 사용하지 않을 수 있습니다. 대부분의 제공자가 정책 정보를 해당 외부 저장소에 저장하며 이를 통해 동적 업데이트를 지원하는 것이 가능합니다. 이 옵션은 대부분의 제공자에 대해 기본적으로 사용되어야 합니다.

동적 모듈 업데이트 지원 옵션이 사용되면 보안 역할을 포함하는 웹 모듈이 동적으로 추가, 수정 또는 삭제되면 특정 웹 모듈만 영향을 받고 다시 시작됩니다. 옵션을 사용하지 않으면 전체 애플리케이션이 다시 시작됩니다. 동적 업데이트가 수행되는 경우, 영향을 받는 모듈의 보안 정책 정보가 제공자로 전파됩니다. 보안 정책 전파에 대한 자세한 정보는 JACC 정책 전파의 내용을 참조하십시오.

JACC 제공자 초기화

JACC(Java Authorization Contract for Containers) 제공자에서 예를 들어 클라이언트 코드가 서버 코드와 통신하기 위해서와 같은 이유로 서버 시작 중에 초기화가 필요한 경우, 제공자는 com.ibm.wsspi.security.authorization.InitializeJACCProvider 인터페이스를 구현할 수 있습니다. 자세한 정보는 JACC를 지원하는 인터페이스의 내용을 참조하십시오.

이 인터페이스가 구현되면 서버 시작 중에 호출됩니다. JACC 구성 모델의 모든 사용자 정의 특성은 이 구현의 초기화 메소드에 전파됩니다. 사용자 정의 특성은 관리 콘솔이나 스크립팅을 사용하여 입력 가능합니다.

서버 시스템 종료 중에 정리 메소드는 제공자에게 필요한 모든 정리 작업에 대해 호출됩니다. 이 인터페이스 구현은 전적으로 선택사항으로 제공자가 서버 시작 중에 초기화를 필요로 하는 경우에만 사용됩니다.

혼합 노드 환경 및 JACC

JACC(Java Authorization Contract for Containers)를 사용한 권한 부여는 WebSphere Application Server 버전 6의 새로운 기능이며, 이는 WebSphere Application Server 버전 9에서 최신 JACC 스펙 버전 1.5로 개선되었습니다.

JACC 구성은 셀 레벨에서 설정되며 해당 셀의 모든 노드 및 서버에 적용됩니다.

JACC 기반의 권한 부여 버전 1.5 기능을 사용하려면 셀에 버전 9 이상 노드만 포함되어야 합니다. 이 제한사항은 버전 9 이상 셀에 버전 8.5.x 이하 노드가 포함된 혼합 노드 환경이 셀의 최하위 지원 버전을 기반으로 하는 JACC 기반 권한 부여에 대해 지원됨을 의미합니다. 이 경우에 이는 JACC 기반의 권한 부여 버전 1.4입니다.


주제 유형을 표시하는 아이콘 개념 주제



시간소인 아이콘 마지막 업데이트 날짜: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_jaccsupport
파일 이름:csec_jaccsupport.html