Sun logo      이전      목차      색인      다음     

Sun ONE Portal Server, Secure Remote Access 6.2 관리자 설명서

2 장
게이트웨이

이 장에서는 게이트웨이 관련 개념과 게이트웨이의 원활한 실행에 필요한 정보를 설명합니다. 게이트웨이 구성에 대한 자세한 내용은 9 장, "게이트웨이 구성"을 참조하십시오.

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

게이트웨이의 개요

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

게이트웨이 프로필 만들기

게이트웨이 프로필에는 게이트웨이가 수신하는 포트, SSL 옵션 및 프락시 옵션과 같이 게이트웨이 구성에 관련된 모든 정보가 들어 있습니다.

게이트웨이를 설치할 때 기본 값을 선택하면 "기본"이라는 기본 게이트웨이 프로필이 만들어집니다. 기본 프로필에 해당하는 구성 파일은 다음 위치에 있습니다.

/etc/opt/SUNWps/platform.conf.default

여기서 /etc/opt/SUNWps는 모든 platform.conf.* 파일을 위한 기본 위치입니다.

platform.conf 파일 내용에 대한 자세한 내용은 "platform.conf 파일 이해"를 참조하십시오.

가능한 작업:

주의

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

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

    게이트웨이 프로필을 만들려면
  1. Sun™ ONE Identity Server 관리 콘솔에 관리자로 로그인합니다.
  2. [서비스 구성] 탭을 선택합니다.
  3. SRA 구성 아래에서 게이트웨이 옆에 있는 화살표를 클릭합니다.

    4. 오른쪽 창에 게이트웨이 페이지가 표시됩니다.

  4. [새로 만들기]를 클릭합니다.

    5. 새 게이트웨이 프로필 만들기 페이지가 표시됩니다.

  5. 새 게이트웨이 프로필의 이름을 입력합니다.
  6. 드롭다운 목록에서 새 프로필을 만들 때 사용할 프로필을 선택합니다.

    7. 기본적으로 만들어지는 새 프로파일은 모두 사전 제공된 기본 프로파일을 기준으로 합니다. 사용자 정의 프로필을 만든 경우 드롭다운 목록에서 그 프로필을 선택할 수 있습니다. 새 프로필은 선택한 프로필의 모든 속성을 상속합니다.

  7. [만들기]를 클릭합니다.

    8. 새 프로필이 만들어지고 게이트웨이 페이지로 돌아가면 거기에 새 프로필이 나열됩니다.

  8. 변경 사항을 적용하려면 이 게이트웨이 프로필 이름이 있는 게이트웨이를 다시 시작합니다.

    9. 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

표 2-1에는 platform.conf 파일에 있는 모든 필드가 나열되고 이에 대한 설명이 나와 있습니다. 이 표에는 3개의 열이 있습니다. 첫 번째 열에는 파일의 항목이 나열되며 두 번째 열에는 기본값이 있는 경우 이 값이 나타나고 세 번째 열에는 필드가 간략하게 설명되어 있습니다.

표 2-1  platform.conf 파일 속성

항목

기본값

설명

gateway.user

noaccess

게이트웨이가 이 사용자로 실행됩니다.

게이트웨이는 루트로 시작되어야 하며 초기화 후에는 이 사용자가 되는 루트 권한을 상실합니다.

gateway.jdk.dir

 

게이트웨이에서 사용하는 JDK 디렉토리의 위치입니다.

gateway.dsame.agent

 

이 프로필을 얻을 수 있도록 시작하는 중에 게이트웨이에서 접촉하게 되는 Identity Server의 URL입니다.

portal.server.
protocol

portal.server.host

portal.server.port

 

기본 Portal Server 설치에서 사용하는 프로토콜, 호스트 및 포트입니다.

gateway.protocol
gateway.host
gateway.port

 

게이트웨이 프로토콜, 호스트 및 포트입니다. 이 값은 설치 시 지정한 모드 및 포트와 동일합니다. 이 값은 알림 URL을 구성하는 데 사용됩니다.

gateway.trust_all_
server_certs

true

게이트웨이에서 모든 서버 인증서를 신뢰해야 하는지 아니면 게이트웨이 인증서 데이터베이스에 있는 서버 인증서만 신뢰해야 하는지 나타냅니다.

gateway.trust_all_
server_cert_domains

false

게이트웨이와 서버 사이에 SSL 통신이 있을 때마다 서버 인증서가 게이트웨이에 제공됩니다. 기본적으로 게이트웨이는 서버 호스트 이름이 서버 인증서 CN과 같은지 확인합니다.

이 속성 값이 true로 설정되어 있으면 게이트웨이에서는 수신하는 서버 인증서에 대해 도메인 확인을 사용하지 않습니다.

gateway.virtualhost

 

게이트웨이 컴퓨터에 구성된 호스트 이름이 여러 개 있을 경우 이 필드에서 이름을 다르게 지정하여 공급자 주소를 구분할 수 있습니다.

gateway.virtualhost.defaultOrg=org

 

사용자가 로그인할 기본 조직을 지정합니다.

예를 들어 가상 호스트 필드 항목이 다음과 같다고 가정해 봅시다.

gateway.virtualhost=test.com employee.test.com

Managers.test.com

기본 조직 항목이 다음과 같음:

test.com.defaultOrg = o=root,dc=test,dc=com

employee.test.com.defaultOrg = o=employee,dc=test,dc=com

Manager.test.com.defaultOrg = o=Manager,dc=test,dc=com

사용자는 https://manager.test.com을 통해 https://test.com/o=Manager,dc=test,dc=com 대신 관리자 조직에 로그인할 수 있습니다.

참고: virtualhost 및 defaultOrg는 platform.conf file에서는 대소문자가 구별되지만 URL에 사용할 때는 구별되지 않습니다.

gateway.
notification.url

 

게이트웨이 호스트, 프로토콜 및 포트 조합은 알림 URL을 구성하는 데 사용됩니다. 이 조합은 Identity Server의 세션 알림을 수신하는 데 사용됩니다.

알림 URL은 다른 조직 이름과 같지 않도록 합니다. 알림 URL은 조직 이름과 일치하므로 해당 조직에 연결을 시도하는 사용자에게는 로그인 페이지 대신 공백 페이지가 나타납니다.

gateway.retries

 

시작하는 중에 게이트웨이에서 Portal Server에 접촉하고자 시도하는 횟수를 말합니다.

gateway.debug

error

게이트웨이의 디버그 수준을 설정합니다. 디버그 파일은 debug-directory/files에 있습니다. 디버그 파일 위치는 gateway.debug.dir 항목에 지정되어 있습니다.

디버깅 수준은 다음과 같습니다.

오류 - 디버그 파일에 심각한 오류만 기록됩니다. 일반적으로 이러한 오류가 발생하면 게이트웨이는 기능이 중단됩니다.

경고 - 경고 메시지가 기록됩니다.

메시지 - 모든 디버그 메시지가 기록됩니다.

날짜 - 모든 디버그 메시지가 콘솔에 표시됩니다.

디버그 파일은 다음과 같습니다.

srapGateway.gateway-profile-name - 게이트웨이 디버그 메시지가 들어 있습니다.

Gateway_to_from_server.gateway-profile-name - 메시지 모드에서는 이 파일에 게이트웨이와 내부 서버 사이의 모든 요청 및 응답 헤더가 들어 있습니다.

이 파일을 생성하려면 /var/opt/SUNWps/debug 디렉토리에서 쓰기 권한을 변경합니다.

Gateway_to_from_server.gateway-profile-name - 메시지 모드에서는 이 파일에 게이트웨이와 클라이언트 브라우저 사이의 모든 요청 및 응답 헤더가 들어 있습니다.

이 파일을 생성하려면 /var/opt/SUNWps/debug 디렉토리에서 쓰기 권한을 변경합니다.

gateway.debug.dir

 

여기는 모든 디버그 파일이 생성되는 디렉토리입니다.

이 디렉토리에는 gateway.user에서 언급된 사용자가 파일에 쓸 수 있도록 충분한 권한을 가지고 있어야 합니다.

gateway.
logdelimiter

 

현재 사용되지 않음.

gateway.external.ip

 

다중 홈 게이트웨이 컴퓨터인 경우(IP 주소가 여러 개) 여기서 외부 IP 주소를 지정해야 합니다. 이 IP는 Netlet에서 FTP를 실행하는 데 사용됩니다.

gateway.certdir

 

인증서 데이터베이스의 위치를 지정합니다.

gateway.allow.
client.caching

true

클라이언트 캐싱을 허용하거나 허용 불가합니다.

허용되는 경우 클라이언트 브라우저는 동적 페이지와 이미지를 캐싱하여 성능을 향상시킵니다(네트워크 트래픽 감소를 통해).

허용되지 않는 경우 보안이 철저해서 클라이언트 쪽에서는 아무 것도 캐싱되지 않으므로 네트워크 로드가 많을 경우에는 성능 저하가 생깁니다.

gateway.userProfile.cacheSize

 

게이트웨이에서 캐싱되는 사용자 프로필 항목의 수입니다. 항목 수가 이 값을 초과하면 캐시를 정리하는 재시도가 자주 이루어집니다.

gateway.userProfile.cacheSleepTime

 

초 단위로 캐시 정리에 대한 절전 시간을 설정합니다.

gateway.userProfile.cacheCleanupTime

 

이 시간이 지나면 프로필 항목을 삭제할 수 있는 최대 시간(초).

gateway.
bindipaddress

 

다중 홈 컴퓨터에서 게이트웨이가 serversocket을 바인딩하는 IP 주소입니다.

gateway.sockretries

3

현재 사용되지 않음.

gateway.enable.accelerator

false

true로 설정된 경우 외부 가속기 지원이 허용됩니다.

gateway.enable.customurl

false

true로 설정된 경우 관리자는 게이트웨이에서 페이지를 다시 쓸 사용자 정의 URL를 지정할 수 있습니다.

gateway.httpurl

 

HTTP reverseproxy URL을 입력하여 게이트웨이에서 페이지를 다시 쓸 사용자 정의 URL을 설정합니다.

gateway.httpsurl

 

HTTPS reverseproxy URL을 입력하여 게이트웨이에서 페이지를 다시 쓸 사용자 정의 URL을 설정합니다.

gateway.favicon

 

게이트웨이에서 favicon.ico 파일에 대한 요청을 리디렉션할 URL을 지정합니다.

이는 Internet Explore 및 Netscape 7.0 이상의 기본 설정이나 즐겨찾기에 있는 "favorite icon"에 사용됩니다.

이 필드가 비어 있으면 게이트웨이는 "404 찾을 수 없습니다"라는 메시지를 브라우저로 반환합니다.

gateway.logging.password

 

이 필드에는 게이트웨이에서 응용프로그램 세션을 만드는 데 사용하는 사용자 "amService-srapGateway"의 LDAP 비밀번호가 들어 있습니다.

암호화되었거나 일반 텍스트일 수 있습니다.

http.proxyHost

 

이 프락시 호스트는 Portal Server에 접촉할 때 사용됩니다.

http.proxyPort

 

이것은 Portal Server에 접촉할 때 사용되는 호스트의 포트입니다.

http.proxySet

 

이 속성은 프락시 호스트가 필요한 경우에 true로 설정됩니다. 이 속성이 false로 설정되면 http.proxyHost 및 http.proxyPort가 무시됩니다.

게이트웨이 시작 및 중지

기본적으로 게이트웨이는 사용자 noaccess로 시작됩니다.

    게이트웨이를 시작하려면
  1. 게이트웨이를 설치하고 필요한 프로필을 만든 후에는 다음 명령을 실행하여 게이트웨이를 시작합니다.

    2. gateway-install-root/SUNWps/bin/gateway -n default start

    default는 설치 중에 만들어지는 기본 게이트웨이 프로필입니다. 나중에 고유한 프로필을 만들고 새 프로필로 게이트웨이를 다시 시작할 수 있습니다. "게이트웨이 프로필 만들기"을 참조하십시오.

    다중 게이트웨이 인스턴스가 있다면 다음을 사용합니다.

    gateway-install-root/SUNWps/bin/gateway start

이 명령은 특정 컴퓨터에 구성된 모든 게이트웨이 인스턴스를 시작합니다.

참고

서버를 다시 시작하면(게이트웨이의 인스턴스를 구성한 서버) 게이트웨이의 구성된 인스턴스가 모두 다시 시작됩니다.

/etc/opt/SUNWps 디렉토리에 기존 프로필이나 백업 프로필이 없어야 합니다.

  1. 다음 명령을 실행하여 지정 포트에서 게이트웨이가 실행되고 있는지 점검합니다.

    2. netstat -a | grep port-number

    기본 게이트웨이 포트는 443입니다.

    게이트웨이를 중지하려면

게이트웨이를 중지하려면 다음 명령을 사용합니다.

gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name stop

다중 게이트웨이 인스턴스가 있으면 다음을 사용합니다.

gateway-install-root/SUNWps/bin/gateway stop

이 명령은 특정 컴퓨터에서 실행되고 있는 모든 게이트웨이 인스턴스를 중지합니다.

게이트웨이 다시 시작

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

    다른 프로필로 게이트웨이를 다시 시작하려면

게이트웨이를 다시 시작합니다.

gateway-install-root/SUNWps/bin/gateway -n new-gateway-profile-name start

    게이트웨이를 다시 시작하려면

단말기 창에서 루트로 연결하고 다음 작업 중 하나를 수행합니다.

    게이트웨이 워치독를 구성하려면

워치독가 게이트웨이의 상태를 모니터링하게 될 시간 간격을 설정할 수 있습니다. 시간 간격은 기본적으로 60초로 설정됩니다. 이 기본 설정을 변경하려면 crontab에서 다음 라인을 편집합니다.

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

crontab 항목을 구성하려면 crontab에 대한 맨 페이지을 참조하십시오.

Identity Server에 접속하도록 프락시 지정

Portal Server에 배포되는 SRA 지원(RemoteConfigServlet)에 접속하기 위해 게이트웨이가 호스트 프락시를 사용하도록 지정할 수 있습니다. 이 프락시는 게이트웨이가 Portal Server와 Identity Server에 접속하기 위해 사용됩니다.

    프락시를 지정하려면
  1. 명령줄에서 다음 파일을 편집합니다.

    2. /etc/opt/bin/platform.conf.gateway-profile-name

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

    3. http.proxyHost=proxy-host

    http.proxyPort=proxy-port

    http.proxySet=true

  3. 서버에 대한 요청에 지정된 프락시를 사용할 수 있도록 게이트웨이를 다시 시작합니다.

    4. gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start

chroot 환경에서 게이트웨이 실행

chroot 환경에서 보안을 높이려면 chroot 디렉토리 컨텐트가 가능한 적어야 합니다. 예를 들어, 사용자가 chroot 디렉토리의 파일을 수정할 수 있는 프로그램이 있으면 chroot는 chroot 트리에서 파일을 수정하는 공격자로부터 서버를 보호하지 않습니다. CGI 프로그램은 bourne shell, c-shell, korn shell 또는 perl과 같은 해석된 언어로 작성되어서는 안되며 해석자가 chroot 디렉토리 트리에 놓지 않아도 되도록 이진수로 컴파일되어야 합니다.

참고

워치독 기능은 chroot 환경에서는 지원되지 않습니다.

    chroot를 설치하려면
  1. 루트로서 단말기 창에서 다음 파일을 네트워크에 있는 컴퓨터나 백업 테이프 또는 플로피 디스크와 같은 외부 소스로 복사합니다.

    2. cp /etc/vfstab external-device

    cp /etc/nsswitch.conf external-device

    cp /etc/hosts external-device

  2. 다음 디렉토리에서 mkchroot 스크립트를 실행합니다.

    3. portal-server-install-root/SUNWps/bin/chroot

    참고

    실행되기 시작하면 mkchroot 스크립트는 Ctrl-C를 눌러 종료할 수 없습니다.

    mkchroot 스크립트를 실행하는 동안 오류가 발생하면 "mkchroot 스크립트의 실행 실패"를 참조하십시오.

다른 루트 디렉토리를 입력하라는 메시지가 나타납니다(new_root_directory). 스크립트에서 새 디렉토리를 만듭니다.

다음 예제에서는 /safedir/chroot가 new_root_directory입니다.

mkchroot version 6.0

 

Enter the full path name of the directory which will be the chrooted tree:/safedir/chroot

Using /safedir/chroot as root.

Checking available disk space...done

/safedir/chroot is on a setuid mounted partition.

Creating filesystem structure...dev etc sbin usr var proc opt bin lib tmp etc/lib usr/platform usr/bin usr/sbin usr/lib usr/openwin/lib var/opt var/tmp dev/fd done

Creating devices...null tcp ticots ticlts ticotsord tty udp zero conslog done

Copying/creating etc files...group passwd shadow hosts resolv.conf netconfig nsswitch.conf

done

Copying binaries...................................done

Copying libraries.....................................done

Copying zoneinfo (about 1 MB)..done

Copying locale info (about 5 MB)..........done

Adding comments to /etc/nsswitch.conf ...done

Creating loopback mount for/safedir/chroot/usr/java1.2...done

Creating loopback mount for/safedir/chroot/proc...done

Creating loopback mount for/safedir/chroot/dev/random...done

Do you need /dev/fd (if you do not know what it means, press return)[n]:

Updating /etc/vfstab...done

Creating a /safedir/chroot/etc/mnttab file, based on these loopback mounts.

Copying SRAP related data ...

Using /safedir/chroot as root.

Creating filesystem structure...........done

mkchroot successfully done.

  1. platform.conf 파일에 언급된 Java 디렉토리를 다음 명령을 사용하여 수동으로 chroot 디렉토리에 마운트합니다.

    2. 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 -

  2. 아래 명령을 입력하여 게이트웨이를 다시 시작합니다.

    3. chroot /safedir/chroot ./gateway-install-root/SUNWps/bin/gateway start

    stopping gateway ... done.

    starting gateway ...

    done.

mkchroot 스크립트의 실행 실패

mkchroot 스크립트를 실행하는 동안 오류가 발생하면 스크립트는 파일을 초기 상태로 복원합니다.

다음 예제에서는 /safedir/chroot가 chroot 디렉토리입니다.

다음 오류 메시지가 발생한 경우,

Not a Clean Exit

  1. 절차 chroot를 설치하려면의 1단계에서 백업 파일을 원래 위치로 복사하고 다음 명령을 실행합니다.

    2. umount /safedir/chroot/usr/java1.2

    umount /safedir/chroot/proc

    umount /safedir/chroot/dev/random

  2. /safedir/chroot 디렉토리를 제거합니다.

chroot 환경에서 게이트웨이 다시 시작

게이트웨이 컴퓨터를 다시 부팅할 때마다 chroot 환경에서 게이트웨이를 시작하려면 다음 단계를 수행합니다.

    chroot 환경에서 게이트웨이를 다시 시작하려면
  1. ’/’ 디렉토리에서 실행 중인 게이트웨이를 중지합니다.

    2. gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name stop

  2. chroot 디렉토리에서 실행할 게이트웨이를 시작합니다.

    3. chroot /safedir/chroot ./portal-server-install-root/SUNWps/bin/gateway -n gateway-profile-name start

    참고

    /safedir/chroot/etc 파일(passwd 및 hosts 등)은 /etc 파일과 같이 관리가 필요하지만 chroot 트리에서 실행되는 프로그램에 필요한 호스트 및 계정 정보만 들어 있습니다.

    예를 들어, 시스템의 identity 공급자 주소를 변경하는 경우에는 파일 /safedir/chroot/etc/hosts도 변경합니다.

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

gwmultiinstance 스크립트를 사용하여 게이트웨이의 새 인스턴스를 만듭니다. 게이트웨이 프로필을 만든 후에 이 스크립트를 실행하는 것이 좋습니다.

  1. 루트로 로그인하여 다음 디렉토리로 찾아 갑니다.

    2. gateway-install-root/SUNWps/bin/

  2. 다중 인스턴스 스크립트를 실행합니다.

    3. ./gwmultiinstance

  3. 다음 설치 옵션 중 하나를 선택합니다.

    4. 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 identity server URI? [/amserver]

    What is the identity server password encryption key?

    Please provide the following information needed for creating a self-signed certificate:

    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

  4. 새 게이트웨이 프로필 이름으로 게이트웨이의 새 인스턴스를 시작합니다.

    5. gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start

    여기서 gateway-profile-name 은 새 게이트웨이 인스턴스입니다.

웹 프락시 사용

타사 웹 프락시를 사용하여 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을 사용해야 함을 나타냅니다.

참고

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

웹 프락시 정보 처리

클라이언트에서 특정 URL에 액세스하려고 할 때 URL의 호스트 이름은 [도메인 및 부속 도메인의 프락시] 목록에 있는 항목과 일치합니다. 요청된 호스트 이름의 가장 긴 접미어에 일치하는 항목이 선택됩니다. 예를 들어, 요청된 호스트 이름이 host1.sesta.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 또는 siroe.com에는 지정된 프락시가 없기 때문에 직접 연결이 시도됩니다.

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 장, "Rewriter"를 참조하십시오.

기본 도메인 및 부속 도메인

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

대상 콘솔의 [기본 도메인 및 부속 도메인] 필드의 항목이 다음과 같다고 가정해 봅시다.

red.sesta.com

참고

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

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

요청된 URL이 host1인 경우, 기본 도메인 및 부속 도메인을 통해 host1.red.sesta.com으로 결정됩니다. 그리고 나서 [도메인 및 부속 도메인의 프락시] 목록에 host1.red.sesta.com이 없는지 검색됩니다.

프락시 자동 구성 사용

[도메인 및 부속 도메인의 프락시] 목록에 있는 정보를 무시하려면 프락시 자동 구성(PAC) 기능을 사용 설정합니다. PAC를 구성하려면 "프락시 자동 구성(PAC) 지원 사용"을 참조하십시오.

PAC 파일을 사용할 때는 다음을 주의합니다.

예제 PAC 파일 사용

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

DIRECT 또는 NULL이 반환되는 예제

도메인 및 부속 도메인에 이 프락시 사용:

intranet1.com

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 domain에 있는 호스트에 대한 것이면 게이트웨이는 proxy.intranet1.com:8080에 연결합니다. 프락시 intranet1.com:8080이 다운되면 요청이 실패합니다. 그래도 게이트웨이에서는 장애 조치를 수행하고 proxy1.intranet1.com:8080에 연결하지 않습니다.

Netlet 프락시 사용

Netlet 패킷은 게이트웨이에서 암호가 해독되어 대상 서버로 보내집니다. 그러나 게이트웨이는 비무장 지대(DMZ)와 인트라넷 사이의 방화벽을 통해 모든 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 프락시와 관련하여 가능한 구성을 보여주고 Netlet 프락시를 설치하는 경우에 누릴 수 있는 이점을 설명합니다. 그림 앞부분의 자세한 설명을 참고하십시오.

Netlet 프락시의 인스턴스 만들기

Portal Server 노드나 별도 노드에 Netlet 프락시의 새 인스턴스를 만들려면 nlpmultiinstance 스크립트를 사용합니다. 게이트웨이 프로필을 만든 후에 이 스크립트를 실행하는 것이 좋습니다.

  1. 루트로 로그인하여 다음 디렉토리로 찾아 갑니다.

    2. netlet-install-dir/SUNWps/bin

  2. 다중 인스턴스 스크립트를 실행합니다.

    3. ./nlpmultiinstance

  3. nlpmultiinstance 스크립트에서 나타나는 다음 질문에 답합니다.
    • 새 netlet 프락시 인스턴스의 이름은 무엇입니까?
    • 이 노드에 같은 이름으로 구성된 rewriter 프락시 인스턴스가 있으면 이 netlet 프락시 인스턴스에도 같은 구성을 사용할 것인지 묻는 메시지가 나타납니다.
    • 예라고 답한 경우, 다음 두 질문에 답하십시오.
      • 새 netlet 프락시 인스턴스에서는 어떤 포트를 수신합니까?
      • 설치 후 netlet 프락시를 시작하시겠습니까?
    • 아니오라고 답한 경우, 다음 질문에 답하십시오.
      • 새 netlet 프락시 인스턴스에서는 어떤 프로토콜을 사용합니까?
      • 새 netlet 프락시 인스턴스에서는 어떤 포트를 수신합니까?
      • 조직의 이름은 무엇입니까?
      • 부서 이름은 무엇입니까?
      • 구/군/시의 이름은 무엇입니까?
      • 시/도의 이름은 무엇입니까?
      • 2자로 된 국가 번호는 무엇입니까?
      • 인증서 데이터베이스 비밀번호는 무엇입니까?
      • 사용자 로그인 비밀번호는 무엇입니까?
      • 관리 콘솔에 새 netlet 프락시 프로필을 만들었습니까?
      • 예라고 답한 경우, 설치 후 netlet 프락시를 시작하시겠습니까?
  4. 새 게이트웨이 프로필 이름으로 netlet 프락시의 새 인스턴스를 시작합니다.

    5. netlet-proxy-install-root/SUNWps/bin/netletd -n gateway-profile-name start

    여기서 gateway-profile-name은 필요한 게이트웨이 인스턴스에 해당하는 프로필 이름입니다.

Netlet 프락시 사용 설정

Identity Server 관리 콘솔의 SRA 구성에서 게이트웨이 서비스를 통해 Netlet 프락시를 사용하도록 설정합니다. "Netlet 프락시 목록 사용과 만들기"을 참조하십시오.

Netlet 프락시 다시 시작

프락시가 예기치 않게 중단될 때마다 다시 시작하도록 Netlet 프락시를 구성할 수 있습니다. 워치독 프로세스 일정을 계획하여 Netlet 프락시를 모니터링하고, 프락시가 다운된 경우 다시 시작합니다.

Netlet 프락시를 수동으로 다시 시작할 수도 있습니다.

    Netlet 프락시를 다시 시작하려면

단말기 창에서 루트로 연결하고 다음 작업 중 하나를 수행합니다.

    Netlet 프락시 워치독를 구성하려면

워치독가 Netlet 프락시의 상태를 모니터링하게 될 시간 간격을 설정할 수 있습니다. 시간 간격은 기본적으로 60초로 설정됩니다. 이 설정을 변경하려면 crontab에서 다음 라인을 편집합니다.

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

Rewriter 프락시 사용

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

Rewriter 프락시를 사용을 통해 얻을 수 있는 이점은 2가지입니다.

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

Rewriter 프락시를 사용 설정하려면 "Rewriter 프락시 목록 사용과 만들기"를 참조하십시오.

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

Portal Server 노드에 Rewriter 프락시의 새 인스턴스를 만들려면 rwpmultiinstance 스크립트를 사용합니다. 게이트웨이 프로필을 만든 후에 이 스크립트를 실행하는 것이 좋습니다.

  1. 루트로 로그인하여 다음 디렉토리로 찾아 갑니다.

    2. rewriter-proxy-install-root/SUNWps/bin

  2. 다중 인스턴스 스크립트를 실행합니다.

    3. ./rwpmultiinstance

  3. 스크립트에 나타나는 질문에 답합니다.
    • 새 rewriter 프락시 인스턴스의 이름은 무엇입니까?
    • 이 노드에 같은 이름으로 구성된 rewriter 프락시 인스턴스가 있으면 이 rewriter 프락시 인스턴스에도 같은 구성을 사용할 것인지 묻는 메시지가 나타납니다.
    • 예라고 답한 경우, 다음 두 질문에 답하십시오.
      • 새 rewriter 프락시 인스턴스에서는 어떤 포트를 수신합니까?
      • 설치 후 rewriter 프락시를 시작하시겠습니까?
    • 아니오라고 답한 경우, 다음 질문에 답하십시오.
      • 새 rewriter 프락시 인스턴스에서는 어떤 프로토콜을 사용합니까?
      • 새 rewriter 프락시 인스턴스에서는 어떤 포트를 수신합니까?
      • 조직의 이름은 무엇입니까?
      • 부서 이름은 무엇입니까?
      • 구/군/시의 이름은 무엇입니까?
      • 시/도의 이름은 무엇입니까?
      • 2자로 된 국가 번호는 무엇입니까?
      • 인증서 데이터베이스 비밀번호는 무엇입니까?
      • 사용자 로그인 비밀번호는 무엇입니까?
      • 관리 콘솔에 새 rewriter 프락시 프로필을 만들었습니까?
      • 예라고 답한 경우, 설치 후 rewriter 프락시를 시작하시겠습니까?
  4. 새 게이트웨이 프로필 이름으로 rewriter 프락시의 새 인스턴스를 시작합니다.

    5. rewriter-proxy-install-root/SUNWps/bin/rwproxyd -n gateway-profile-name start

    여기서 gateway-profile-name은 필요한 게이트웨이 인스턴스에 해당하는 프로필 이름입니다.

Rewriter 프락시 사용 설정

Identity Server 관리 콘솔의 SRA 구성에서 게이트웨이 서비스를 통해 Rewriter 프락시를 사용 설정합니다. "Rewriter 프락시 목록 사용과 만들기"을 참조하십시오.

Rewriter 프락시 다시 시작

프락시가 예기치 않게 중단될 때마다 다시 시작하도록 Rewriter 프락시를 구성할 수 있습니다. 워치독 프로세스 일정을 계획하여 Rewriter 프락시를 모니터링하고, 프락시가 다운된 경우 다시 시작합니다.

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

    Rewriter 프락시를 다시 시작하려면

터미널 창에서 루트로 연결하고 다음 작업 중 하나를 수행합니다.

    Rewriter 프락시 워치독를 구성하려면

워치독가 Rewriter 프락시 상태를 모니터링하게 될 시간 간격을 설정할 수 있습니다. 시간 간격은 기본적으로 60초로 설정됩니다. 이 설정을 변경하려면 crontab에서 다음 라인을 편집합니다.

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

게이트웨이에서 역 프락시 사용

프락시 서버는 인트라넷에 인터넷 컨텐트를 서비스하고 역 프락시는 인터넷에 인트라넷 컨텐트를 서비스합니다. 특정 역 프락시 배포는 인터넷 컨텐트를 서비스하고 로드 균형 조정과 캐싱을 수행하도록 구성됩니다.

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

    역 프락시를 사용 설정하려면
  1. 루트로 로그인하여 필요한 게이트웨이 인스턴스의 platform.conf 파일을 편집합니다.

    2. /etc/opt/SUNWps/platform.conf.gateway-profile-name

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

    3. 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 포트로 나열된 포트에서 수신된 요청에 대한 응답을 다시 쓰는데 사용됩니다.

  3. 게이트웨이를 다시 시작합니다.

    4. gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start

값이 지정되어 있지 않으면 게이트웨이에서는 일반 작동으로 기본값을 설정합니다.

클라이언트 정보 가져오기

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

HTTP 요청 헤더를 보려면 platform.conf 파일의 항목을 gateway.error=message로 설정한 다음 servlet API에서 request.getHeader()를 사용합니다.

첫 번째 열에는 헤더 레이블이 나열되고, 두 번째 열은 각 헤더에 대한 구문을 지정하며 세 번째 열은 헤더 레이블을 설명합니다.

표 2-3  HTTP 헤더의 정보

헤더

구문

설명

PS-GW-PDC

PS-GW-PDC: true/false

게이트웨이에서 PDC의 사용 설정 여부를 나타냅니다.

PS-Netlet

PS-Netlet:enabled=true/false

게이트웨이에서 Netlet의 사용 설정 여부를 나타냅니다.

사용 설정된 경우 암호화 옵션이 채워져서 게이트웨이가 HTTPS(encryption=ssl) 또는 HTTP 모드(encryption=plain) 중 어느 쪽에서 실행 중인지 보여줍니다.

예:

PS-Netlet: enabled=false

Netlet이 사용 해제되었습니다.

PS-Netlet: enabled=true; encryption=ssl

게이트웨이가 SSL 모드에서 실행되며 Netlet이 사용 설정되었습니다.

encryption=ssl/plain은 Netlet이 사용 설정되지 않은 경우에는 채워지지 않습니다.

PS-GW-URL

PS-GW-URL: http(s)://gatewayURL(:port)

클라이언트가 연결된 URL을 나타냅니다.

비표준 포트인 경우(즉, 포트 80/443이 아닌 상태로 게이트웨이가 HTTP/HTTPS 모드에 잇는 경우) ":port"도 채워집니다.

PS-GW-Rewriting-URL

PS-GW-URL: http(s)://gatewayURL(:port)/[SessionInfo]

 

게이트웨이가 모든 페이지를 다시 쓰는 URL을 나타냅니다.

1.  브라우저에서 쿠키를 지원하는 경우 이 헤더 값은 PS-GW-URL 헤더와 같습니다.

2.  브라우저가 쿠키를 지원하지 않고

  • 대상 호스트가 "쿠키 URL 전달" 목록에 있으면 이 값은 게이트웨이가 페이지를 다시 쓰게 되는 실제 URL을 나타냅니다(인코딩된 SessionID info 포함).
  • 또는 대상 호스트가 쿠키 URL 전달 목록에 있지 않으면 SessionInfo 문자열은 "$SessionID"가 됩니다.

참고: 응답의 일부로 사용자의 Identity Server sessionId가 변경되면(인증 페이지에서 오는 응답과 같이) 페이지는 이전에 헤더에 표시된 값이 아닌 그 값으로 다시 쓰여집니다.

예:

  • 브라우저에서 쿠키를 지원하는 경우

PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/

  • 브라우저가 쿠키는 지원하지 않지만 endserver가 "쿠키 URL 전달" 목록에 있는 경우

PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/SessIDValCustomEncodedValue/

  • 브라우저가 쿠키는 지원하지 않고 endserver가 "쿠키 URL 전달" 목록에 없는 경우

PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/$SessionID

PS-GW-CLientIP

 

PS-GW-CLientIP: IP

게이트웨이가 recievedSocket.getInetAddress().getHostAddress()로부터 가져온 IP입니다.

이 IP는 게이트웨이에 직접 연결되면 클라이언트의 IP가 됩니다.

참고: JSS/NSS 버그로 인해 현재 존재하지는 않습니다.

인증 체이닝 사용

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

여기에 설명된 절차는 게이트웨이에서 PDC 인증과 함께 인증 체이닝을 사용하는 경우에만 적용됩니다. 게이트웨이에서 PDC 인증을 사용하지 않는 인증 체이닝에 대해서는 Sun ONE Identity Server Administration Guide를 참조하십시오.

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

참고

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

    기존 PDC 인스턴스에 인증 모듈을 추가하려면
  1. Identity Server 관리 콘솔에 관리자로 로그인합니다.
  2. 필요한 조직을 선택합니다.
  3. [보기] 드롭다운 메뉴에서 [서비스]를 선택합니다.

    4. 왼쪽 창에 서비스가 표시됩니다.

  4. [인증 구성] 옆의 화살표를 클릭합니다.

    5. 서비스 인스턴스 목록이 표시됩니다.

  5. gatewaypdc를 클릭합니다.

    6. Gatewaypdc 속성 페이지가 표시됩니다.

  6. [인증 구성] 앞의 [편집]을 클릭합니다.

    7. [모듈 추가]가 나타납니다.

  7. [모듈 이름]을 선택하고 [플래그]를 [필요]로 설정합니다. 빈 칸으로 남겨둬도 됩니다.
  8. [확인]을 클릭합니다.
  9. 모듈을 하나 이상 추가한 다음 [저장]을 클릭합니다.
  10. gatewaypdc 속성 페이지에서 [저장]을 클릭합니다.
  11. 변경 내용을 적용하려면 게이트웨이를 다시 시작합니다.

    12. gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start

와일드카드 인증 사용

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

그러면 같은 도메인에서 여러 호스트에게 인증을 허용할 수 있습니다. 예를 들어, *.domain.com에 대한 인증을 abc.domain.com 및 abc1.domain.com에 사용할 수 있습니다. 사실 이 인증은 domain.com 도메인에 있는 모든 호스트에 유효합니다.

완전한 정규 호스트 이름에 *를 지정해야 합니다. 예를 들어, 완전한 정규 호스트 이름이 abc.florizon.com인 경우 이 이름을 *.florizon.com으로 지정하십시오. 이제 생성된 인증서가 florizon.com 도메인에 있는 모든 호스트 이름에 유효합니다.

브라우저 캐싱 사용 해제

게이트웨이 구성 요소는 웹 브라우저를 사용하여 어느 위치에서든 백엔드 기업 데이터에 안전하게 액세스하므로 클라이언트에 의해 정보가 로컬로 캐싱되지 않아야 합니다.

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

이 옵션을 사용 해제하면 게이트웨이 성능에 영향이 있을 수 있습니다. 포털 데스크탑을 새로 고칠 때마다 게이트웨이는 브라우저에서 이전에 캐싱한 이미지와 같이 페이지에서 참조되는 모든 항목을 검색해야 합니다. 그러나 이 기능을 사용 설정하면 원격 액세스 보안 컨텐트가 클라이언트 사이트에 캐싱된 풋프린트를 남기지 않습니다. 기업 네트워크가 인터넷 카페에서 또는 기업 IT 제어를 받지 않는 유사한 원격 위치에서 액세스되는 경우 이 이점은 성능상의 불이익 보다 훨씬 큽니다.

    브라우저 캐싱을 사용 해제하려면
  1. 루트로 로그인하여 필요한 게이트웨이 인스턴스의 platform.conf 파일을 편집합니다.

    2. /etc/opt/SUNWps/platform.conf.gateway-profile-name

  2. 다음 라인을 편집합니다.

    3. gateway.allow.client.caching=true

    이 값은 기본적으로 true로 설정되어 있습니다. 값을 false로 변경하여 클라이언트 쪽에서 브라우저 캐싱을 사용 해제합니다.

  3. 게이트웨이를 다시 시작합니다.

    4. gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start

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

이 부분에서는 편집할 수 있는 여러 속성 파일에 대해 설명합니다. 관리 콘솔의 게이트웨이 서비스에 대한 레이블, 오류 메시지 또는 로그 정보 순서를 편집할 수 있습니다. 여러 로켈에서 제품을 사용자 정의하고자 할 때 유용합니다.

다음 파일을 사용자 정의할 수 있습니다.

portal-server-install-root/SUNWam/locale/srapGatewayAdminConsole.properties

portal-server-installl-dir/SUNWps/locale/srapGateway.properties

portal-server-install-root/SUNWps/web-src/WEB-INF/classes/srapgwadminmsg.properties

참고

여러 로켈 설정이 있는 경우 이 파일의 각 복사본을 각각 locale 디렉토리에 저장해야 합니다.

srapGatewayAdminConsole.properties 파일

관리 콘솔의 게이트웨이 서비스에 나타나는 필드 이름을 변경하려면 이 필드를 편집합니다.

srapGateway.properties File

이 파일은 다음과 같은 경우 편집합니다.

srapgwadminmsg.properties 파일

이 파일은 다음과 같은 경우 편집합니다.

연합 관리 사용

연합 관리를 사용하면 사용자가 하나의 네트워크 아이디를 가질 수 있도록 로컬 아이디를 집계할 수 있습니다. 연합 관리에서는 네트워크 아이디를 사용하여 사용자가 한 서비스 공급자의 사이트에 로그인할 경우 아이디를 재인증 받지 않고도 다른 서비스 공급자의 사이트에 액세스할 수 있도록 해줍니다. 이를 단일 사인온이라 합니다.

연합 관리는 Portal Server에서 개방 모드 및 보안 모드로 구성할 수 있습니다. Sun ONE Portal Server Administrator’s Guide에서는 개방 모드로 연합 관리를 구성하는 방법에 대해 설명합니다. 연합 관리를 보안 원격 액세스를 사용하여 보안 모드에서 구성하려면 개방 모드에서 올바로 작동하는지 확인해야 합니다. 사용자가 같은 브라우저에서 개방 모드와 보안 모드 모두에서 연합 관리를 사용할 수 있도록 하려면 쿠키를 지우고 브라우저로부터 캐싱해야 합니다.

연합 관리에 대한 자세한 내용은 Sun ONE Identity Server Customization and API Guide를 참조하십시오.

연합 관리 시나리오

사용자가 최초 서비스 공급자에게 인증을 받습니다. 서비스 공급자는 웹 기반 서비스를 제공하는 상업적 조직이거나 비영리 조직을 말합니다. 이렇게 넓은 범주에는 인터넷 포털, 대리점, 운송 공급자, 금융 기관, 엔터테인먼트 회사, 도서관, 대학 및 정부 기관이 모두 포함될 수 있습니다.

서비스 공급자는 쿠키를 사용하여 클라이언트 브라우저에 사용자의 세션 정보를 저장합니다. 쿠키에도 사용자의 Identity 공급자가 포함될 수 있습니다.

Identity 공급자는 인증 서비스를 전문적으로 제공하는 서비스 공급자를 말합니다. 인증을 위한 관리 서비스로 Identity 공급자는 아이디 정보를 유지 관리하기도 합니다. Identity 공급자에 의해 허가된 인증은 제휴 관계에 있는 모든 서비스 공급자에게 유효합니다.

사용자가 Identity 공급자와 제휴되지 않은 서비스에 액세스하려고 하면 Identity 공급자는 쿠키를 비제휴 서비스 공급자에게 전달합니다. 그리고 나면 이 서비스 공급자가 쿠키에 명명된 Identity 공급자에게 액세스할 수 있습니다.

그러나 쿠키는 여러 DAN 도메인에서 읽을 수 없기 때문에 서비스 공급자를 올바른 Identity 공급자에게 리디렉션하여 사용자에게 단일 사인온이 가능하도록 공용 도메인 쿠키 서비스를 사용합니다.

연합 관리 리소스 구성

연합 리소스, 서비스 공급자, Identity 공급자, Identity 공급자 및 공용 도메인 쿠키 서비스(CDCS)는 상주해 있는 위치를 기준으로 게이트웨이 프로필에 구성합니다. 이 부분에서는 3가지 시나리오를 구성하는 방법에 대해 설명합니다.

  1. 모든 리소스가 기업 인트라넷 안에 있는 경우.
  2. 모든 리소스가 기업 인트라넷에 있지 않거나 Identity 공급자가 인터넷에 상주하는 경우.
  3. 모든 리소스가 기업 인트라넷에 있지 않거나 서비스 공급자는 인터넷에 상주하는 타사이고 Identity 공급자는 게이트웨이에서 보호되는 경우.

구성 1

이 구성에서는 서비스 공급자, Identity 공급자 및 공용 도메인 쿠키 서비스가 같은 기업 인트라넷에 배치되고 Identity 공급자는 인터넷 DNS(Domain Name Server)에 게시되지 않습니다. CDCS는 선택 사항입니다.

이 구성에서는 게이트웨이가 Portal Server가 되는 서비스 공급자를 지정합니다. 이 구성은 Portal Server의 다중 인스턴스에 유효합니다.

  1. Identity Server 관리 콘솔에 관리자로 로그인합니다.
  2. 관리 콘솔에서 [서비스 구성] 탭을 선택합니다.
  3. SRA 구성 아래에서 게이트웨이 옆에 있는 화살표를 클릭합니다.

    4. 게이트웨이 페이지가 표시됩니다.

  4. 속성을 설정할 게이트웨이 프로필 옆의 [편집...]을 클릭합니다.

    5. 게이트웨이 프로필 편집 페이지가 표시됩니다.

  5. [코어] 탭을 클릭합니다.
  6. [쿠키 관리 사용] 확인란을 선택하고 쿠키 관리의 사용을 설정합니다.
  7. [Portal Server 목록] 필드로 스크롤하고 Portal Server 이름을 입력하여 인증되지 않은 URL 목록에 나열된 /amserver or /portal/dt와 같은 관련 URL을 사용할 수 있도록 합니다. 예:

    8. 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

  8. [Portal Server 목록] 필드로 스크롤하여 Portal Server 이름을 입력합니다. 예를 들어 /amserver를 입력합니다.
  9. [저장]을 클릭합니다.
  10. [보안] 탭을 클릭합니다.
  11. 인증되지 않은 URL 목록으로 스크롤하여 연합 리소스를 추가합니다. 예:

    12. /amserver/config/federation

    /amserver/IntersiteTransferService

    /amserver/AssertionConsumerservice

    /amserver/fed_images

    /amserver/preLogin

    /portal/dt

  12. [추가]를 클릭합니다.
  13. [저장]을 클릭합니다.
  14. 웹 프락시에서 인증되지 않은 URL 목록에 나열된 URL에 접속이 필요하면 [프락시] 탭을 클릭합니다.
  15. [도메인 및 부속 도메인의 프락시] 필드로 스크롤하여 필요한 웹 프락시를 입력합니다.
  16. [추가]를 클릭합니다.
  17. [저장]을 클릭합니다.
  18. 단말기 창에서 게이트웨이를 다시 시작합니다.

    19. gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start

구성 2

이 구성에서는 Identity 공급자, Identity 공급자 및 공용 도메인 쿠키 공급자(CDCP)가 같은 기업 인트라넷에 배치되지 않았거나 Identity 공급자가 인터넷에 상주하는 타사 공급자입니다.

이 구성에서는 게이트웨이가 Portal Server가 되는 서비스 공급자를 지정합니다. 이 구성은 Portal Server의 다중 인스턴스에 유효합니다.

  1. Identity Server 관리 콘솔에 관리자로 로그인합니다.
  2. 관리 콘솔에서 [서비스 구성] 탭을 선택합니다.
  3. SRA 구성 아래에서 게이트웨이 옆에 있는 화살표를 클릭합니다.

    4. 게이트웨이 페이지가 표시됩니다.

  4. 속성을 설정할 게이트웨이 프로필 옆의 [편집...]을 클릭합니다.

    5. 게이트웨이 프로필 편집 페이지가 표시됩니다.

  5. [코어] 탭을 클릭합니다.
  6. [쿠키 관리 사용] 확인란을 선택하고 쿠키 관리의 사용을 설정합니다.
  7. [Portal Server 목록] 필드로 스크롤하고 서비스 공급자 Portal Server 이름을 입력하여 비인증 URL 목록에 나열된 /amserver or /portal/dt와 같은 관련 URL을 사용할 수 있도록 합니다.

    8. 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

  8. [저장]을 클릭합니다.
  9. [보안] 탭을 클릭합니다.
  10. 인증되지 않은 URL 목록으로 스크롤하여 연합 리소스를 추가합니다. 예:

    11. /amserver/config/federation

    /amserver/IntersiteTransferService

    /amserver/AssertionConsumerservice

    /amserver/fed_images

    /amserver/preLogin

    /portal/dt

  11. [추가]를 클릭합니다.
  12. [저장]을 클릭합니다.
  13. 웹 프락시에서 인증되지 않은 URL 목록에 나열된 URL에 접속이 필요하면 [프락시] 탭을 클릭합니다.
  14. [도메인 및 부속 도메인의 프락시] 필드로 스크롤하여 필요한 웹 프락시를 입력합니다.
  15. [추가]를 클릭합니다.
  16. [저장]을 클릭합니다.
  17. 단말기 창에서 게이트웨이를 다시 시작합니다.

    18. gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start

구성 3

이 구성에서는 Identity 공급자, Identity 공급자 및 공용 도메인 쿠키 공급자(CDCP)가 같은 기업 인트라넷에 배치되지 않았거나 서비스 공급자가 인터넷에 상주하는 타사이고 Identity 공급자는 게이트웨이에 의해 보호됩니다.

이 구성에서는 게이트웨이가 Portal Server가 되는 Identity 공급자를 지정합니다.

이 구성은 Portal Server의 다중 인스턴스에 유효합니다. 이 구성은 인터넷에서는 구현되는 경우가 거의 없지만 어떤 기업 네트워크에는 인트라넷에 이러한 구성이 있을 수 있습니다. 즉, Identity 공급자는 방화벽으로 보호되는 서브 네트에 있고 서비스 공급자는 기업 네트워크 내에서 직접 액세스 가능한 경우를 말합니다.

  1. Identity Server 관리 콘솔에 관리자로 로그인합니다.
  2. 관리 콘솔에서 [서비스 구성] 탭을 선택합니다.
  3. SRA 구성 아래에서 게이트웨이 옆에 있는 화살표를 클릭합니다.

    4. 게이트웨이 페이지가 표시됩니다.

  4. 속성을 설정할 게이트웨이 프로필 옆의 [편집...]을 클릭합니다.

    5. 게이트웨이 프로필 편집 페이지가 표시됩니다.

  5. [코어] 탭을 클릭합니다.
  6. [쿠키 관리 사용] 확인란을 선택하고 쿠키 관리의 사용을 설정합니다.
  7. [Portal Server 목록] 필드로 스크롤하고 Identity 공급자 Portal Server 이름을 입력하여 비인증 URL 목록에 나열된 /amserver or /portal/dt와 같은 관련 URL을 사용할 수 있도록 합니다.

    8. 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

  8. [저장]을 클릭합니다.
  9. [보안] 탭을 클릭합니다.
  10. 인증되지 않은 URL 목록으로 스크롤하여 연합 리소스를 추가합니다. 예:

    11. /amserver/config/federation

    /amserver/IntersiteTransferService

    /amserver/AssertionConsumerservice

    /amserver/fed_images

    /amserver/preLogin

    /portal/dt

  11. [추가]를 클릭합니다.
  12. [저장]을 클릭합니다.
  13. 웹 프락시에서 인증되지 않은 URL 목록에 나열된 URL에 접속이 필요하면 [프락시] 탭을 클릭합니다.
  14. [도메인 및 부속 도메인의 프락시] 필드로 스크롤하여 필요한 웹 프락시를 입력합니다.
  15. [추가]를 클릭합니다.
  16. [저장]을 클릭합니다.
  17. 단말기 창에서 게이트웨이를 다시 시작합니다.

    18. gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start



이전      목차      색인      다음     

Copyright 2003 Sun Microsystems, Inc. 모든 권리는 저작권자의 소유입니다.