보안 어노테이션
어노테이션은 JSR-175 권장사항에 따른 강력한 프로그래밍 메커니즘입니다. 어노테이션은 소스 코드와 구성 파일을 자동으로 생성하면서, 지원되는 보안 동작을 포함하는 표준 방법입니다.
시나리오 | 규칙 |
---|---|
배치 디스크립터의 보안 메타데이터 전용 | 병합이 필요하지 않습니다. 배치 디스크립터의 보안 메타데이터가 전파됩니다. |
어노테이션의 보안 메타데이터 전용 | 병합이 필요하지 않습니다. 어노테이션으로 정의된 보안 메타데이터가 전파됩니다. |
배치 디스크립터 및 어노테이션의 보안 메타데이터 | 배치 디스크립터와 어노테이션의 메타데이터가 병합됩니다. 어노테이션의 메타데이터는 배치 디스크립터의 동일한 데이터 유형으로 대체됩니다. |
- @DeclareRoles(Servlet 2.5 이상 및 EJB 3)
MergeAction 구현은 DeclareRoles 어노테이션이 있는 모든 클래스를 찾습니다. 지정된 각 역할 이름의 어노테이션이 있는 각 클래스에서, 배치 디스크립터에 나열된 보안 역할에 어노테이션이 있는 역할 이름이 있는 SecurityRole이 없는 경우, 새 SecurityRole을 작성하여 보안 역할 목록에 추가합니다.
- @RunAs(Servlet 2.5 이상 및 EJB 3)
MergeAction 구현은 RunAs 어노테이션이 있는 모든 클래스를 찾습니다. 어노테이션이 있는 각 클래스의 경우, 제공된 클래스와 연관된 서블릿이나 EJB(Enterprise Java Bean)를 찾습니다. 그런 다음, 해당 서블릿이나 EJB의 배치 디스크립터에 실행 도구 요소가 정의되어 있는지 판별합니다. 실행 도구 요소가 없으면 새 실행 도구 요소를 작성하여 배치 디스크립터에 추가합니다. 실행 도구 요소가 있는 경우에는 새 항목을 작성하지 않고 이 실행 도구 요소를 사용합니다. RunAs 어노테이션에 사용된 역할 이름을 배치 디스크립터에서 정의해야 합니다.
- @DenyAll(EJB 3 전용)
MergeAction 구현은 DenyAll 어노테이션이 있는 모든 메소드를 찾습니다. 어노테이션이 있는 각 메소드의 경우, 제외된 메소드의 배치 디스크립터 목록에 해당 메소드가 포함되어 있지 않고 배치 디스크립터에 MethodPermission이 없으면 새 MethodElement를 작성하여 배치 디스크립터에서 제외된 메소드 목록에 추가합니다.
- @PermitAll(EJB 3 전용)
MergeAction 구현은 PermitAll 어노테이션이 있는 모든 클래스와 메소드를 찾습니다. 어노테이션이 있는 각 클래스의 경우, 제공된 클래스와 연관된 EJB(Enterprise Java Bean)를 찾습니다. 그런 다음, 이 EJB의 배치 디스크립터에 정의된 모든 MethodPermission 목록에서 MethodElement의 서브세트를 검색합니다. 와일드카드 메소드 이름(“*”)이 있는 MethodElement를 찾을 수 없고 제외된 메소드 목록이나 보안 역할이 있는 MethodElements 목록에 와일드카드 메소드가 없으면 새 MethodPermission과 새 MethodElement를 작성합니다. 새 MethodPermission을 선택 취소로 표시하고 배치 디스크립터의 MethodPermission 목록에 추가합니다. 새 MethodElement는 새로 작성된 선택 취소된 MethodPermission의 MethodElement 목록에 추가됩니다. 어노테이션이 있는 모든 메소드에 대해 이와 유사한 조치를 수행합니다. 와일드 카드 MethodElement 대신, 메소드 서명은 어노테이션이 있는 메소드의 서명과 완전히 일치해야 합니다.
- @RolesAllowed(EJB 3 전용)
MergeAction 구현은 RolesAllowed 어노테이션이 있는 모든 클래스와 메소드를 찾습니다. 어노테이션이 있는 각 클래스의 경우, 제공된 클래스와 연관된 EJB를 찾습니다. 그런 다음, 이 EJB의 배치 디스크립터에 정의된 모든 MethodPermission 목록에서 MethodElement의 서브세트를 찾습니다. 와일드카드 메소드 이름(“*”)이 있는 MethodElement를 찾을 수 없고 제외된 메소드 목록이나 선택 취소된 MethodElements 목록에 와일드카드 메소드가 없는 경우, 새 MethodPermission 및 MethodElement를 작성합니다. 이 EJB의 MethodPermission이 해당 어노테이션에서 찾은 항목과 동일한 역할로 존재하면 새 항목을 작성하지 않고 이 MethodPermission을 사용합니다. 어노테이션에 지정된 각 역할 이름에 대해, 새 SecurityRole을 작성하여 MethodPermission의 SecurityRole 목록에 추가하고 MethodPermission을 새로 작성한 경우에는 배치 디스크립터의 MethodPermission 목록에 추가합니다. 작성된 새 MethodElement는 MethodPermission의 MethodElement 목록에 추가됩니다. 어노테이션이 있는 모든 메소드에 대해 이와 유사한 조치를 수행합니다. 와일드 카드 MethodElement 대신, 메소드 서명은 어노테이션이 있는 메소드의 서명과 완전히 일치해야 합니다. 또한 어노테이션에 지정된 각 역할 이름의 경우, 보안 역할의 배치 디스크립터 목록에 어노테이션이 있는 역할 이름의 SecurityRole이 없으면 새 SecurityRole을 작성하여 보안 역할 목록에 추가합니다.
- @ServletSecurity(Servlet 3.0 전용)참고: Servlet 3.0의 ServletSecurity 어노테이션에 대한 지원은 이번 WebSphere® Application Server 릴리스의 새로운 기능입니다.
애플리케이션을 배치하면 ServletSecurity MergeAction 구현은 ServletSecurity 어노테이션이 있는 모든 서블릿을 찾습니다. 어노테이션이 있는 각 서블릿의 경우, WebServlet 어노테이션에서 제공된 클래스 기반과 연관된 서블릿을 찾습니다. ServletSecurity 어노테이션의 RolesAllowed를 배치 디스크립터에서 찾을 수 없으면 해당 역할에 대한 role-name 속성을 배치 디스크립터에서 작성합니다.
애플리케이션 시작 시, WebContainer는 RunAs, declareRoles 및 ServletSecurity 어노테이션이 있는 모든 서블릿을 조사하여 ServletRegistration 어노테이션의 setServletSecurity() 메소드에서 해당 어노테이션을 설정합니다. WebContainer는 URL 패턴 및 보안 제한조건이 있는 모든 ServletRegistration 어노테이션을 조사하도록 보안 컴포넌트에 알립니다. 그러면 보안 컴포넌트는 배치 디스크립터에 URL 패턴이 정의되어 있는지 판별합니다. 배치 디스크립터에 URL 패턴이 정의되어 있지 않으면 URL 패턴에서 보안 제한조건과 RunAs 역할을 작성하여 사용합니다. 배치 디스크립터에 일치 항목이 이미 정의되어 있으면 어노테이션 데이터 대신 배치 디스크립터의 URL 패턴에서 보안 제한조건과 RunAs 역할을 사용합니다.
참고: 웹 인증 시스템 특성인 com.ibm.wsspi.security.web.webAuthReq를 지속적으로 설정하면 유효한 사용자 이름과 비밀번호를 제공한 경우 보호되지 않은 URL에 로그인할 수 있습니다.상속된 서블릿 어노테이션은 메타데이터 어노테이션입니다. 클래스에는 상속된 어노테이션을 지정하지 마십시오. 서브클래스에 보안 어노테이션이 없으면 상위 클래스에서 보안 어노테이션이 자동으로 상속됩니다. 서브클래스는 보안 어노테이션을 지정하여 상위 보안 어노테이션을 겹쳐쓸 수 있습니다.
다음 예제는 제한조건이 없는 모든 HTTP 메소드의 경우입니다.@WebServlet ("/Example") @ServletSecurity public class Example extends HttpServlet { …… }
다음 예제는 <auth-constraint> 요소 및 기밀 TransportGuarantee가 필요 없는 모든 HTTP 메소드의 경우입니다.@WebServlet ("/Example") @ServletSecurity(@HttpConstraint(transportGuarantee = TransportGuarantee.CONFIDENTIAL)) public class Example extends HttpServlet { …… }
다음 예제는 모든 액세스가 거부된 모든 HTTP 메소드의 경우입니다.@WebServlet ("/Example") @ServletSecurity(@HttpConstraint(EmptyRoleSemantic.DENY)) public class Example extends HttpServlet { …… }
다음 예제는 제한조건이 없는 GET 및 POST 값을 제외한 모든 HTTP 메소드의 경우입니다. GET의 경우, <auth-constraint> 요소에는 ALL ROLE의 멤버십이 필요합니다. POST의 경우, 모든 액세스가 거부됩니다.@WebServlet (name="Example", urlPatterns={"/Example"}) @ServletSecurity((httpMethodConstraints = { @HttpMethodConstraint(value = "GET", rolesAllowed = “ALL ROLE"), @HttpMethodConstraint(value="POST“, emptyRoleSemantic = EmptyRoleSemantic.DENY)) }) public class Example extends HttpServlet { …… }
다음 예제는 GET을 제외한 모든 HTTP 메소드의 경우입니다. <auth-constraint> 요소에는 ALL ROLE의 멤버십이 필요하고 GET 메소드에는 제한조건이 없습니다.@WebServlet (name="Example", urlPatterns={"/Example"}) @ServletSecurity(value = @HttpConstraint(rolesAllowed = "ALL ROLE"), httpMethodConstraints = @HttpMethodConstraint("GET")) public class Example extends HttpServlet { …… }
다음 예제는 TRACE를 제외한 모든 HTTP 메소드의 경우입니다. <auth-constraint> 요소에는 ALL ROLE의 멤버십이 필요하고 TRACE의 경우, 모든 액세스가 거부됩니다.@WebServlet (name="Example", urlPatterns={"/Example"}) @ServletSecurity(value = @HttpConstraint(rolesAllowed = "ALL ROLE"), httpMethodConstraints = @HttpMethodConstraint(value="TRACE", emptyRoleSemantic = EmptyRoleSemantic.DENY)) public class Example extends HttpServlet { …… }