포틀릿 URL 보안
WebSphere® Application Server를 사용하여 서블릿과 같이 포틀릿 URL(Uniform Resource Locator)에 직접 액세스할 수 있습니다. 이 절에서는 URL을 사용하여 포틀릿에 액세스할 경우의 보안 고려사항에 대해 설명합니다.
보안상의 이유로 포틀릿은 서블릿과 유사하게 처리됩니다. 대부분의 포틀릿 보안은 기본적인 서블릿 보안 메커니즘을 사용합니다. 그렇지만 포틀릿 보안 정보는 portlet.xml 파일에 상주하지만 서블릿 및 JavaServer Pages 파일은 web.xml 파일에 상주합니다. 또한 사용자가 포틀릿에 대해 액세스 결정을 할 때 web.xml 파일의 보안 정보(있는 경우)는 portlet.xml 파일의 보안 정보와 결합됩니다.
포틀릿 보안은 프로그램 보안(즉, isUserInRole)과 선언 보안 둘 다를 지원해야 합니다. 프로그램 보안은 정확히 서블릿의 보안과 일치합니다. 그러나 포틀릿의 경우, isUserInRole 메소드는 portlet.xml에 있는 security-role-ref 요소의 정보를 사용합니다. 프로그램 보안에서 사용되는 다른 두 메소드는 getRemoteUser와 getUserPrincipal로, 서블릿에 액세스할 때와 같은 방식으로 작동합니다. 두 메소드 모두 포틀릿에 액세스하는 인증된 사용자 정보를 리턴합니다.
- 자원에 액세스할 수 있는 역할의 이름을 나열하는 auth-constraint 요소는 portlet.xml 파일에 존재하지 않습니다. portlet.xml 파일에는 포틀릿에 액세스하기 위해 필요한 전송 계층 보안의 유형(HTTP 또는 HTTPS)을 표시하는 user-data-constraint 요소만 포함됩니다.
- portlet.xml 파일의 security-constraint 정보에는 portlet-collection 요소가 포함되는 반면 web.xml 파일에는 web-resource-collection 요소가 포함됩니다. portlet-collection 요소에는 단순 포틀릿 이름 목록만 포함되는 반면 web-resource-collection에는 url-patterns와 보호해야 하는 HTTP 메소드도 포함됩니다.
포틀릿 컨테이너는 사용자 인증을 직접 처리하지 않습니다. 예를 들어, 신임 정보를 수집하도록 요청하는 프롬프트를 표시하지 않습니다. 대신 포틀릿 컨테이너는 사용자 인증 메커니즘에 대해 기본적인 서블릿 컨테이너를 사용해야 합니다. 결국, portlet.xml 파일의 security-constraint 정보에는 auth-constraint 요소가 없습니다.
WebSphere Application Server에서 URL을 사용하여 포틀릿에 액세스한 경우, 사용자 인증은 web.xml 파일에 있는 해당 포틀릿의 security-constraint 정보를 기반으로 처리됩니다. 이는 포틀릿에 대해 사용자를 인증하려면 web.xml 파일에 해당 포틀릿에 대한 security-constraint 정보가 포함되고 이 정보에는 관련된 auth-constraint가 포함되어야 함을 의미합니다. 포틀릿에 해당되는 auth-constraint가 web.xml 파일에 없으면 포틀릿에 인증이 필요하지 않음을 표시합니다. 이 경우, web.xml 파일에 auth-constraint가 전혀 없는 서블릿에 대해 URL 패턴처럼 인증되지 않은 액세스가 허용됩니다. 포틀릿의 auth-constraint는 url-pattern 요소에서 포틀릿 이름을 사용하여 직접, 또는 포틀릿을 내포하는 url-pattern으로 간접적으로 지정할 수 있습니다.
다음 예제는 포틀릿 애플리케이션에서 portlet.xml 및 web.xml 파일에 포함된 security-constraint 정보를 사용하여 포틀릿에 대한 보안 결정을 수행하는 방법을 보여줍니다. isUserInRole 호출에 사용되는 security-role-ref 요소는 서블릿과 같은 방법으로 사용되므로 여기에서 설명하지 않습니다.
이 절의 뒤에 있는 예에는(다르게 명시되는 경우는 제외), 4개의 포틀릿(MyPortlet1, MyPortlet2, MyPortlet3, MyPortlet4)이 portlet.xml에 정의됩니다. 포틀릿은 URL을 통해 직접 액세스할 때 web.xml 파일에 있는 정보(있는 경우)를 결합하여 보안을 유지합니다.
모든 예제는 web.xml 및 portlet.xml 파일의 컨텐츠를 표시합니다. 포틀릿 애플리케이션을 어셈블할 때 일반적으로 수행하는 것처럼 배치 디스크립터 파일을 작성할 때 올바른 도구를 사용하십시오.
예제 1: web.xml 파일에 security-constraint 데이터가 없음
<security-constraint>
<display-name>Secure Portlets</display-name>
<portlet-collection>
<portlet-name>MyPortlet1</portlet-name>
<portlet-name>MyPortlet3</portlet-name>
</portlet-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
이 예제에서, MyPortlet1 및 MyPortlet3 아래에 있는 어떤 것에 액세스하는데 이 포틀릿에 비보안 HTTP 프로토콜을 사용하여 액세스하는 경우, 보안 HTTPS 프로토콜을 통해 경로가 재지정됩니다. transport-guarantee는 보안 연결을 사용하도록 설정됩니다. MyPortlet2 및 MyPortlet4의 경우, transport-guarantee가 설정되어 있지 않으므로 비보안(HTTP) 액세스가 허용됩니다. web.xml 파일에는 네 개의 포틀릿 모두에 대해 해당되는 security-constraint 정보가 없습니다. 따라서 모든 포틀릿은 사용자 인증 및 역할 권한이 없어도 액세스할 수 있습니다. 이 인스턴스에 포함된 유일한 보안은 MyPortlet1 및 MyPortlet3에 대해 SSL(Secure Sockets Layer)을 사용하는 전송 계층 보안입니다.
URL | 전송 보호 | 사용자 인증 | 역할 기반 권한 부여 |
---|---|---|---|
/MyPortlet1/* | HTTPS | 없음 | 없음 |
/MyPortlet2/* | 없음 | 없음 | 없음 |
/MyPortlet3/* | HTTPS | 없음 | 없음 |
/MyPortlet4/* | 없음 | 없음 | 없음 |
예제 2: web.xml 파일에 포틀릿 특정 보안 제한조건 데이터 포함
<security-constraint id="SecurityConstraint_1">
<web-resource-collection id="WebResourceCollection_1">
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/MyPortlet1/*</url-pattern>
<url-pattern>/MyPortlet2/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Employee</role-name>
</auth-constraint>
</security-constraint>
- web.xml 파일은 url-pattern을 사용하므로 포틀릿 이름이 자동으로 수정되었습니다. MyPortlet1은 이제 /MyPortlet1/*입니다. 이는 MyPortlet1 URL 아래에 있는 모든 것이 보호됨을 표시합니다. 이는 portlet.xml 파일에 있는 정보와 일치합니다. 보안 런타임 코드가 transport-guarantee의 경우에도 portlet.xml 파일에 있는 portlet-name 요소를 url-pattern으로 변환하기 때문입니다(예: MyPortlet1에서 /MyPortlet1/*로).
- web.xml 파일의 http-method 요소는 예제에서 사용되지 않습니다. 모든 HTTP 메소드는 보호해야 하기 때문입니다.
URL | 전송 보호 | 사용자 인증 | 역할 기반 권한 부여 |
---|---|---|---|
MyPortlet1/* | HTTPS | 예 | 예(Employee) |
MyPortlet2/* | 없음 | 예 | 예(Employee) |
MyPortlet3/* | HTTPS | 없음 | 없음 |
MyPortlet4/* | 없음 | 없음 | 없음 |
예제 3: web.xml 파일에 모든 포틀릿을 내포하는 일반 security-constraint 데이터 포함
<security-constraint id="SecurityConstraint_1">
<web-resource-collection id="WebResourceCollection_1">
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Manager</role-name>
</auth-constraint>
</security-constraint>
이 예제에서, /*는 고유한 명시적 security-constraint를 포함하지 않는 모든 자원은 URL 패턴 일치 규칙에 따라 관리자 역할로 보호해야 함을 의미합니다. portlet.xml 파일에는 MyPortlet1 및 MyPortlet3에 대한 명시적 security-constraint 정보가 포함되므로, 두 포틀릿은 관리자 역할로 보호되지 않고 HTTPS 전송으로만 보호됩니다. portlet.xml 파일에는 auth-constraint 정보를 포함할 수 없으므로, 안에 security-contraint를 포함하는 포틀릿은 내포하는 URL(예: /*)이 web.xml 파일에 나열될 때 비보호 상태로 렌더링됩니다. 이는 URL 일치 규칙 때문입니다.
이전의 경우, MyPortlet1 및 MyPortlet3 모두 사용자 인증 없이 액세스 가능합니다. 그렇지만 MyPortlet2 및 MyPortlet4는 portlet.xml 파일에 security-constraint는 가지고 있지 않기 때문에 /* 패턴을 사용하여 이 포틀릿을 일치시키고 사용자 인증이 필요한 관리자 역할로 보호합니다.
URL | 전송 보호 | 사용자 인증 | 역할 기반 권한 부여 |
---|---|---|---|
MyPortlet1/* | HTTPS | 없음 | 없음 |
MyPortlet2/* | 없음 | 예 | 예(관리자) |
MyPortlet3/* | HTTPS | 없음 | 없음 |
MyPortlet4/* | 없음 | 예 | 예(관리자) |
<security-constraint id="SecurityConstraint_1">
<web-resource-collection id="WebResourceCollection_1">
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Manager</role-name>
</auth-constraint>
</security-constraint>
<security-constraint id="SecurityConstraint_2">
<web-resource-collection id="WebResourceCollection_2">
<web-resource-name>Protection for MyPortlet1</web-resource-name>
<url-pattern>/MyPortlet1/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Manager</role-name>
</auth-constraint>
</security-constraint>
이 경우, MyPortlet1은 관리자 역할로 보호하며 인증이 필요합니다. CONFIDENTIAL의 data-constraint도 적용됩니다. web.xml 파일과 portlet.xml 파일의 정보가 결합되기 때문입니다. MyPortlet3은 web.xml 파일에 명시적으로 나열되지 않으므로 여전히 관리자 역할로 보호되지 않아서 사용자 인증이 필요하지 않습니다.
URL | 전송 보호 | 사용자 인증 | 역할 기반 권한 부여 |
---|---|---|---|
MyPortlet1/* | HTTPS | 예 | 예(관리자) |
MyPortlet2/* | 없음 | 예 | 예(관리자) |
MyPortlet3/* | HTTPS | 없음 | 없음 |
MyPortlet4/* | 없음 | 예 | 예(관리자) |