|
| |
| Sun Java System Portal Server Secure Remote Access 6 2005Q1 관리 설명서 | |
2장
게이트웨이이 장에서는 게이트웨이 관련 개념과 게이트웨이의 원활한 실행에 필요한 정보를 설명합니다. 게이트웨이 구성에 대한 자세한 내용은 9장, "게이트웨이 구성"을 참조하십시오.
이 장에서는 다음 주제를 다룹니다.
게이트웨이의 개요게이트웨이는 인터넷을 통해 들어오는 원격 사용자 세션과 회사 인트라넷 사이에서 인터페이스와 보안 장벽을 제공합니다. 게이트웨이는 원격 사용자에 대한 단일 인터페이스를 통해 내부 웹 서버와 응용 프로그램 서버에서 안전하게 컨텐트를 제공합니다.
각 게이트웨이에서 다음 작업을 수행해야 합니다.
- 게이트웨이 프로필 만들기. 자세한 내용은 게이트웨이 프로필 만들기를 참조하십시오.
- 게이트웨이 인스턴스 만들기. 자세한 내용은 게이트웨이 인스턴스 만들기를 참조하십시오.
- 게이트웨이 구성. 9장, "게이트웨이 구성"을 참조하십시오.
게이트웨이 프로필 만들기게이트웨이 프로필에는 게이트웨이가 수신하는 포트, SSL 옵션 및 프록시 옵션과 같이 게이트웨이 구성에 관련된 모든 정보가 들어 있습니다.
게이트웨이를 설치할 때 기본값을 선택하면 "기본"이라는 기본 게이트웨이 프로필이 만들어집니다. 기본 프로필에 해당하는 구성 파일은 다음 위치에 있습니다.
/etc/opt/SUNWps/platform.conf.default
여기서 /etc/opt/SUNWps는 모든 platform.conf.* 파일을 위한 기본 위치입니다.
platform.conf 파일 내용에 대한 자세한 내용은 platform.conf 파일 이해를 참조하십시오.
가능한 작업:
게이트웨이 프로필을 만들려면
- Sun Java™ System Access Manager 관리 콘솔에 관리자로 로그인합니다.
- [서비스 구성] 탭을 선택합니다.
- SRA 구성 아래에서 게이트웨이 옆에 있는 화살표를 누릅니다.
오른쪽 창에 [게이트웨이] 페이지가 표시됩니다.
- [새로 만들기]를 누릅니다.
[새 게이트웨이 프로필 만들기] 페이지가 표시됩니다.
- 새 게이트웨이 프로필의 이름을 입력합니다.
- 드롭다운 목록에서 새 프로필을 만들 때 사용할 프로필을 선택합니다.
기본적으로 만들어지는 새 프로필은 모두 사전 제공된 기본 프로필을 기준으로 합니다. 사용자 정의 프로필을 만든 경우 드롭다운 목록에서 해당 프로필을 선택할 수 있습니다. 새 프로필은 선택한 프로필의 모든 속성을 상속합니다.
기존 프로필을 복사하여 새 프로필을 만드는 경우 포트도 동일하게 복사됩니다. 새 프로필의 포트를 기존 프로필과 충돌하지 않도록 변경하십시오.
- [만들기]를 누릅니다.
새 프로필이 만들어지며 새 프로필이 나열된 [게이트웨이] 페이지로 돌아갑니다.
- gwmultiinstance 스크립트를 실행하여 게이트웨이의 새 인스턴스를 만듭니다. 게이트웨이 시작 및 중지를 참조하십시오.
- 변경 사항을 적용하려면 이 게이트웨이 프로필 이름의 게이트웨이를 다시 시작합니다.
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
게이트웨이 시작 및 중지을 참조하십시오. 게이트웨이를 구성하려면 9장, "게이트웨이 구성"을 참조하십시오.
platform.conf 파일 이해platform.conf 파일은 기본적으로 다음 위치에 있습니다.
/etc/opt/SUNWps
platform.conf 파일에는 게이트웨이에 필요한 상세 정보가 들어 있습니다. 이 절에는 예제 platform.conf 파일이 나와 있으며 모든 항목에 대해 설명합니다.
모든 컴퓨터별 상세 정보를 구성 파일에 포함시키면 공통 프로필을 여러 컴퓨터에서 실행되는 게이트웨이에서 공유할 수 있다는 장점이 있습니다.
다음은 예제입니다.
#
# Copyright 11/28/00 Sun Microsystems, Inc. All Rights Reserved.
# "@(#)platform.conf 1.38 00/11/28 Sun Microsystems"
#
gateway.user=noaccess
gateway.jdk.dir=/usr/java_1.3.1_06
gateway.dsame.agent=http://pserv2.iportal.com:8080/sunportal/RemoteConfigServlet
portal.server.protocol=http
portal.server.host=pserv2.iportal.com
portal.server.port=8080
gateway.protocol=https
gateway.host=siroe.india.sun.com
gateway.port=333
gateway.trust_all_server_certs=true
gateway.trust_all_server_cert_domains=false
gateway.virtualhost=siroe1.india.sun.com 10.13.147.81
gateway.virtualhost.defaultOrg=o=root,dc=test,dc=com
gateway.notification.url=/notification
gateway.retries=6
gateway.debug=error
gateway.debug.dir=/var/opt/SUNWps/debug
gateway.logdelimiter=&&
gateway.external.ip=10.12.147.71
gateway.certdir=/etc/opt/SUNWps/cert/portal
gateway.allow.client.caching=true
gateway.userProfile.cacheSize=1024
gateway.userProfile.cacheSleepTime=60000
gateway.userProfile.cacheCleanupTime=300000
gateway.bindipaddress=10.12.147.71
gateway.sockretries=3
gateway.enable.accelerator=false
gateway.enable.customurl=false
gateway.httpurl=http://siroe.india.sun.com
gateway.httpsurl=https://siroe.india.sun.com
gateway.favicon=https://siroe.india.sun.com
gateway.logging.password=ALKJDF123SFLKJJSDFU
portal.server.instance=
gateway.cdm.cacheSleepTime=60000
gateway.cdm.cacheCleanUpTime=300000
netletproxy.port=10555
rewriterproxy.port=10556
표 2-1에는 platform.conf 파일에 있는 모든 필드가 나열되고 이에 대한 설명이 나와 있습니다.
게이트웨이 인스턴스 만들기gwmultiinstance 스크립트를 사용하여 게이트웨이 인스턴스를 만들거나 제거합니다. 게이트웨이 프로필을 만든 후에 이 스크립트를 실행하십시오.
- 루트로 로그인하여 다음 디렉토리로 이동합니다.
gateway-install-root/SUNWps/bin/
- 다중 인스턴스 스크립트를 실행합니다.
./gwmultiinstance
다음 설치 옵션 중 하나를 선택합니다.
1) Create a new gateway instance
2) Remove a gateway instance
3) Remove all gateway instances
4) Exit
1을 선택한 경우 다음 질문에 답하십시오.
What is the name of the new gateway instance?
What protocol will the new gateway instance use?? [https]
What port will the new gateway instance listen on??
What is the fully qualified hostname of the portal server?
What port should be used to access the portal server?
What protocol should be used to access the portal server? [http]
What is the portal server deploy URI?
What is the organization DN? [dc=iportal,dc=com]
What is the Access Manager URI? [/amserver]
What is the Access Manager password encryption key?
직접 서명한 인증서를 만드는 데 필요한 다음 정보를 입력하십시오.
What is the name of your organization?
What is the name of your division?
What is the name of your city or locality?
What is the name of your state or province?
What is the two-letter country code?
What is the password for the Certificate Database? Again?
What is the password for the logging user? Again?
Have you created the new gateway profile in the admin console? [y]/n
Start the gateway after installation? [y]/n
- 새 게이트웨이 프로필 이름으로 게이트웨이의 새 인스턴스를 시작합니다.
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
여기서 gateway-profile-name 은 새 게이트웨이 인스턴스입니다.
게이트웨이 프로필 외에도 AMConfig-.instance-name.properties 파일이 /etc/opt/SUNWam/config 디렉토리에 만들어집니다.
platform.conf 파일에 portal.server.instance 등록 정보가 있으면 게이트웨이에서 그에 해당하는 AMConfig-instance-name.properties 파일을 읽습니다. platform.conf 파일에 portal.server.instance 등록 정보가 없으면 게이트웨이에서 기본 AMConfig 파일 (AMConfig.properties) 을 읽습니다.
다중 홈 게이트웨이 인스턴스 만들기
다중 홈 게이트웨이 인스턴스를 만드는 경우, 즉 한 Portal Server에 여러 게이트웨이를 만드는 경우에는 다음과 같이 platform.conf 파일을 수정해야 합니다.
gatewaybindipaddress = 0.0.0.0
같은 LDAP를 사용하여 게이트웨이 인스턴스 만들기
같은 LDAP를 사용하는 게이트웨이 인스턴스 여러 개를 만드는 경우에는 첫 게이트웨이를 만든 후에 그 뒤의 모든 게이트웨이에서 다음을 수행합니다.
/etc/opt/SUNWam/config/에서 AMConfig-instance-name.properties의 다음 영역을 처음 설치한 게이트웨이 인스턴스와 일치하도록 수정합니다.
- 암호의 암호화와 해독에 사용되는 키를 첫 게이트웨이와 같은 문자열로 대체합니다.
am.encryption.pwd= string_key_specified_in gateway-install
- 응용 프로그램 인증 모듈의 공유 비밀에 해당하는 키를 대체합니다.
com.iplanet.am.service.secret= string_key_specified_in gateway-install
- /etc/opt/SUNWam/config/ums에서 serverconfig.xml의 다음 영역을 처음 설치한 Portal-Identity Server와 다른 값으로 수정합니다.
<DirDN> cn=puser,ou=DSAME Users,dc=sun,dc=net</DirDN>
<DirPassword>string_key_specified_in gateway-install</DirPassword>
<DirDN>cn=dsameuser,ou=DSAME Users,dc=sun,dc=net</DirDN>
<DirPassword>string_key_specified_in gateway-install </DirPassword>
- amserver 서비스를 다시 시작합니다.
chroot 환경에서 게이트웨이 실행chroot 환경에서 보안을 강화하려면 chroot 디렉토리 컨텐트가 가능한 적어야 합니다. 예를 들어, 사용자가 chroot 디렉토리의 파일을 수정할 수 있는 프로그램이 있으면 chroot는 chroot 트리에서 파일을 수정하는 공격자로부터 서버를 보호하지 않습니다. CGI 프로그램은 bourne shell, c-shell, korn shell 또는 perl과 같은 해석된 언어로 작성하면 안 되며 해석자가 chroot 디렉토리 트리에 놓을 필요가 없도록 이진 형식으로 컴파일해야 합니다.
chroot를 설치하려면
- 루트로 로그인하고 단말기 창에서 다음 파일을 네트워크에 있는 컴퓨터나 백업 테이프 또는 플로피 디스크와 같은 외부 소스로 복사합니다.
cp /etc/vfstab external-device
cp /etc/nsswitch.conf external-device
cp /etc/hosts external-device
- 다음 디렉토리에서 mkchroot 스크립트를 실행합니다.
portal-server-install-root/SUNWps/bin/chroot
참고
실행되기 시작하면 mkchroot 스크립트는 Ctrl-C를 눌러 종료할 수 없습니다.
mkchroot 스크립트를 실행하는 동안 오류가 발생하면 mkchroot 스크립트의 실행 실패를 참조하십시오.
다른 루트 디렉토리를 입력하라는 메시지가 나타납니다 (new_root_directory). 스크립트에서 새 디렉토리를 만듭니다.
다음 예제에서는 /safedir/chroot가 new_root_directory입니다.
- platform.conf 파일에 언급된 Java 디렉토리를 다음 명령을 사용하여 수동으로 chroot 디렉토리에 마운트합니다.
mkdir -p /safedir/chroot/java-dir
mount -F lofs java-dir /safedir/chroot/java-dir
Solaris 9에서는 다음을 수행합니다.
mkdir -p /safedir/chroot/usr/lib/32
mount -F lofs /usr/lib/32 /safedir/chroot/usr/lib/32
mkdir -p /safedir/chroot/usr/lib/64
mount -F lofs /usr/lib/64 /safedir/chroot/usr/lib/64
시스템을 시작할 때 이 디렉토리를 마운트하려면 /etc/vfstab 파일에 해당 항목을 추가합니다.
java-dir - /safedir/chroot/java-dir lofs - no -
Solaris 9의 경우:
/usr/lib/32 - /safedir/chroot/usr/lib/32 lofs - no -
/usr/lib/64 - /safedir/chroot/usr/lib/64 lofs - no -
Linux
# mount red.iplanet.com:/misc/export /misc/local
여기서
red.iplanet.com은 NFS 파일 서버의 호스트 이름입니다.
/misc/export는 red.iplanet.com에서 내보내는 파일 시스템입니다.
/misc/local은 파일 시스템을 마운트할 로컬 시스템 위치입니다.
참고: 로컬 시스템의 마운트 지점 디렉토리 (위의 예에서 /misc/local) 는 반드시 존재해야 합니다.
마운트 명령이 실행되고 red.iplanet.com NFS 서버에서 적절한 클라이언트 권한을 할당 받은 후, 클라이언트 사용자가 명령 ls /misc/local을 실행하여 red.iplanet.com의 /misc/export에 있는 파일 목록을 표시할 수 있습니다.
- 아래 명령을 입력하여 게이트웨이를 다시 시작합니다.
mkchroot 스크립트의 실행 실패
mkchroot 스크립트를 실행하는 동안 오류가 발생하면 스크립트에서 파일을 초기 상태로 복원합니다.
다음 예제에서는 /safedir/chroot가 chroot 디렉토리입니다.
다음 오류 메시지가 발생한 경우,
Not a Clean Exit
- chroot를 설치하려면의 1단계에서 백업 파일을 원래 위치로 복사하고 다음 명령을 실행합니다.
umount /safedir/chroot/usr/java1.2
umount /safedir/chroot/proc
umount /safedir/chroot/dev/random
- /safedir/chroot 디렉토리를 제거합니다.
chroot 환경에서 게이트웨이 다시 시작게이트웨이 시스템을 재부트할 때마다 chroot 환경에서 게이트웨이를 시작하려면 다음 단계를 수행합니다.
chroot 환경에서 게이트웨이를 다시 시작하려면
게이트웨이 시작 및 중지기본적으로 게이트웨이는 사용자 noaccess로 시작됩니다.
게이트웨이를 시작하려면
- 게이트웨이를 설치하고 필요한 프로필을 만든 후 다음 명령을 실행하여 게이트웨이를 시작합니다.
gateway-install-root/SUNWps/bin/gateway -n default start
default는 설치 중에 만들어지는 기본 게이트웨이 프로필입니다. 나중에 고유한 프로필을 만들고 새 프로필로 게이트웨이를 다시 시작할 수 있습니다. 게이트웨이 프로필 만들기를 참조하십시오.
다중 게이트웨이 인스턴스가 있다면 다음을 사용합니다.
gateway-install-root/SUNWps/bin/gateway start
이 명령은 특정 컴퓨터에 구성된 모든 게이트웨이 인스턴스를 시작합니다.
참고
서버를 다시 시작하면 (게이트웨이의 인스턴스를 구성한 서버) 게이트웨이의 구성된 인스턴스가 모두 다시 시작됩니다.
/etc/opt/SUNWps 디렉토리에 기존 프로필이나 백업 프로필이 없어야 합니다.
게이트웨이를 중지하려면
게이트웨이 다시 시작일반적으로 게이트웨이를 다시 시작할 필요가 없습니다. 다음 이벤트가 발생한 경우에만 다시 시작합니다.
다른 프로필로 게이트웨이를 다시 시작하려면
게이트웨이를 다시 시작합니다.
gateway-install-root/SUNWps/bin/gateway -n new-gateway-profile-name start
게이트웨이를 다시 시작하려면
단말기 창에서 루트로 연결하고 다음 작업 중 하나를 수행합니다.
게이트웨이 워치독을 구성하려면
워치독이 게이트웨이의 상태를 모니터링하게 될 시간 간격을 설정할 수 있습니다. 시간 간격은 기본적으로 60초로 설정됩니다. 이 기본 설정을 변경하려면 crontab 유틸리티에서 다음 줄을 편집합니다.
0-59 * * * * gateway-install-root/SUNWps/bin/
/var/opt/SUNWps/.gw. 5 > /dev/null 2>&1
crontab 항목을 구성하려면 crontab man 페이지를 참조하십시오.
가상 호스트 지정가상 호스트는 같은 시스템 IP와 호스트 이름을 가리키는 추가 호스트 이름입니다. 예를 들어 호스트 이름 a.b.c가 호스트 IP 주소 192.155.205.133을 가리키는 경우, 같은 IP 주소를 가리키는 다른 호스트 이름 c.d.e를 추가할 수 있습니다.
가상 호스트를 지정하려면
- 루트로 로그인하여 필요한 게이트웨이 인스턴스의 platform.conf 파일을 편집합니다.
/etc/opt/SUNWps/platform.conf.gateway-profile-name
- 다음 항목을 추가합니다.
gateway.virtualhost=fully-qualified-gateway-host gateway-ip-address fully- qualified-reverse-proxyhost
gateway.enable.customurl=true (이 값은 기본적으로 false로 설정됩니다.)
- 게이트웨이를 다시 시작합니다.
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
값이 지정되어 있지 않으면 게이트웨이에서는 기본적으로 일반적인 작동을 합니다.
Access Manage에 접속할 프록시 지정게이트웨이에서 프록시 호스트를 사용하여 Portal Server에 배포되는 SRA 코어 (RemoteConfigServlet) 에 접속하도록 지정할 수 있습니다. 이 프록시는 게이트웨이가 Portal Server와 Access Manager에 접속하기 위해 사용됩니다.
프록시를 지정하려면
웹 프록시 사용타사 웹 프록시를 사용하여 HTTP 리소스에 연결하도록 게이트웨이를 구성할 수 있습니다. 웹 프록시는 클라이언트와 인터넷 사이에 상주합니다.
웹 프록시 구성
여러 도메인 및 부속 도메인에 서로 다른 프록시가 사용될 수 있습니다. 이 항목은 특정 도메인에서 특정 부속 도메인에 연결할 때 어떤 프록시를 사용할지 게이트웨이에 알려 줍니다. 게이트웨이에 지정된 프록시 구성은 다음과 같이 작동합니다.
도메인 및 부속 도메인의 프록시 구성에 대한 자세한 내용은 도메인 및 부속 도메인의 프록시 목록 만들기를 참조하십시오.
프록시 사용 옵션을 구성하려면 웹 프록시 사용 활성화를 참조하십시오.
그림 2-1은 게이트웨이 서비스의 프록시 구성에 기반하여 웹 프록시 정보가 어떻게 결정되는지 보여줍니다.
그림 2-1 웹 프록시 관리
그림 2-1에서 프록시 사용이 활성화되어 있고, 요청된 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을 사용해야 함을 나타냅니다.
웹 프록시 정보 처리
클라이언트에서 특정 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
게이트웨이는 표 2-2에 나와 있듯이 이 항목을 테이블에 내부적으로 매핑합니다.
표 2-2 도메인 및 부속 도메인의 프록시 목록에서 항목 매핑
번호
도메인 및 부속 도메인의 프록시 목록의 항목
프록시
설명
1
com
p1
목록에 지정된 대로
2
host1.com
p2
목록에 지정된 대로
3
host2.com
p1
host2에 대해 프록시가 지정되지 않았으므로 도메인의 프록시가 사용됩니다.
4
*.com
p3
목록에 지정된 대로
5
sesta.com
p4
목록에 지정된 대로
6
host5.sesta.com
p5
목록에 지정된 대로
7
*.sesta.com
p6
목록에 지정된 대로
8
florizon.com
직접
자세한 내용은 항목 14에 대한 설명 참조
9
host6.florizon.com
–
자세한 내용은 항목 14에 대한 설명 참조
10
abc.sesta.com
p8
목록에 지정된 대로.
11
host7.abc.sesta.com
p7
목록에 지정된 대로.
12
host8.abc.sesta.com
p8
목록에 지정된 대로.
13
*.abc.sesta.com
p9
목록에 지정된 대로 abc.sesta.com 도메인에서 host7과 host8을 제외한 모든 호스트에는 p9가 프록시로 사용됩니다.
14
host6.florizon.com
p10
이 항목은 항목 9와 동일합니다. 그러나 항목 9는 직접 연결을 나타내지만, 이 항목은 프록시 p10을 사용해야 함을 나타냅니다. 이 경우와 같이 2개 항목이 있는 경우에는 프록시 정보가 있는 항목이 유효한 항목으로 간주됩니다. 다른 항목은 무시됩니다.
15
host9.sesta.com
p11
목록에 지정된 대로.
16
siroe.com
직접
siroe.com에 대해 프록시가 지정되지 않았으므로 직접 연결을 시도합니다.
17
host12.siroe.com
p12
목록에 지정된 대로.
18
host13.siroe.com
p13
목록에 지정된 대로.
19
host14.siroe.com
직접
host14에 대해 프록시가 지정되지 않았으므로 직접 연결을 시도합니다.
20
*.siroe.com
p14
항목 23에 대한 설명 참조.
21
host15.siroe.com
p15
목록에 지정된 대로.
22
host16.siroe.com
직접
host16 또는 siroe.com에 대해 프록시가 지정되지 않았으므로 직접 연결을 시도합니다.
23
*.siroe.com
p16
이 항목은 항목 20과 비슷하지만 지정된 프록시가 다릅니다. 이런 경우 게이트웨이의 정확한 동작은 알 수 없습니다. 두 프록시 중 하나가 사용됩니다.
24
*
p17
요청된 URL과 일치하는 다른 항목이 없으면 p17이 프록시로 사용됩니다.
참고
[도메인 및 부속 도메인의 프록시] 목록에서 프록시 항목을 | 기호와 분리하는 것보다 목록에 개별 항목을 보유하는 것이 더 간단할 수 있습니다. 예를 들어, 다음과 같은 항목 대신에
sesta.com p1 | red p2 | * p3
이 항목을 다음과 같이 지정할 수 있습니다.
sesta.com p1
red.sesta.com p2
*.sesta.com p3
그러면 쉽게 반복되는 항목이나 기타 모호함의 범위를 좁힐 수 있습니다.
도메인 및 부속 도메인의 프록시 목록에 기반하여 다시 쓰기
[도메인 및 부속 도메인의 프록시] 목록의 항목도 Rewriter에서 사용됩니다. Rewriter는 도메인이 [도메인 및 부속 도메인의 프록시] 목록에 나열된 도메인과 일치하는 모든 URL을 다시 씁니다.
주의
[도메인 및 부속 도메인의 프록시] 목록의 * 항목은 다시 쓰기에 고려되지 않습니다. 예를 들어, 표 2-2에 나온 예제에서는 항목 24가 고려되지 않습니다.
Rewriter에 대한 자세한 내용은 3장, "Proxylet 및 Rewriter"를 참조하십시오.
기본 도메인 및 부속 도메인
URL의 대상 호스트가 정규 호스트 이름이 아닐 경우, 정규 이름에 도달하도록 기본 도메인 및 부속 도메인을 사용합니다.
관리 콘솔의 [기본 도메인] 필드 항목이 다음과 같다고 가정해 보겠습니다.
red.sesta.com
위의 예에서는 sesta.com이 기본 도메인이고 기본 부속 도메인은 red입니다.
요청된 URL이 host1인 경우, 기본 도메인 및 부속 도메인을 통해 host1.red.sesta.com으로 결정됩니다. 그런 다음 [도메인 및 부속 도메인의 프록시] 목록에 host1.red.sesta.com이 있는지 검색합니다.
자동 프록시 구성 사용[도메인 및 부속 도메인의 프록시] 목록에 있는 정보를 무시하려면 자동 프록시 구성 (PAC) 기능을 활성화합니다. 이를 구성하려면 자동 프록시 구성 지원 사용을 참조하십시오.
자동 프록시 구성 (PAC) 파일을 사용할 때에는 다음을 주의합니다.
- js.jar는 게이트웨이 컴퓨터의 $JRE_HOME/lib/ext 디렉토리에 있어야 합니다. 그렇지 않으면 게이트웨이에서 PAC 파일의 구문을 분석할 수 없습니다.
- 게이트웨이는 부팅 시에 게이트웨이 프로필 [자동 프록시 구성 파일] 위치 필드에 지정된 위치로부터 PAC 파일을 불러옵니다. 위치를 구성하려면 자동 프록시 구성 파일 위치 지정을 참조하십시오.
- 게이트웨이는 URLConnection API를 사용하여 이 위치에 도달합니다. 프록시가 게이트웨이에 도달하도록 구성해야 하는 경우에는 프록시를 다음과 같이 구성해야 합니다.
- 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가 반환되는 예제
도메인 및 부속 도메인에 이 프록시 사용:
해당하는 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 파일의 위치를 지정하는 형식은 다음과 같이 해당 위치에 따라 다릅니다.
별도 세션에서 서비스 추가Portal Server 서비스를 별도 세션에서 추가할 경우 다음을 확인하십시오.
- 모든 Portal Server가 관리 콘솔의 [게이트웨이] > [핵심] 아래에 나열됩니다. 자세한 내용은 Portal Server 목록 만들기 를 참조하십시오.
- 모든 Portal Server URL은 [게이트웨이] > [보안] 아래의 비인증 URL에 나열됩니다. 자세한 내용은 인증되지 않은 URL 목록 만들기 를 참조하십시오.
Netlet 프록시 사용Netlet 패킷은 게이트웨이에서 비밀번호가 해독되어 대상 서버로 보내집니다. 그러나 게이트웨이는 완충 지대 (DMZ) 와 인트라넷 사이의 방화벽을 통해 모든 Netlet 대상 호스트에 액세스해야 합니다. 그러려면 방화벽에서 많은 포트를 열어야 합니다. Netlet 프록시는 방화벽에서 열린 포트의 수를 줄이는 데 사용할 수 있습니다.
Netlet 프록시는 클라이언트로부터 게이트웨이를 거쳐 인트라넷에 상주하는 Netlet 프록시에 이르기까지 보안 터널을 확장하여 게이트웨이와 인트라넷 사이의 보안을 강화합니다. 프록시가 있으면 Netlet 패킷은 프록시에서 해독된 후 대상으로 보내집니다.
Netlet 프록시가 유용한 이유는 다음과 같습니다.
- 보안 계층을 추가할 수 있음
- 상당한 규모의 배치 환경에서 내부 방화벽을 통해 추가 IP 주소와 게이트웨이의 포트 사용을 최대한 줄일 수 있음
- 게이트웨이와 Portal Server 간 개방 포트 수를 1로 제한할 수 있음. 이 포트 수는 설치 시 구성 가능
- 클라이언트와 게이트웨이 사이의 보안 채널을 그림 2-2의 "Netlet 프록시가 구성되어 있는 경우" 부분에 나와 있듯이 Portal Server까지 확장할 수 있음. Netlet 프록시는 데이터 암호화를 통해 보안을 강화한다는 이점이 있지만 시스템 자원을 더 많이 사용할 수 있습니다. Netlet 프록시 설치에 대한 자세한 내용은 Sun Java Enterprise System 설치 설명서를 참조하십시오.
가능한 작업:
- Portal Server 노드나 별도 노드에 Netlet 프록시를 설치할 수 있습니다.
- 다중 Netlet 프록시를 설치하고 관리 콘솔을 사용하여 단일 게이트웨이에 구성할 수 있습니다. 이는 로드 균형 조정에 유용합니다. 자세한 내용은 Netlet 프록시 목록 활성화 및 만들기를 참조하십시오.
- 단일 시스템에 Netlet 프록시의 다중 인스턴스를 구성할 수 있습니다.
- 게이트웨이의 다중 인스턴스를 Netlet 프록시의 단일 설치에 지정할 수 있습니다.
- 웹 프록시를 통해 Netlet을 통과할 수 있습니다. 이를 구성하려면 웹 프록시를 통한 Netlet 터널링 활성화를 참조하십시오.
그림 2-2에는 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-2 Netlet 프록시 구현
Netlet 프록시의 인스턴스 만들기
Portal Server 노드나 별도 노드에 Netlet 프록시의 새 인스턴스를 만들려면 nlpmultiinstance 스크립트를 사용합니다. 게이트웨이 프로필을 만든 후에 이 스크립트를 실행하십시오.
- 루트로 로그인하여 다음 디렉토리로 이동합니다.
netlet-install-dir/SUNWps/bin
- 다중 인스턴스 스크립트를 실행합니다.
./nlpmultiinstance
- nlpmultiinstance 스크립트에서 나타나는 다음 질문에 답합니다.
- What is the name of the new netlet proxy instance?
- If you have a instance configured on this node with the same name, you are asked if you want to use the same configuration for this netlet proxy instance.
- If you answered yes, answer these two questions:
- If you answered no, answer the following questions:
- What protocol will the new netlet proxy instance use?
- What port will the new netlet proxy instance listen on?
- What is the name of your organization?
- What is the name of your division?
- What is the name of your city or locality?
- What is the name of your state or province?
- What is the two-letter country code?
- What is the password for the certificate Database?
- What is the password for the logging user?
- Have you created the new gateway profile in the admin console?
- If you answered yes, start the netlet proxy after installation?
- 새 게이트웨이 프로필 이름으로 Netlet 프록시의 새 인스턴스를 시작합니다.
netlet-proxy-install-root/SUNWps/bin/netletd -n gateway-profile-name start
여기서 gateway-profile-name은 필요한 게이트웨이 인스턴스에 해당하는 프로필 이름입니다.
Netlet 프록시 활성화
Access Manager 관리 콘솔의 SRA 구성에서 게이트웨이 서비스를 통해 Netlet 프록시를 활성화합니다. Netlet 프록시 목록 활성화 및 만들기를 참조하십시오.
Netlet 프록시 다시 시작
프록시가 예기치 않게 중지될 때마다 다시 시작하도록 Netlet 프록시를 구성할 수 있습니다. 워치독 프로세스를 예약하여 Netlet 프록시를 모니터하고, 프록시가 다운된 경우 다시 시작할 수 있습니다.
Netlet 프록시를 수동으로 다시 시작할 수도 있습니다.
Netlet 프록시를 다시 시작하려면
단말기 창에서 루트로 연결하고 다음 작업 중 하나를 수행합니다.
- 워치독 프로세스를 시작합니다.
netlet-proxy-install-root/SUNWps/bin/netletd watchdog on
그러면 crontab 유틸리티에 항목이 만들어지고 워치독 프로세스가 활성 상태가 됩니다. 워치독은 Netlet 프록시 포트를 모니터링하여 프록시가 다운되면 표시합니다.
- Netlet 프록시를 수동으로 시작합니다.
netlet-proxy-install-root/SUNWps/bin/netletd -n gateway-profile-name start
여기서 gateway-profile-name은 필요한 게이트웨이 인스턴스에 해당하는 프로필 이름입니다.
Netlet 프록시 워치독을 구성하려면
워치독이 Netlet 프록시의 상태를 모니터하는 시간 간격을 구성할 수 있습니다. 시간 간격은 기본적으로 60초로 설정됩니다. 이 설정을 변경하려면 crontab 유틸리티에서 다음 줄을 편집합니다.
0-59 * * * * netlet-install-dir/bin/checkgw /var/opt/SUNWps/.gw 5 > /dev/null 2>&1
Rewriter 프록시 사용Rewriter 프록시는 인트라넷에 설치됩니다. 게이트웨이는 컨텐트를 직접 검색하는 대신, 컨텐트를 가져와 게이트웨이로 반환하는 Rewriter 프록시로 모든 요청을 전달합니다.
Rewriter 프록시 사용을 통해 얻을 수 있는 이점은 다음과 같습니다.
Rewriter 프록시를 지정하지 않으면 사용자가 인트라넷 컴퓨터에 액세스하려고 할 때 게이트웨이 구성 요소에서 인트라넷 컴퓨터에 직접 연결합니다.
Rewriter 프록시를 로드 조정기로 사용하는 경우에는 Rewriter의 platform.conf.instance_name이 로드 조정기 URL을 가리키는지 확인해야 합니다. Portal Servers 목록에 로드 조정기 호스트가 지정되어 있는지도 확인해야 합니다.
각 게이트웨이 인스턴스 (포털 노드에 있지 않을 수도 있음) 에 대해 여러 개의 Rewriter 프록시 인스턴스가 있는 경우, Rewriter 프록시에 대한 단일 포트 항목을 입력하지 말고 platform.conf 파일에 host-name:port 형식으로 각 Rewriter 프록시 정보를 입력합니다.
Rewriter 프록시의 인스턴스 만들기
Portal Server 노드에 Rewriter 프록시의 새 인스턴스를 만들려면 rwpmultiinstance 스크립트를 사용합니다. 게이트웨이 프로필을 만든 후에 이 스크립트를 실행하십시오.
- 루트로 로그인하여 다음 디렉토리로 이동합니다.
rewriter-proxy-install-root/SUNWps/bin
- 다중 인스턴스 스크립트를 실행합니다.
./rwpmultiinstance
- 스크립트에서 나타나는 질문에 답합니다.
- What is the name of the new rewriter proxy instance?
- If you have a rewriter proxy instance configured on this node with the same name, you are asked if you want to use the same configuration for this rewriter proxy instance.
- If you answered yes, answer these two questions:
- If you answered no, answer the following questions:
- What protocol will the new rewriter proxy instance use?
- What port will the new rewriter proxy instance listen on?
- What is the name of your organization?
- What is the name of your division?
- What is the name of your city or locality?
- What is the name of your state or province?
- What is the two-letter country code?
- What is the password for the certificate Database?
- What is the password for the logging user?
- Have you created the new gateway profile in the admin console?
- If you answered yes, start the rewriter proxy after installation?
- 새 게이트웨이 프로필 이름으로 rewriter 프록시의 새 인스턴스를 시작합니다.
rewriter-proxy-install-root/SUNWps/bin/rwproxyd -n gateway-profile-name start
여기서 gateway-profile-name은 필요한 게이트웨이 인스턴스에 해당하는 프로필 이름입니다.
Rewriter 프록시 활성화
Access Manager 관리 콘솔의 SRA 구성에서 게이트웨이 서비스를 통해 Rewriter 프록시를 활성화합니다. Rewriter 프록시 목록 사용과 만들기를 참조하십시오.
Rewriter 프록시 다시 시작
프록시가 예기치 않게 중지될 때마다 다시 시작하도록 Rewriter 프록시를 구성할 수 있습니다. 모니터할 워치독 프로세스를 예약하고 이 경우가 발생했을 때 다시 시작할 수 있습니다.
Rewriter 프록시를 수동으로 다시 시작할 수도 있습니다.
Rewriter 프록시를 다시 시작하려면
단말기 창에서 루트로 연결하고 다음 작업 중 하나를 수행합니다.
- 워치독 프로세스를 시작합니다.
rewriter-proxy-install-root/SUNWps/bin/rwproxd watchdog on
그러면 crontab 유틸리티에 항목이 만들어지고 워치독 프로세스가 활성 상태가 됩니다. 워치독은 포트를 모니터링하여 프록시가 다운되면 표시합니다.
- 수동으로 시작합니다.
rewriter-proxy-install-root/SUNWps/bin/rwproxd -n gateway-profile-name start
여기서 gateway-profile-name은 필요한 게이트웨이 인스턴스에 해당하는 프로필 이름입니다.
Rewriter 프록시 워치독을 구성하려면
워치독이 Rewriter 프록시 상태를 모니터링하는 시간 간격을 구성할 수 있습니다. 시간 간격은 기본적으로 60초로 설정됩니다. 이 설정을 변경하려면 crontab 유틸리티에서 다음 줄을 편집합니다.
0-59 * * * * rewriter-proxy-install-root/bin/checkgw /var/opt/SUNWps/.gw 5 > /dev/null 2>&1
게이트웨이에서 역 프록시 사용프록시 서버는 인트라넷에 인터넷 컨텐트를 서비스하고 역 프록시는 인터넷에 인트라넷 컨텐트를 서비스합니다. 인터넷 컨텐트를 제공하며 로드 균형 조정과 캐싱을 수행하도록 역 프록시를 배포할 수 있습니다.
이 배포에서 게이트웨이 전방에 타사의 역 프록시가 사용된다면 게이트웨이의 URL 대신 역 프록시의 URL로 응답을 다시 써야 합니다. 이를 위해 다음 구성이 필요합니다.
역 프록시를 활성화하려면
- 루트로 로그인하여 필요한 게이트웨이 인스턴스의 platform.conf 파일을 편집합니다.
/etc/opt/SUNWps/platform.conf.gateway-profile-name
- 다음 항목을 추가합니다.
gateway.virtualhost=fully-qualified-gateway-host gateway-ip-address fully- qualified-reverse-proxyhost
gateway.enable.customurl=true (이 값은 기본적으로 false로 설정됩니다.)
gateway.httpurl=http reverse-proxy-URL
gateway.httpsurl=https reverse-proxy-URL
gateway.httpurl은 게이트웨이 프로필에서 HTTP 포트로 나열된 포트에서 수신된 요청에 대한 응답을 다시 쓰는 데 사용됩니다.
gateway.httpsurl은 게이트웨이 프로필에서 HTTPS 포트로 나열된 포트에서 수신된 요청에 대한 응답을 다시 쓰는 데 사용됩니다.
- 게이트웨이를 다시 시작합니다.
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
값이 지정되어 있지 않으면 게이트웨이에서는 기본적으로 일반적인 작동을 합니다.
클라이언트 정보 가져오기게이트웨이에서 클라이언트 요청을 임의 서버로 전달할 때 HTTP 헤더를 HTTP 요청에 추가합니다. 이 헤더를 사용하여 추가 클라이언트 정보를 가져오고 게이트웨이가 있는지 감지할 수 있습니다.
HTTP 요청 헤더를 보려면 platform.conf 파일의 항목을 gateway.error=message로 설정한 다음 servlet API에서 request.getHeader()를 사용합니다. 다음 표에는 HTTP 헤더에 있는 정보가 나열되어 있습니다.
표 2-3 HTTP 헤더의 정보
헤더
구문
설명
PS-GW-PDC
X-PS-GW- PDC: true/false
게이트웨이에서 PDC의 사용 가능 여부를 나타냅니다.
PS-Netlet
X-PS-Netlet:enabled=true/false
게이트웨이에서 Netlet의 사용 가능 여부를 나타냅니다.
Netlet이 활성화된 경우 암호화 옵션이 채워져서 게이트웨이가 HTTPS (encryption=ssl) 또는 HTTP 모드 (encryption=plain) 중 어느 쪽에서 실행 중인지 보여줍니다.
예:
PS-Netlet: enabled=false
Netlet이 사용 불가능 상태입니다.
PS-Netlet: enabled=true; encryption=ssl
게이트웨이가 SSL 모드에서 실행되며 Netlet이 활성화되었습니다.
Netlet이 활성화되지 않은 경우에는 encryption=ssl/plain이 채워지지 않습니다.
PS-GW-URL
X-PS-GW-URL: http(s)://gatewayURL(:port)
클라이언트가 연결된 URL을 나타냅니다.
비표준 포트인 경우 (즉, 포트 80/443이 아닌 상태로 게이트웨이가 HTTP/HTTPS 모드에 있는 경우) ":port"도 채워집니다.
PS-GW-Rewriting-URL
X-PS-GW-URL: http(s)://gatewayURL(:port)/[SessionInfo]
게이트웨이가 모든 페이지를 다시 쓰는 URL을 나타냅니다.
참고: 응답의 일부로 사용자의 Access Manager sessionId가 변경되면 (인증 페이지에서 오는 응답과 같이) 페이지는 이전에 헤더에 표시된 값이 아닌 그 값으로 다시 쓰여집니다.
예:
PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/
PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/SessIDValCustomEncodedValue/
PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/$SessionID
PS-GW-CLientIP
X-PS-GW-CLientIP: IP
게이트웨이가 recievedSocket.getInetAddress().getHostAddress()로부터 가져온 IP입니다.
이 IP는 게이트웨이에 직접 연결되면 클라이언트의 IP가 됩니다.
인증 체이닝 사용인증 체이닝은 인증의 일반 메커니즘에서 보안을 한층 높은 수준으로 강화합니다. 사용자가 2개 이상 인증 메커니즘에 대해 인증 받도록 설정할 수 있습니다.
여기에 설명된 절차는 게이트웨이에서 개인 디지털 인증서 (PDC) 인증과 함께 인증 체이닝을 사용하는 경우에만 적용됩니다. 게이트웨이에서 PDC 인증을 사용하지 않는 인증 체이닝에 대한 자세한 내용은 Access Manager 관리 설명서를 참조하십시오.
예를 들어, PDC 및 Radius 인증 모듈을 체이닝한 경우에는 사용자가 표준 포털 데스크탑에 액세스하려면 이 3개 모듈에 대한 인증을 모두 거쳐야 합니다.
기존 PDC 인스턴스에 인증 모듈을 추가하려면
- Access Manager 관리 콘솔에 관리자로 로그인합니다.
- 필요한 조직을 선택합니다.
- [보기] 드롭다운 메뉴에서 [서비스]를 선택합니다.
왼쪽 창에 서비스가 표시됩니다.
- [인증 구성] 옆의 화살표를 누릅니다.
서비스 인스턴스 목록이 표시됩니다.
- gatewaypdc를 누릅니다.
Gatewaypdc 속성 페이지가 표시됩니다.
- [인증 구성] 앞의 [편집]을 누릅니다.
[모듈 추가]가 나타납니다.
- [모듈 이름]을 선택하고 [플래그]를 [필요]로 설정합니다. 빈 칸으로 남겨둬도 됩니다.
- [확인]을 누릅니다.
- 모듈을 하나 이상 추가한 다음 [저장]을 누릅니다.
- gatewaypdc 등록 정보 페이지에서 [저장]을 누릅니다.
- 변경 내용을 적용하려면 게이트웨이를 다시 시작합니다.
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
와일드카드 인증 사용와일드카드 인증에서는 정규 DNS 호스트 이름에 와일드카드 문자가 있는 단일 인증을 수락합니다.
그러면 같은 도메인에서 여러 호스트에 인증을 허용할 수 있습니다. 예를 들어, *.domain.com에 대한 인증을 abc.domain.com 및 abc1.domain.com에 사용할 수 있습니다. 사실 이 인증은 domain.com 도메인에 있는 모든 호스트에 유효합니다.
브라우저 캐싱 사용 불가능게이트웨이 구성 요소는 웹 브라우저를 사용하여 어느 위치에서나 백엔드 기업 데이터에 안전하게 액세스하므로 클라이언트에 의해 정보가 로컬로 캐싱되지 않아야 합니다.
특정 게이트웨이의 platform.conf 파일에 있는 속성을 수정하여 게이트웨이를 통해 리디렉션된 페이지의 캐싱을 비활성화할 수 있습니다.
이 옵션을 비활성화하면 게이트웨이 성능에 영향을 줄 수 있습니다. 표준 포털 데스크탑을 새로 고칠 때마다 게이트웨이는 브라우저에서 이전에 캐싱한 이미지와 같이 페이지에서 참조되는 모든 항목을 검색해야 합니다. 그러나 이 기능을 성화면 원격 액세스 보안 컨텐트가 클라이언트 사이트에 캐싱된 풋프린트를 남기지 않습니다. 기업 네트워크가 인터넷 카페에서, 또는 기업 IT 제어를 받지 않는 유사한 원격 위치에서 액세스되는 경우 이 이점은 성능상의 불이익보다 훨씬 큽니다.
브라우저 캐싱을 비활성화하려면
- 루트로 로그인하여 필요한 게이트웨이 인스턴스의 platform.conf 파일을 편집합니다.
/etc/opt/SUNWps/platform.conf.gateway-profile-name
- 다음 라인을 편집합니다.
gateway.allow.client.caching=true
이 값은 기본적으로 true로 설정되어 있습니다. 값을 false로 변경하여 클라이언트 쪽에서 브라우저 캐싱을 비활성화합니다.
- 게이트웨이를 다시 시작합니다.
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
게이트웨이 서비스 사용자 인터페이스 사용자 정의이 절에서는 편집할 수 있는 여러 등록 정보 파일에 대해 설명합니다.
srapGateway.properties 파일
다음과 같은 목적으로 이 파일을 편집할 수 있습니다.
srapgwadminmsg.properties 파일
다음과 같은 이유로 이 파일을 편집할 수 있습니다.
LDAP 디렉토리 공유Portal Server 및 Access Manager 서버의 두 인스턴스가 같은 LDAP 디렉토리를 공유하는 경우 모든 후속 Portal Server, Access Manager 및 게이트웨이에 대해 다음 해결 방법을 사용하십시오.
#The key that will be used to encrypt and decrypt passwords. am.encryption.pwd=t/vnY9Uqjf12NbFywKuAaaHibwlDFNLO <== 이 문자열을 첫 번째 포털을 설치했을 때의 문자열로 바꾸십시오.
/* The following key is the shared secret for application auth module */ com.iplanet.am.service.secret=AQICxIPLNc0WWQRVlYZN0PnKgyvq3gTU8JA9 <== 이 문자열을 첫 번째 포털을 설치했을 때의 문자열로 바꾸십시오.
- /etc/opt/SUNWam/config/ums에서 serverconfig.xml의 다음 영역을 처음 설치한 Portal Server 및 Access Manager 서버와 동기화되도록 수정합니다.
<DirDN>
cn=puser,ou=DSAME Users,dc=sun,dc=net
</DirDN>
<DirPassword>
AQICxIPLNc0WWQT22gQnGgnCp9rUf+FuaqpY <== 이 문자열을 첫 번째 포털을 설치했을 때의 문자열로 바꾸십시오.
</DirPassword>
<DirDN>
cn=dsameuser,ou=DSAME Users,dc=sun,dc=net
</DirDN>
<DirPassword>
AQICxIPLNc0WWQT22gQnGgnCp9rUf+FuaqpY <== 이 문자열을 첫 번째 포털을 설치했을 때의 문자열로 바꾸십시오.
</DirPassword>
- amserver 서비스를 다시 시작합니다.
연합 관리 사용연합 관리를 사용하면 사용자가 하나의 네트워크 아이디를 가질 수 있도록 로컬 아이디를 집계할 수 있습니다. 연합 관리에서는 네트워크 아이디를 사용하여 사용자가 한 서비스 공급자의 사이트에 로그인할 경우 아이디를 재인증 받지 않고도 다른 서비스 공급자의 사이트에 액세스할 수 있도록 해 줍니다. 이를 단일 사인온이라 합니다.
연합 관리는 Portal Server에서 개방 모드 및 보안 모드로 구성할 수 있습니다. Portal Server 관리 설명서에서는 개방 모드로 연합 관리를 구성하는 방법에 대해 설명합니다. 연합 관리를 Secure Remote Access 를 사용하여 보안 모드에서 구성하려면 열린 모드에서 올바로 작동하는지 확인해야 합니다. 사용자가 같은 브라우저에서 개방 모드와 보안 모드 모두에 대해 연합 관리를 사용할 수 있도록 하려면 쿠키를 지우고 브라우저로부터 캐싱해야 합니다.
연합 관리에 대한 자세한 내용은 Access Manager Federation Management Guide를 참조하십시오.
연합 관리 시나리오
사용자가 최초 서비스 공급자에게 인증을 받습니다. 서비스 공급자는 웹 기반 서비스를 제공하는 상업적 조직이거나 비영리 조직을 말합니다. 이렇게 넓은 범주에는 인터넷 포털, 대리점, 운송 공급자, 금융 기관, 엔터테인먼트 회사, 도서관, 대학 및 정부 기관이 모두 포함될 수 있습니다.
서비스 공급자는 쿠키를 사용하여 클라이언트 브라우저에 사용자의 세션 정보를 저장합니다. 쿠키에도 사용자의 아이디 공급자가 포함될 수 있습니다.
아이디 공급자는 인증 서비스를 전문적으로 제공하는 서비스 공급자를 말합니다. 인증을 위한 관리 서비스로 아이디 공급자는 아이디 정보를 유지 관리하기도 합니다. 아이디 공급자에 의해 허가된 인증은 제휴 관계에 있는 모든 서비스 공급자에게 유효합니다.
사용자가 아이디 공급자와 제휴되지 않은 서비스에 액세스하려고 하면 아이디 공급자는 쿠키를 제휴되지 않은 서비스 공급자에게 전달합니다. 그런 다음 이 서비스 공급자가 쿠키에 명명된 아이디 공급자에게 액세스할 수 있습니다.
그러나 쿠키는 여러 DNS 도메인에서 읽을 수 없기 때문에 서비스 공급자를 올바른 아이디 공급자에게 리디렉션하여 사용자에게 단일 사인온이 가능하도록 공용 도메인 쿠키 서비스를 사용합니다.
연합 관리 리소스 구성
연합 자원, 서비스 공급자, 아이디 공급자 및 공용 도메인 쿠키 서비스 (CDCS) 는 상주해 있는 위치를 기준으로 게이트웨이 프로필에 구성됩니다. 이 절에서는 3가지 시나리오를 구성하는 방법에 대해 설명합니다.
구성 1
이 구성에서는 서비스 공급자, 아이디 공급자 및 공용 도메인 쿠키 서비스가 같은 기업 인트라넷에 배치되고 아이디 공급자는 인터넷 DNS (Domain Name Server) 에 게시되지 않습니다. CDCS는 선택 사항입니다.
이 구성에서는 게이트웨이가 Portal Server가 되는 서비스 공급자를 지정합니다. 이 구성은 Portal Server의 다중 인스턴스에 유효합니다.
- Access Manager 관리 콘솔에 관리자로 로그인합니다.
- 관리 콘솔에서 [서비스 구성] 탭을 선택합니다.
- SRA 구성 아래에서 게이트웨이 옆에 있는 화살표를 누릅니다.
게이트웨이 페이지가 표시됩니다.
- 속성을 설정할 게이트웨이 프로필을 누릅니다.
게이트웨이 프로필 편집 페이지가 표시됩니다.
- [핵심] 탭을 누릅니다.
- [쿠키 관리 사용] 확인란을 선택하고 쿠키 관리의 사용을 활성화합니다.
- [보안] 탭을 누릅니다.
- Portal Servers 필드로 스크롤하고 Portal Server 이름을 입력하여 인증되지 않은 URL 목록에 나열된 /amserver 또는 /portal/dt 등의 관련 URL을 사용할 수 있도록 합니다. 예:
http://idp-host:port/amserver/js
http://idp-host:port/amserver/UI/Login
http://idp-host:port/amserver/css
http://idp-host:port/amserver/SingleSignOnService
http://idp-host:port/amserver/UI/blank
http://idp-host:port/amserver/postLogin
http://idp-host:port/amserver/login_images
- Portal Server 필드로 스크롤하여 Portal Server 이름을 입력합니다. 예를 들어 /amserver를 입력합니다.
- [저장]을 누릅니다.
- [보안] 탭을 누릅니다.
- 인증되지 않은 URL 목록으로 스크롤하여 연합 리소스를 추가합니다. 예:
/amserver/config/federation
/amserver/IntersiteTransferService
/amserver/AssertionConsumerservice
/amserver/fed_images
/amserver/preLogin
/portal/dt
- [추가]를 누릅니다.
- [저장]을 누릅니다.
- 웹 프록시에서 인증되지 않은 URL 목록에 나열된 URL에 접속이 필요하면 [프록시] 탭을 누릅니다.
- [도메인 및 부속 도메인의 프록시] 필드로 스크롤하여 필요한 웹 프록시를 입력합니다.
- [추가]를 누릅니다.
- [저장]을 누릅니다.
- 터미널 창에서 게이트웨이를 다시 시작합니다.
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
구성 2
이 구성에서는 아이디 공급자, 아이디 공급자 및 공용 도메인 쿠키 공급자 (CDCP) 가 같은 기업 인트라넷에 배치되지 않았거나 아이디 공급자가 인터넷에 상주하는 타사 공급자입니다.
이 구성에서는 게이트웨이가 Portal Server가 되는 서비스 공급자를 지정합니다. 이 구성은 Portal Server의 다중 인스턴스에 유효합니다.
- Access Manager 관리 콘솔에 관리자로 로그인합니다.
- 관리 콘솔에서 [서비스 구성] 탭을 선택합니다.
- SRA 구성 아래에서 게이트웨이 옆에 있는 화살표를 누릅니다.
게이트웨이 페이지가 표시됩니다.
- 속성을 설정할 게이트웨이 프로필을 누릅니다.
게이트웨이 프로필 편집 페이지가 표시됩니다.
- [핵심] 탭을 누릅니다.
- [쿠키 관리 사용] 확인란을 선택하고 쿠키 관리의 사용을 활성화합니다.
- Portal Servers 필드로 스크롤하고 서비스 공급자 Portal Server 이름을 입력하여 인증되지 않은 URL 목록에 나열된 /amserver 또는 /portal/dt 등의 관련 URL을 사용할 수 있도록 합니다.
http://idp-host:port/amserver/js
http://idp-host:port/amserver/UI/Login
http://idp-host:port/amserver/css
http://idp-host:port/amserver/SingleSignOnService
http://idp-host:port/amserver/UI/blank
http://idp-host:port/amserver/postLogin
http://idp-host:port/amserver/login_images
- [저장]을 누릅니다.
- [보안] 탭을 누릅니다.
- 인증되지 않은 URL 목록으로 스크롤하여 연합 리소스를 추가합니다. 예:
/amserver/config/federation
/amserver/IntersiteTransferService
/amserver/AssertionConsumerservice
/amserver/fed_images
/amserver/preLogin
/portal/dt
- [추가]를 누릅니다.
- [저장]을 누릅니다.
- 웹 프록시에서 인증되지 않은 URL 목록에 나열된 URL에 접속이 필요하면 [프록시] 탭을 누릅니다.
- [도메인 및 부속 도메인의 프록시] 필드로 스크롤하여 필요한 웹 프록시를 입력합니다.
- [추가]를 누릅니다.
- [저장]을 누릅니다.
- 터미널 창에서 게이트웨이를 다시 시작합니다.
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
구성 3
이 구성에서는 아이디 공급자, 아이디 공급자 및 공용 도메인 쿠키 공급자 (CDCP) 가 같은 기업 인트라넷에 배치되지 않았거나 서비스 공급자가 인터넷에 상주하는 타사이고 아이디 공급자는 게이트웨이에 의해 보호됩니다.
이 구성에서는 게이트웨이가 Portal Server가 되는 아이디 공급자를 지정합니다.
이 구성은 Portal Server의 다중 인스턴스에 유효합니다. 이 구성은 인터넷에서는 구현되는 경우가 거의 없지만 어떤 기업 네트워크에는 인트라넷에 이러한 구성이 있을 수 있습니다. 즉, 아이디 공급자는 방화벽으로 보호되는 서브넷에 있고 서비스 공급자는 기업 네트워크 내에서 직접 액세스 가능한 경우를 말합니다.
- Access Manager 관리 콘솔에 관리자로 로그인합니다.
- 관리 콘솔에서 [서비스 구성] 탭을 선택합니다.
- SRA 구성 아래에서 게이트웨이 옆에 있는 화살표를 누릅니다.
게이트웨이 페이지가 표시됩니다.
- 속성을 설정할 게이트웨이 프로필을 누릅니다.
게이트웨이 프로필 편집 페이지가 표시됩니다.
- [핵심] 탭을 누릅니다.
- [쿠키 관리 사용] 확인란을 선택하고 쿠키 관리의 사용을 활성화합니다.
- Portal Servers 필드로 스크롤하고 아이디 공급자 Portal Server 이름을 입력하여 인증되지 않은 URL 목록에 나열된 /amserver 또는 /portal/dt 등의 관련 URL을 사용할 수 있도록 합니다.
http://idp-host:port/amserver/js
http://idp-host:port/amserver/UI/Login
http://idp-host:port/amserver/css
http://idp-host:port/amserver/SingleSignOnService
http://idp-host:port/amserver/UI/blank
http://idp-host:port/amserver/postLogin
http://idp-host:port/amserver/login_images
- [저장]을 누릅니다.
- [보안] 탭을 누릅니다.
- 인증되지 않은 URL 목록으로 스크롤하여 연합 리소스를 추가합니다. 예:
/amserver/config/federation
/amserver/IntersiteTransferService
/amserver/AssertionConsumerservice
/amserver/fed_images
/amserver/preLogin
/portal/dt
- [추가]를 누릅니다.
- [저장]을 누릅니다.
- 웹 프록시에서 인증되지 않은 URL 목록에 나열된 URL에 접속이 필요하면 [프록시] 탭을 누릅니다.
- [도메인 및 부속 도메인의 프록시] 필드로 스크롤하여 필요한 웹 프록시를 입력합니다.
- [추가]를 누릅니다.
- [저장]을 누릅니다.
- 터미널 창에서 게이트웨이를 다시 시작합니다.
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
