2장 게이트웨이 작업

이 장에서는 게이트웨이 관련 개념을 설명합니다. 게이트웨이 관리에 대한 자세한 내용은 16 장, 게이트웨이 관리을 참조하십시오게이트웨이 구성에 대한 자세한 내용은 8 장, Secure Remote Access Gateway 구성을 참조하십시오.

이 장에서는 다음 주제를 다룹니다.

• 게이트웨이 소개

• platform.conf 파일 이해

• 웹 프록시 사용

• 자동 프록시 구성 사용

• Netlet 프록시 사용

• Rewriter 프록시 사용

• 게이트웨이에서 역방향 프록시 사용

• 클라이언트 정보 가져오기

• 인증 체이닝 사용

• 와일드카드 인증 사용

• 브라우저 캐싱 사용 불가능

• 게이트웨이 서비스 사용자 인터페이스 사용자 정의

게이트웨이 소개

게이트웨이는 인터넷을 통해 들어오는 원격 사용자 세션과 회사 인트라넷 사이에서 인터페이스와 보안 장벽을 제공합니다. 게이트웨이는 원격 사용자에 대한 단일 인터페이스를 통해 내부 웹 서버와 응용프로그램 서버에서 안전하게 컨텐트를 제공합니다.

각 게이트웨이 인스턴스에 대해 다음 작업을 완료해야 합니다.

• 게이트웨이 프로필 만들기

• 게이트웨이의 여러 인스턴스 만들기

• 8 장, Secure Remote Access Gateway 구성

기타 게이트웨이 관련 항목은 다음과 같습니다.

• 게이트웨이 다시 시작

• 게이트웨이 워치독 구성

• 가상 호스트 지정

• Access Manage에 접속할 프록시 지정

게이트웨이 프로필 만들기

게이트웨이 프로필은 게이트웨이가 수신하는 포트, SSL 옵션 및 프록시 옵션과 같은 게이트웨이 구성과 관련된 모든 정보를 포함합니다. 게이트웨이를 설치하는 경우 기본값을 선택하면 "default"라는 기본 게이트웨이 프로필이 만들어집니다. 기본 프로필에 해당하는 구성 파일은 다음 위치에 있습니다. /etc/opt/SUNWportal/platform.conf.default.

여기서 /etc/opt/SUNWportal은 모든 platform.conf.* 파일의 기본 위치입니다. platform.conf 파일에 대한 자세한 내용은 platform.conf 파일 이해를 참조하십시오.

프로필과 관련하여 다음과 같은 작업을 수행할 수 있습니다.

• 여러 프로필을 만들어 각 프로필에 대한 속성을 정의한 다음 이 프로필을 필요에 따라 서로 다른 게이트웨이에 할당할 수 있습니다.

• 서로 다른 컴퓨터에 있는 게이트웨이 설치에 단일 프로필을 할당할 수 있습니다.

• 같은 컴퓨터에서 실행되는 단일 게이트웨이 인스턴스에 서로 다른 프로필을 할당할 수 있습니다.

같은 컴퓨터에서 실행되는 게이트웨이의 서로 다른 인스턴스에 같은 프로필을 할당하지 마십시오. 이렇게 설정하면 포트 번호가 같게 되므로 충돌이 발생합니다.

같은 게이트웨이에 만들어진 서로 다른 프로필에서 같은 포트 번호를 지정하지 마십시오. 동일한 게이트웨이의 포트 번호가 같은 다중 인스턴스를 실행하면 충돌이 발생합니다.

게이트웨이의 여러 인스턴스 만들기

여러 게이트웨이 인스턴스를 만들려면 Sun Java System Portal Server 7.2 Installation and Configuration Guide의 4 장, Installing and Configuring a Gateway With Portal Server을 참조하십시오.

다중 홈 게이트웨이 인스턴스 만들기

다중 홈 게이트웨이 인스턴스는 하나의 Portal Server에 여러 개의 게이트웨이가 있는 것입니다. 이러한 인스턴스를 만들려면 platform.conf 파일을 다음과 같이 수정합니다.

gatewaybindipaddress = 0.0.0.0

같은 LDAP를 사용하여 게이트웨이 인스턴스 만들기

같은 LDAP를 사용하는 게이트웨이 인스턴스 여러 개를 만드는 경우에는 첫 게이트웨이를 만든 후에 그 뒤의 모든 게이트웨이에서 다음을 수행합니다.

/etc/opt/SUNWam/config/에서 AMConfig-instance-name.properties의 다음 영역을 처음 설치한 게이트웨이 인스턴스와 일치하도록 수정합니다.

같은 LDAP를 사용하여 게이트웨이 인스턴스를 만들려면을 참조하십시오.

게이트웨이 다시 시작

일반적으로 게이트웨이를 다시 시작할 필요가 없습니다. 다음 이벤트가 발생한 경우에만 다시 시작합니다.

• 새 프로필을 만들고 이를 게이트웨이에 할당해야 하는 경우

• 기존 프로필의 일부 속성을 수정하고 변경 사항을 적용해야 하는 경우

• 메모리 부족(OutOfMemory)과 같은 오류 때문에 게이트웨이가 충돌하는 경우

• 게이트웨이가 응답을 중지하고 요청에 대한 서비스를 제공하지 않는 경우

게이트웨이 워치독 구성

워치독이 게이트웨이의 상태를 모니터링하게 될 시간 간격을 설정할 수 있습니다. 워치독을 시작 또는 중지하려면 ./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off 명령을 실행합니다. 시간 간격은 기본적으로 60초로 설정됩니다. 이 값을 변경하려면 crontab 유틸리티에서 다음 행을 편집합니다.

0-59 * * * * gateway-install-root/SUNWportal/bin/
/var/opt/SUNWportal/.gw. 5 > /dev/null 2>&1

crontab 항목을 구성하려면 crontab man 페이지를 참조하십시오.

가상 호스트 지정

가상 호스트는 같은 시스템 IP와 호스트 이름을 가리키는 추가 호스트 이름입니다. 예를 들어 호스트 이름 abc가 호스트 IP 주소 192.155.205.133을 가리키는 경우, 같은 IP 주소를 가리키는 다른 호스트 이름 cde를 추가할 수 있습니다.

Access Manage에 접속할 프록시 지정

게이트웨이에서 프록시 호스트를 사용하여 Portal Server에 배포되는 SRA 코어(RemoteConfigServlet)에 접속하도록 지정할 수 있습니다. 이 프록시는 게이트웨이가 Portal Server와 Access Manager에 접속하기 위해 사용됩니다. 프록시를 지정하려면을 참조하십시오.

platform.conf 파일 이해

platform.conf 파일은 기본적으로 다음 위치에 있습니다. /etc/opt/SUNWportal.

platform.conf 파일에는 게이트웨이에 필요한 상세 정보가 들어 있습니다. 이 절에는 예제 platform.conf 파일이 나와 있으며 모든 항목에 대해 설명합니다.

모든 컴퓨터별 상세 정보를 구성 파일에 포함시키면 공통 프로필을 여러 컴퓨터에서 실행되는 게이트웨이에서 공유할 수 있다는 장점이 있습니다.

다음은 platform.conf 파일의 샘플입니다.

Tue May 30 11:51:23 IST 2006
debug.com.sun.portal.rewriter.original.level=INFO
gateway.favicon=
gateway.bindipaddress=10.12.154.236
debug.com.sun.portal.sra.rproxy.toFromServer.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/Gateway.toFromServer.%u.%g.log
gateway.port=443
rewriterproxy.jvm.flags=-ms64m -mx128m
portal.server.instance=default
debug.com.sun.portal.handler.java.util.logging.FileHandler.filter=
gateway.jdk.dir=/usr/jdk/entsys-j2se
gateway.ignoreURIList=/MSOffice/cltreq.asp,/_vti_bin/owssvr.dll
debug.com.sun.portal.rewriter.rest.level=INFO
gateway.trust_all_server_certs=true
debug.com.sun.portal.handler.java.util.logging.FileHandler.append=true
gateway.cdm.cacheCleanupTime=300000
gateway.httpurl=
debug.com.sun.portal.handler.java.util.logging.FileHandler.count=1
gateway.jvm.classpath=
debug.com.sun.portal.setserverlogs=false
gateway.protocol=https
debug.com.sun.portal.sra.rproxy.toFromServer=java.util.logging.FileHandler
rewriterproxy.jvm.classpath=
gateway.enable.customurl=false
debug.com.sun.portal.sra.rproxy.toFromBrowser=java.util.logging.FileHandler
debug.com.sun.portal.handler.java.util.logging.FileHandler.formatter=com.sun.portal.
log.common.PortalLogFormatter
debug.com.sun.portal.sra.rproxy.toFromBrowser.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/Gateway.toFromBrowser.%u.%g.log
debug.com.sun.portal.level=INFO
debug.com.sun.portal.rewriter.unaffected.separatefile=true
gateway.enable.accelerator=false
debug.com.sun.portal.rewriter.original.separatefile=true
gateway.virtualhost=nicp236.india.sun.com 10.12.154.236
debug.com.sun.portal.stacktrace=true 
gateway.host=nicp236.india.sun.com
debug.com.sun.portal.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/%logger.%sraComponentType.%u.%g.log
gateway.certdir=/etc/opt/SUNWportal/cert/default
gateway.sockretries=3
gateway.allow.client.caching=true
debug.com.sun.portal.rewriter.unaffected.level=INFO
debug.com.sun.portal.rewriter.uriinfo.separatefile=true
log.config.check.period=2000
debug.com.sun.portal.rewriter.rewritten.level=INFO
gateway.userProfile.cacheSize=1024
debug.com.sun.portal.rewriter.rulesetinfo.level=INFO
netletproxy.jvm.classpath=
gateway.userProfile.cacheSleepTime=60000
debug.com.sun.portal.rewriter.uriinfo.level=INFO
debug.com.sun.portal.rewriter.rest.separatefile=true
gateway.notification.url=notification
debug.com.sun.portal.rewriter.rulesetinfo.separatefile=true
gateway.logdelimiter=&&
gateway.ignoreServerList=false
gateway.jvm.flags=-ms64m -mx128m
debug.com.sun.portal.handler.java.util.logging.FileHandler.limit=5000000
gateway.dsame.agent=http\://sunone216.india.sun.com\:8080/portal/RemoteConfigServlet
gateway.httpsurl=
gateway.retries=6
gateway.userProfile.cacheCleanupTime=300000
gateway.logging.password=X03MO1qnZdYdgyfeuILPmQ\=\= UX9x0jIua3hx1YOVRG/TLg\=\=
netletproxy.jvm.flags=-ms64m -mx128m
debug.com.sun.portal.rewriter.rewritten.separatefile=true
gateway.user=noaccess
gateway.external.ip=10.12.154.236
debug.com.sun.portal.handler=java.util.logging.FileHandler
gateway.cdm.cacheSleepTime=60000
rewriterproxy.accept.from.gateways=
rewriterproxy.checkacl=false

다음 표에는 platform.conf 파일의 모든 필드와 해당 설명이 정리되어 있습니다.

웹 프록시 사용

타사 웹 프록시를 사용하여 HTTP 자원에 연결하도록 게이트웨이를 구성할 수 있습니다. 웹 프록시는 클라이언트와 인터넷 사이에 상주합니다.

웹 프록시 구성

여러 도메인 및 부속 도메인에 서로 다른 프록시가 사용될 수 있습니다. 이 항목은 특정 도메인에서 특정 부속 도메인에 연결할 때 어떤 프록시를 사용할지 게이트웨이에 알려 줍니다. 게이트웨이에 지정된 프록시 구성은 다음과 같이 작동합니다.

• 게이트웨이 서비스의 [도메인 및 부속 도메인의 프록시] 필드에 필요한 프록시와 함께 도메인 및 부속 도메인 목록을 만듭니다.

• 프록시 사용 옵션을 사용하는 경우,

  • [도메인 및 부속 도메인의 프록시] 필드에 지정된 프록시가 지정된 호스트에 사용됩니다.

  • 도메인 및 부속 도메인의 프록시 목록에 지정된 도메인 및 부속 도메인에서 특정 URL에 직접 연결하려면 [웹 프록시 URL 사용 안함] 필드에서 해당 URL을 지정합니다.

  프록시 사용 옵션이 사용 불가능 상태인 경우,

  • 프록시가 도메인 및 부속 도메인의 프록시 필드에 지정된 도메인과 부속 도메인에서 특정 URL에 사용되도록 하려면 [웹 프록시 URL 사용] 목록에서 해당 URL을 지정합니다.

    프록시 사용 옵션이 사용 불가능 상태이더라도 [웹 프록시 사용]에 나열된 URL에 프록시를 사용하여 연결할 수 있습니다. 이 URL의 프록시는 [도메인 및 부속 도메인의 프록시] 목록에서 가져온 것입니다.

    다음 그림에서는 게이트웨이 서비스의 프록시 구성에 기반하여 웹 프록시 정보가 어떻게 결정되는지 보여줍니다.

    

    웹 프록시 구성에서 프록시 사용이 활성화되어 있고, 요청된 URL이 [웹 프록시 URL 사용 안함] 목록에 나열되는 경우 게이트웨이가 대상 호스트에 직접 연결됩니다.

    프록시 사용이 활성화되어 있고, 요청된 URL이 [웹 프록시 URL 사용 안함] 목록에 나열되지 않은 경우 게이트웨이는 지정된 프록시를 통해 대상 호스트에 연결됩니다. 프록시가 지정되어 있는 경우에는 [도메인 및 부속 도메인의 프록시] 목록에서 찾으면 됩니다.

    프록시 사용이 비활성화되어 있고, 요청된 URL이 [웹 프록시 URL 사용] 목록에 나열되면 게이트웨이는 [도메인 및 부속 도메인의 프록시] 목록에 있는 프록시 정보를 사용하여 대상 호스트에 연결됩니다.

    프록시 사용이 비활성화되어 있고, 요청된 URL이 [웹 프록시 URL 사용] 목록에 나열되지 않으면 게이트웨이가 대상 호스트에 직접 연결됩니다.

    위에 설명된 조건 중 어느 것에도 해당하지 않아서 직접 연결이 불가능하면 연결할 수 없다는 게이트웨이 오류 메시지를 표시합니다.

표준 포털 데스크탑의 책갈피 채널을 통해 URL에 액세스하는 중에 위에 설명된 조건 중 어느 것도 충족되지 않으면 게이트웨이는 브라우저로 리디렉션합니다. 그러면 브라우저는 자체 프록시 설정을 통해 URL에 액세스합니다.

구문

domainname [web_proxy1:port1]|subdomain1 [web_proxy2:port2]|

예

sesta.com wp1:8080|red wp2:8080|yellow|* wp3:8080

*는 모든 항목과 일치하는 와일드카드입니다.

여기서,

sesta.com은 도메인 이름이고 wp1은 포트 8080에 연결할 프록시입니다.

red는 하위 도메인이고 wp2는 포트 8080에 연결할 프록시입니다.

yellow는 하위 도메인입니다. 프록시가 지정되어 있지 않고 포트 8080에 도메인에 지정된 프록시 즉, wp1이 사용됩니다.

*는 모든 다른 하위 도메인에서 포트 8080에 wp3을 사용해야 함을 나타냅니다.

포트를 지정하지 않은 경우 기본적으로 포트 8080이 사용됩니다.

웹 프록시 정보처리

클라이언트가 특정 URL에 액세스하려고 하면 해당 URL의 호스트 이름이 [도메인 및 하위 도메인의 프록시] 목록의 항목과 일치됩니다. 요청된 호스트 이름의 가장 긴 접미어에 일치하는 항목이 선택됩니다. 예를 들어, 요청된 호스트 이름이 host1.sesta.com이라고 가정해 보겠습니다. 다음 검색 작업은 일치하는 항목을 찾을 때까지 수행됩니다.

• [도메인 및 하위 도메인의 프록시]에 host1.sesta.com이 있는지 검색합니다. 일치하는 항목이 있으면 이 항목에 지정된 프록시를 통해 그 호스트에 연결됩니다.

• 그렇지 않으면 목록에 *.sesta.com이 있는지 검색합니다. 항목을 찾으면 해당 프록시가 사용됩니다.

• 그렇지 않으면 목록에 sesta.com이 있는지 검색합니다. 항목을 찾으면 해당 프록시가 사용됩니다.

• 그렇지 않으면 목록에 *.com이 있는지 검색합니다. 항목을 찾으면 해당 프록시가 사용됩니다.

• 그렇지 않으면 목록에 com이 있는지 검색합니다. 항목을 찾으면 해당 프록시가 사용됩니다.

• 그렇지 않으면 목록에서 *에 대한 검색을 수행합니다. 항목을 찾으면 해당 프록시가 사용됩니다.

• 일치하는 항목이 없으면 직접 연결을 시도합니다.

[도메인 및 부속 도메인의 프록시] 목록에서 다음 항목을 고려합니다.

com p1| host1 p2 | host2 | * p3
sesta.com p4 | host5 p5 | * p6
florizon.com | host6
abc.sesta.com p8 | host7 p7 | host8 p8 | * p9
host6.florizon.com p10
host9.sesta.com p11
siroe.com | host12 p12 | host13 p13 | host14 | * p14
siroe.com | host15 p15 | host16 | * p16
* p17

게이트웨이에서는 내부적으로 이러한 항목을 다음 표에 나와 있는 것처럼 테이블로 매핑합니다.

[도메인 및 부속 도메인의 프록시] 목록에서 프록시 항목을 | 기호로 분리하는 대신 목록에서 개별 항목을 별도의 행으로 지정할 수 있습니다. 예를 들어, 다음과 같은 항목 대신에

sesta.com p1 | red p2 | * p3

이 정보를 다음과 같이 지정할 수 있습니다.

sesta.com p1
red.sesta.com p2
*.sesta.com p3

이 목록 형식을 사용하면 반복되는 항목이나 기타 모호한 부분을 쉽게 파악할 수 있습니다.

도메인 및 부속 도메인의 프록시 목록에 기반하여 다시 쓰기

[도메인 및 부속 도메인의 프록시] 목록의 항목도 Rewriter에서 사용됩니다. Rewriter는 도메인이 [도메인 및 부속 도메인의 프록시] 목록에 나열된 도메인과 일치하는 모든 URL을 다시 씁니다.

[도메인 및 하위 도메인의 프록시] 목록의 * 항목은 다시 쓰기에 고려되지 않습니다. 예를 들어 24번 항목은 고려 대상이 되지 않습니다.

Rewriter에 대한 자세한 정보는 4 장, Rewriter 작업을 참조하십시오.

기본 도메인 및 부속 도메인

URL의 대상 호스트가 정규 호스트 이름이 아닐 경우, 정규 이름에 도달하도록 기본 도메인 및 부속 도메인을 사용합니다.

관리 콘솔의 [기본 도메인] 필드 항목이 다음과 같다고 가정해 보겠습니다.

red.sesta.com

[도메인 및 부속 도메인의 프록시] 목록에 해당하는 항목이 있어야 합니다.

위의 예에서는 sesta.com이 기본 도메인이고 기본 하위 도메인은 red입니다.

요청된 URL이 host1인 경우, 이 항목은 기본 도메인 및 하위 도메인을 통해 host1.red.sesta.com으로 결정됩니다. 그런 다음 [도메인 및 하위 도메인의 프록시] 목록에 host1.red.sesta.com이 있는지 확인합니다.

자동 프록시 구성 사용

[도메인 및 부속 도메인의 프록시] 목록에 있는 정보를 무시하려면 자동 프록시 구성(PAC) 기능을 활성화합니다.

자동 프록시 구성(PAC) 파일을 사용하는 경우

• Portal Server, Gateway, Netlet 및 Proxylet은 Rhino 소프트웨어를 사용하여 PAC 파일을 구문 분석합니다. SUNWrhino 패키지는 Java Enterprise System Accessory CD에서 설치할 수 있습니다.

  이 패키지에는 /usr/share/lib 디렉토리에 반드시 있어야 하는 js.jar 파일이 포함되어 있습니다. 이 디렉토리를 게이트웨이 및 Portal Server 시스템의 webserver/appserver 클래스 경로에 추가합니다. 그렇지 않으면 Portal Server, Gateway, Netlet 및 Proxylet에서 PAC 파일을 구문 분석할 수 없습니다.

• js.jar은 게이트웨이 컴퓨터의 $JRE_HOME/lib/ext 디렉토리에 있어야 합니다. 그렇지 않으면 게이트웨이에서 PAC 파일의 구문을 분석할 수 없습니다.

• 게이트웨이는 부팅 시에 게이트웨이 프로필 [자동 프록시 구성 파일] 위치 필드에 지정된 위치로부터 PAC 파일을 불러옵니다.

• 게이트웨이는 URLConnection API를 사용하여 이 위치에 도달합니다. 프록시가 게이트웨이에 도달하도록 구성해야 하는 경우에는 프록시를 다음과 같이 구성해야 합니다.

  1. 명령줄에서 다음 파일을 편집합니다.

     /etc/opt/SUNWportal/platform.conf.gateway-profile-name

  2. 다음 항목을 추가합니다.

     http.proxyHost= web-proxy-hostname

     http.proxyPort= web-proxy-port

     http.proxySet=true

  3. 게이트웨이를 다시 시작하여 지정된 프록시를 사용합니다.

     ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>

• PAC 파일 초기화가 실패하면 게이트웨이는 [도메인 및 부속 도메인의 프록시] 목록에 있는 정보를 사용합니다.

• PAC 파일로부터 "" (빈 문자열) 이나 "null"이 반환되면 게이트웨이에서는 호스트가 인트라넷에 속하지 않는 것으로 가정합니다. 이는 호스트가 [도메인 및 부속 도메인의 프록시] 목록에 있지 경우와 비슷합니다.

  게이트웨이에서 호스트에 직접 연결되도록 하려면 "DIRECT"를 반환합니다. DIRECT 또는 NULL이 반환되는 예제를 참조하십시오.

• 여러 프록시가 지정되어 있으면 게이트웨이는 첫 번째 반환된 프록시만 사용합니다. 호스트에 지정된 여러 프록시에서 페일오버나 로드 균형 조정을 시도하지 않습니다.

• 게이트웨이는 SOCKS 프록시를 무시하고 직접 연결을 시도하면서 호스트가 인트라넷의 일부라 가정합니다.

• 인트라넷의 일부가 아닌 호스트에 도달하는 데 프록시를 사용하도록 지정하려면 프록시 유형 STARPROXY를 사용합니다. 이 프록시 유형은 PAC 파일 형식의 확장이며 게이트웨이 프로필에 있는 [도메인 및 하위 도메인의 프록시] 부분의 * proxyHost:port 항목과 유사합니다. STARPROXY가 반환되는 예제를 참조하십시오.

예제 PAC 파일 사용

다음 예제는 [도메인 및 부속 도메인의 프록시] 목록과 해당하는 PAC 파일에 나열된 URL을 보여줍니다.

DIRECT 또는 NULL이 반환되는 예제

도메인 및 하위 도메인에 사용되는 프록시:

*intranet1.com proxy.intranet.com:8080

intranet2.com proxy.intranet1.com:8080

해당하는 PAC 파일:

// Start of the PAC File
function FindProxyForURL(url, host) {
         if (dnsDomainIs(host, ".intranet1.com")) {
             return "DIRECT";
         }
          if (dnsDomainIs(host, ".intranet2.com")) {
              return "PROXY proxy.intranet1.com:8080";
          }
          return "NULL";
}
//End of the PAC File

STARPROXY가 반환되는 예제

도메인 및 하위 도메인에 사용되는 프록시:

intranet1.com

intranet2.com.proxy.intranet1.com:8080

internetproxy.intranet1.com:80

해당하는 PAC 파일:

// Start of the PAC File
function FindProxyForURL(url, host) {
          if (dnsDomainIs(host, ".intranet1.com")) {
              return "DIRECT";
          }
          if (dnsDomainIs(host, ".intranet2.com")) {
              return "PROXY proxy.intranet1.com:8080;" +
                  "PROXY proxy1.intranet1.com:8080";
          }
          return "STARPROXY internetproxy.intranet1.com:80";
}
//End of the PAC File

이 경우 요청이 .intranet2.com 도메인에 있는 호스트에 대한 것이면 게이트웨이는 proxy.intranet1.com:8080에 접속합니다. proxy.intranet1.com:8080이 다운되면 요청이 실패합니다. 게이트웨이는 페일오버하지 않고 proxy1.intranet1.com:8080에 접속합니다.

PAC 파일 위치 지정

PAC 파일의 위치를 지정하는 형식은 다음과 같이 해당 위치에 따라 다릅니다.

• PAC 파일이 웹 서버에 상주하는 경우 다음과 같이 PAC URL을 입력합니다.

  http://hostname/pacfile_name .pac

• PAC 파일이 로컬 파일(예: c:\\pacfile\\sample.pac)인 경우 java 1.4.1_x에 대해 다음과 같이 PAC URL을 입력합니다.

  file://c:/pacfile/sample.pac

• PAC 파일이 로컬 파일(예: c:\\pacfile\\sample.pac)인 경우 java 1.4.2_x에 대해 다음과 같이 PAC URL을 입력합니다.

  file:///c:/pacfile/sample.pac

별도 세션에서 서비스 추가

Portal Server 서비스를 별도 세션에서 추가할 경우

• Portal Server가 Portal Server 관리 콘솔의 [게이트웨이] > [핵심] 아래에 나열됩니다.

• Portal Server URL은 [게이트웨이] > [보안] 아래의 비인증 URL에 나열됩니다.

Netlet 프록시 사용

Netlet 패킷은 게이트웨이에서 비밀번호가 해독되어 대상 서버로 보내집니다. 그러나 게이트웨이는 비무장 지대(DMZ)와 인트라넷 사이의 방화벽을 통해 모든 Netlet 대상 호스트에 액세스해야 합니다. 따라서 이렇게 설정하면 방화벽에서 많은 포트를 열어야 합니다. Netlet 프록시는 방화벽에서 열린 포트의 수를 줄이는 데 사용할 수 있습니다.

Netlet 프록시는 클라이언트로부터 게이트웨이를 거쳐 인트라넷에 상주하는 Netlet 프록시에 이르기까지 보안 터널을 확장하여 게이트웨이와 인트라넷 사이의 보안을 강화합니다. 프록시가 있으면 Netlet 패킷은 프록시에서 해독된 후 대상으로 보내집니다.

Netlet 프록시를 사용하면 다음과 같은 장점이 있습니다.

• 보안 계층을 추가할 수 있습니다.

• 상당한 규모의 배치 환경에서 내부 방화벽을 통해 추가 IP 주소와 게이트웨이의 포트 사용을 최대한 줄일 수 있습니다.

• 게이트웨이와 Portal Server 간 개방 포트 수를 1로 제한할 수 있습니다. 이 포트 수는 설치 시 구성 가능합니다.

• 클라이언트와 게이트웨이 사이의 보안 채널을 Netlet 프록시 사용의 "Netlet 프록시가 구성되어 있는 경우" 부분에 나와 있듯이 Portal Server까지 확장할 수 있습니다. Netlet 프록시는 데이터 암호화를 통해 보안을 강화한다는 이점이 있지만 시스템 자원을 더 많이 사용할 수 있습니다. Netlet 프록시 설치에 대한 자세한 내용은 Sun Java System 설치 설명서를 참조하십시오.

다음과 같은 작업을 수행할 수 있습니다.

• Portal Server 노드나 별도 노드에 Netlet 프록시를 설치할 수 있습니다.

• 다중 Netlet 프록시를 설치하고 관리 콘솔을 사용하여 단일 게이트웨이에 구성할 수 있습니다. 로드 균형 조절에 유용합니다.

• 단일 시스템에 Netlet 프록시의 다중 인스턴스를 구성할 수 있습니다.

• 게이트웨이의 다중 인스턴스를 Netlet 프록시의 단일 설치에 지정할 수 있습니다.

• 웹 프록시를 통해 Netlet을 통과할 수 있습니다.

Netlet 프록시가 설치된 경우와 설치되지 않은 경우, 게이트웨이와 Portal Server를 구현하는 3가지 구현 샘플이 나와 있습니다. 구성 요소에는 클라이언트, 방화벽 2개, 두 방화벽 사이에 상주하는 게이트웨이, Portal Server 및 Netlet 대상 서버가 포함됩니다.

첫 번째 시나리오는 Netlet 프록시가 설치되지 않은 경우의 게이트웨이와 Portal Server를 보여줍니다. 데이터 암호화는 클라이언트에서 게이트웨이까지만 적용됩니다. 각 Netlet 연결 요청을 위해 두 번째 방화벽에서 포트가 1개 개방되어 있습니다.

두 번째 시나리오는 Netlet 프록시가 Portal Server에 설치된 경우의 게이트웨이와 Portal Server를 보여줍니다. 데이터 암호화는 클라이언트에서 Portal Server까지 전체적으로 적용됩니다. 모든 Netlet 연결이 Netlet 프록시를 통해 라우팅되기 때문에 두 번째 방화벽에서 Netlet 요청에 사용되는 포트는 하나만 열려 있으면 됩니다.

세 번째 시나리오는 Netlet 프록시가 별도 노드에 설치된 경우의 게이트웨이와 Portal Server를 보여줍니다. Netlet 프록시를 별도 노드에 설치하면 Portal Server 노드의 로드가 줄어듭니다. 여기서는 두 번째 방화벽에서 2개의 포트만 개방되어 있으면 됩니다. 한 포트는 Portal Server에 대한 요청을 처리하고 다른 포트는 Netlet 프록시 서버에 대한 Netlet 요청을 라우팅합니다.

그림 2–1 Netlet 프록시 구현

Netlet 프록시 활성화

Portal Server 관리 콘솔을 사용하여 게이트웨이 서비스를 통해 Netlet 프록시를 사용할 수 있습니다.

Netlet 프록시 다시 시작

프록시가 예기치 않게 중지될 때마다 다시 시작하도록 Netlet 프록시를 구성할 수 있습니다. Netlet 프록시를 모니터링하고 다운된 경우 다시 시작하도록 워치독 프로세스를 예약할 수 있습니다.

Netlet 프록시를 수동으로 다시 시작할 수도 있습니다. 자세한 단계는 Netlet 프록시를 다시 시작하려면을 참조하십시오.

Netlet 프록시 워치독을 구성하려면

워치독이 Netlet 프록시의 상태를 모니터하는 시간 간격을 구성할 수 있습니다. 시간 간격은 기본적으로 60초로 설정됩니다. 이 간격을 변경하려면 다음 행을 crontab 파일에 추가합니다.

0-59 * * * * netlet-install-dir/bin/checkgw /var/opt/SUNWportal/.gw 5 > /dev/null 2>&1

워치독을 시작 또는 중지하려면 ./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off 명령을 실행합니다.

Rewriter 프록시 사용

Rewriter 프록시는 인트라넷에 설치됩니다. 게이트웨이는 컨텐트를 직접 검색하는 대신, 컨텐트를 가져와 게이트웨이로 반환하는 Rewriter 프록시로 모든 요청을 전달합니다.

Rewriter 프록시를 사용하면 다음과 같은 장점이 있습니다.

• 게이트웨이와 서버 사이에 방화벽이 있는 경우 방화벽에서는 포트를 2개만 열면 됩니다. 하나는 게이트웨이와 Rewriter 프록시 사이의 포트이고 다른 하나는 게이트웨이와 Portal Server 사이의 포트입니다.

• 대상 서버가 HTTP 프로토콜만 지원하고 HTTPS는 지원하지 않아도 게이트웨이와 인트라넷 사이의 HTTP 트래픽이 안정적으로 됩니다.

Rewriter 프록시를 지정하지 않으면 사용자가 인트라넷 컴퓨터에 액세스하려고 할 때 게이트웨이 구성 요소에서 인트라넷 컴퓨터에 직접 연결합니다.

Rewriter 프록시를 로드 조정기로 사용하는 경우에는 Rewriter의 platform.conf.instance_name이 로드 조정기 URL을 가리키는지 확인해야 합니다. 또한 [Portal Servers] 목록에서 로드 밸런서 호스트를 지정하십시오.

각 게이트웨이 인스턴스에 대해 여러 Rewriter 프록시 인스턴스가 있는 경우(포털 노드에서는 필요하지 않음) platform.conf 파일에서 Rewriter 프록시의 단일 포트 항목이 아니라 host-name:port 형식으로 각 Rewriter 프록시의 세부 사항을 입력합니다.

Rewriter 프록시의 인스턴스 만들기

rwpmultiinstance 스크립트를 사용하여 Portal Server 노드에 Rewriter 프록시의 새 인스턴스를 만듭니다. 게이트웨이 프로필을 만든 후에 이 스크립트를 실행하십시오.

Rewriter 프록시 인스턴스를 만들려면을 참조하십시오.

Rewriter 프록시 활성화

Access Manager 관리 콘솔의 SRA 구성에서 게이트웨이 서비스를 통해 Rewriter 프록시를 활성화합니다.

Rewriter 프록시 다시 시작

프록시가 예기치 않게 중지될 때마다 다시 시작하도록 Rewriter 프록시를 구성할 수 있습니다. 이런 문제가 발생하는지 모니터링하고 문제가 발생하면 다시 시작하도록 워치독 프로세스를 예약할 수 있습니다.

Rewriter 프록시를 수동으로 다시 시작할 수도 있습니다.

Rewriter 프록시를 다시 시작하려면을 참조하십시오.

Rewriter 프록시 워치독 구성

워치독이 Rewriter 프록시 상태를 모니터링하는 시간 간격을 구성할 수 있습니다. 시간 간격은 기본적으로 60초로 설정됩니다. 시간 간격을 변경하려면 crontab 파일에 다음 행을 추가하십시오.

0-59 * * * * rewriter-proxy-install-root /bin/checkgw /var/opt/SUNWportal/.gw 5 > /dev/null 2>&1

워치독을 시작 또는 중지하려면 ./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off 명령을 실행합니다.

게이트웨이에서 역방향 프록시 사용

프록시 서버는 인트라넷에 인터넷 컨텐트를 서비스하고 역 프록시는 인터넷에 인트라넷 컨텐트를 서비스합니다. 로드 균형 조절 및 캐싱을 수행하도록 역방향 프록시의 배포를 구성할 수 있습니다.

이 배포에서 게이트웨이 전방에 타사의 역 프록시가 사용된다면 게이트웨이의 URL 대신 역 프록시의 URL로 응답을 다시 써야 합니다. 이를 위해 다음 구성이 필요합니다.

역 프록시를 활성화하려면을 참조하십시오.

클라이언트 정보 가져오기

게이트웨이가 클라이언트 요청을 내부 서버로 전달하면 HTTP 헤더가 HTTP 요청에 추가됩니다. 이 헤더를 사용하여 추가 클라이언트 정보를 가져오고 게이트웨이가 있는지 감지할 수 있습니다.

HTTP 요청 헤더를 보려면 platform.conf 파일에서 해당 항목을 gateway.error=message로 설정합니다. 그런 다음 서블릿 API에서 request.getHeader()를 사용하십시오. 다음 표에는 HTTP 헤더에 있는 정보가 나열되어 있습니다.

인증 체이닝 사용

인증 체이닝은 인증의 일반 메커니즘보다 높은 수준으로 보안을 강화합니다. 사용자가 2개 이상 인증 메커니즘에 대해 인증 받도록 설정할 수 있습니다.

여기에 설명된 절차는 게이트웨이에서 개인 디지털 인증서(PDC) 인증과 함께 인증 체이닝을 사용하는 경우에만 적용됩니다. 게이트웨이에 PDC 인증이 없는 인증 체이닝에 대한 자세한 내용은 Access Manager 관리 설명서를 참조하십시오.

예를 들어, PDC 및 Radius 인증 모듈을 체이닝한 경우에는 사용자가 표준 포털 데스크탑에 액세스하려면 이 3개 모듈에 대한 인증을 모두 거쳐야 합니다.

자세한 단계는 기존 PDC 인스턴스에 인증 모듈을 추가하려면 을 참조하십시오.

활성화된 경우 PDC는 사용자에게 항상 가정 먼저 제시되는 인증 모듈입니다.

와일드카드 인증 사용

와일드카드 인증에서는 정규 DNS 호스트 이름에 와일드카드 문자가 있는 단일 인증을 수락합니다.

인증서가 있으면 동일한 도메인 내의 여러 호스트가 보호됩니다. 예를 들어, *.domain.com에 대한 인증을 abc.domain.com 및 abc1.domain.com에 사용할 수 있습니다. 이 인증은 domain.com 도메인에 있는 모든 호스트에 유효합니다.

브라우저 캐싱 사용 불가능

게이트웨이 구성 요소는 웹 브라우저를 사용하여 어느 위치에서나 백엔드 기업 데이터에 안전하게 액세스하므로 클라이언트가 정보를 로컬로 캐싱할 필요가 없습니다.

특정 게이트웨이의 platform.conf 파일에 있는 속성을 수정하여 게이트웨이를 통해 리디렉션된 페이지의 캐싱을 비활성화할 수 있습니다.

이 옵션을 비활성화하면 게이트웨이 성능에 영향을 줄 수 있습니다. 표준 포털 데스크탑을 새로 고칠 때마다 게이트웨이는 브라우저에서 이전에 캐싱한 이미지와 같이 페이지에서 참조되는 모든 항목을 검색해야 합니다. 그러나 이 기능을 사용하면 원격으로 액세스한 보안 컨텐트를 캐싱한 자취가 클라이언트 사이트에 남지 않습니다. 인터넷 카페 또는 기업 IT 제어를 받지 않는 유사한 원격 장소로부터 기업 네트워크에 액세스하는 경우 이 기능은 비중이 있을 수 있습니다.

브라우저 캐싱을 비활성화하려면을 참조하십시오.

게이트웨이 서비스 사용자 인터페이스 사용자 정의

이 절에서는 편집할 수 있는 여러 게이트웨이 등록 정보 파일에 대해 설명합니다.

srapGateway.properties 파일 수정

다음과 같은 목적으로 이 파일을 편집할 수 있습니다.

• 게이트웨이 실행 중에 나타날 수 있는 오류 메시지를 사용자 정의할 때

  • HTML-CharSets=ISO-8859-1은 이 파일을 만드는 데 사용되는 문자 집합을 지정합니다.

  • 중괄호 안의 숫자(예: {0})는 값이 런타임으로 표시된다는 것을 뜻합니다. 필요에 따라 이 숫자와 연관된 레이블을 변경하거나 레이블을 재배열할 수 있습니다. 레이블 숫자와 오류는 연관되어 있기 때문에 레이블에 해당하는 표시될 메시지가 있어야 합니다.

  로그 정보를 사용자 정의할 때.

  기본적으로 srapGateway.properties 파일은 portal-server-install-root /SUNWportal/locale 디렉토리에 있습니다. 게이트웨이 컴퓨터에 표시되는 모든 메시지는 해당 메시지의 언어와 상관 없이 이 파일에 있습니다.

  클라이언트 표준 포털 데스크탑에 나타나는 메시지의 언어를 변경하려면 이 파일을 각 로켈 디렉토리로 복사합니다(예: portal-server-install-root /SUNWportal/locale_en_US).

srapgwadminmsg.properties 파일 수정

다음과 같은 이유로 이 파일을 편집할 수 있습니다.

• 관리 콘솔의 게이트웨이 서비스에 대한 버튼에 나타나는 레이블을 사용자 정의할 때

• 게이트웨이를 구성하는 중에 나타나는 상태 메시지 및 오류 메시지를 사용자 정의할 때

LDAP 디렉토리 공유

Portal Server 및 Access Manager 서버의 두 인스턴스가 같은 LDAP 디렉토리를 공유하는 경우 모든 후속 Portal Server, Access Manager 및 게이트웨이 인스턴스에서 같은 LDAP 디렉토리를 공유합니다. LDAP 디렉토리를 공유하려면을 참조하십시오.