connection URL 의 사용.
아래는 JEUS 의 datasource 설정부분이다.

<database>
                <vendor>oracle</vendor>
                <export-name>oracleXADatasource1</export-name>
                <data-source-class-name>oracle.jdbc.xa.client.OracleXADataSource</data-source-class-name>
                <database-name>EGORA</database-name>
                <data-source-name>oracle.jdbc.xa.client.OracleXADataSource</data-source-name>
                <user>scott</user>
                <password>tiger</password>
                <data-source-type>XADataSource</data-source-type>

                <property>
                    <name>URL</name>
                    <type>java.lang.String</type>
                  <value>jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS = (PROTOCOL = TCP)(HOST = 160.100.1.35)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 160.100.1.36)(PORT = 1521))(LOAD_BALANCE =on)(FAILOVER = on)(CONEC_DATA=(SERVER = DEDICATED)(SERVICE_NAME = SPDM)   (FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETRIES=180)(DELAY=5))))</value>
                </property>
                <connection-pool>
                    <pooling>
                        <min>2</min>
                        <max>10</max>
                        <step>2</step>
                        <period>1800000</period>
                    </pooling>
                    <wait-free-connection>
                        <enable-wait>false</enable-wait>
                        <wait-time>100000</wait-time>
                    </wait-free-connection>
                    <delegation-datasource>datasource1</delegation-datasource>
                </connection-pool>
            </database>

빨간색의 밎줄부분이 보이는가?
Fail-over 와 Load balance 에 대한 옵션이다.
풀을 생성할때의 옵션인데 failover 의 경우는 죽었을때의 생성관련한 옵션인것 같은데.
LOAD_BALANCE 옵션은 무엇일까?

대략 확인해보니, 위의 옵션들은 pool 을 생성하는 시점에 대한 정의 입니다.
그러니 멀티풀의 개면으로만 존재를 하게되죠. 물론 failover는 connection 이 유효하지 않게되면 인지된 다음 요청부터 failover connection pool 로 생성을 시키게 되는거죠.

아무튼 위 설정은 pool 의 생성시점시의 처리방안 밖에는 안되네요.

다만. 실제로 멀티풀의 개념이 존재할 수 있는지가 궁금하게되겠네요.

만일 2개의 풀이 존재하게 된다면 풀은 가져가는 놈이 여하튼 모든 풀을 대상으로 사용을 하게 되므로 전체적으로
봐서는 2곳의 DB 에 접속을 한다고 봐야하겠습니다.

그러나 정말 원하는 load balance 는 아니군요.

하지만 위의 방법도 괜찮은 방법이군요. Application 에서 쓸대없이 처리하는 것보다는 괜찮군요.

좀더 좋은 안을 찾을때까지 한번 테스트를 해봐야겠습니다.


참조URL : http://www.oracle.com/technology/products/ifs/sample_code/cmsdkandrac/oraclecmsdkandrac.html

 
Listener LoadBalance 방식



Client LoadBalance 방식 

들이 있군요!! 그림을 보니 더 눈에 들어옵니다.

SSO의 종류

요약 :

SSO 에이전트가 대행해주는 Delegation(인증 대행) 방식과

SSO 시스템과 신뢰관계를 토대로 사용자를 인증한 사실을 전달받아 SSO를 구현하는 Propagation(인증정보 전달) 방식으로 구분된다.

 propagation 방식중 같은 도메인내에 있다면 one cookie domain sso를 이용하면 손쉽게 sso를 구현할수 있고 이때는 보안을 위해 128bit암호화 알고리즘이나 유효시간 제한등의 방법을 사용한다.

내용 :

일반적으로 사용되는 SSO 시스템은 두 가지 모델로 구분된다. SSO 대상 애플리케이션에서 사용되는 사용자 인증 방법을 별도의 SSO 에이전트가 대행해주는 Delegation(인증 대행) 방식과 SSO 시스템과 신뢰관계를 토대로 사용자를 인증한 사실을 전달받아 SSO를 구현하는 Propagation(인증정보 전달) 방식으로 구분된다.

<그림 1> SSO Delegation Model

△Delegation 방식: 대상 애플리케이션의 인증 방식을 변경하기 어려울 때 많이 사용된다. 대상 애플리케이션의 인증 방식을 전혀 변경하지 않고, 사용자의 대상 애플리케이션 인증 정보를 에이전트가 관리해 사용자 대신 로그온 해주는 방식이다. 즉 Target Server 1을 로그온 할 때 User1이 alice/alice라는 ID/ PWD가 필요하다면, 에이전트가 이 정보를 가지고 있고, User1이 Target Service 1에 접근할 때 에이전트가 대신 alice/alice ID/PWD 정보를 전달해서 로그온 시켜준다. △Propagation 방식: 통합 인증을 수행하는 곳에서 인증을 받아 대상 애플리케이션으로 전달할 토큰(Token)을 발급 받는다. 대상 애플리케이션에 사용자가 접근할 때 토큰을 자동으로 전달해 대상 애플리케이션이 사용자를 확인할 수 있도록 하는 방식이다. 웹 환경에서는 쿠키(Cookie)라는 기술을 이용해 토큰을 자동으로 대상 애플리케이션에 전달할 수 있다. 이러한 웹 환경의 이점으로 웹 환경에서의 SSO는 대부분 이 모델을 채택하고 있다.

<그림 2> SSO Propagation Model

△Delegation & Propagation 방식: 웹 환경이라고 하더라도 Propagation 방식이 모두 적용될 수는 없다. 특히 웹 애플리케이션의 변경이 전혀 불가능하고 사용자 통합이 어려운 경우 Delegation 방식을 사용하게 된다. 또한 대상 애플리케이션들이 많이 있고 애플리케이션의 특성들이 다양한 경우 각 애플리케이션에 Delegation 방식과 Propagation 방식을 혼용해서 전체 시스템의 SSO을 구성한다.

△Web 기반 One Cookie Domain SSO: SSO 대상 서비스와 응용 애플리케이션들이 하나의 Cookie Domain안에 존재할 때 사용된다. 일반적인 기업 내부의 컴퓨팅 환경이다. 통합인증을 받은 사용자는 토큰을 발급받게 되고, 이 토큰은 Cookie Domain에 Cookie로 설정되어 Cookie Domain 내의 다른 서비스로 접근할 때 자동으로 토큰을 서비스에 제공하게 된다. 서비스에서 동작되는 SSO 에이전트는 토큰으로부터 사용자 신원을 확인하고 요청된 자원에 대한 접근을 허가 해준다.

Cookie를 통한 SSO구현시 Cookie 보안 방법

토큰은 쿠키를 통해 전달되므로 외부에 노출되는 정보이다. 완벽한 보안을 위해서는 토큰이 네트워크에서 노출되어서는 안되지만, 비용 및 관리상의 이유로 허용되고 있다. 하지만 토큰을 통해 토큰이 포함하고 있는 정보까지 외부에 노출하는 것은 심각한 결함을 제공한다. 토큰의 네트워크 구간에서의 정보 노출 및 위·변조를 방지하기 위해 다음과 같은 보안기술이 사용된다.

△Data Confidentiality: 토큰은 주요 암호 알고리즘(AES, SEED)과 128bit 이상의 키로 암호화돼 보호되어야 한다. △Data Integrity: 토큰은 MAC

(Message Authentication Code) 등을 포함해 데이터의 무결성을 보장해야 한다. △Replay Attack Protection: 토큰은 사용자와 대상 애플리케이션 사이에 전달되는 인증 정보이다. 일반적으로 토큰은 네트워크에 노출되며, 노출된 토큰을 사용해 다른 사용자가 인증을 받고 들어올 수 있다(Replay Attack). 특히 웹 환경에서 이러한 문제점이 중요한 이슈로 등장하고 있다. 이러한 문제점을 근본적으로 해결하기 위해서는 토큰을 네트워크에 노출시키지 않아야 한다.
토큰을 네트워크에 노출시키지 않기 위해서는 항상 사용자와 대상 애플리케이션 사이에 암호 채널을 형성해야 하며, 이 채널을 통해 토큰을 전달해야 한다. 그러나 SSL과 같은 채널 암호를 사용하는 데에는 매우 많은 비용이 요구되어 실제로 많이 사용되고 있지는 않다.
SSL과 같은 암호채널을 사용하지 않으면서 Replay Attack이 발생할 수 있는 상황을 줄일 수 있도록 다음과 같은 보안 기술들이 사용된다.

△사용자 주소 제한: 토큰이 발행될 때 접속한 사용자 주소 정보를 토큰 내부나 토큰을 발행한 서버에서 기억함으르써 Token이 제출된 사용자 주소와 최초 발행시 기억된 주소를 비교하여 접속한 곳 이외에서의 접속을 제한할 수 있다. 사용자 주소가 업무진행 중에 자주 변경되지 않는 시스템일 경우 유효하다. 예를 들어 회사내의 인터넷 환경일 경우 사용될 수 있다. 인터넷 환경의 경우에는 사용자 주소가 특정 범위에서 자주 바뀔 수 있는 환경도 있기 때문에 불특정 다수를 위한 일반적인 인터넷 서비스에 사용하기에는 부적합하다.

△유효시간 제한: 토큰의 유효시간을 매우 짧게 줌으로써 Replay Attack에 사용될 수 있는 시간을 제한한다. 유효시간내에 임계시간(예: 유효시간의 1/2)을 넘으면 자동으로 토큰을 재 발행하여 사용자는 의식하지 못하고 서비스를 계속 사용하게 한다. 지금까지 사용자가 각 애플리케이션별로 별도의 인증을 받지 않고, 한번의 통합 인증만으로 각 애플리케이션들을 사용할 수 있도록 하는 SSO 기술에 대해 살펴보았다. 대상 애플리케이션의 수정을 최소화할 수 있는 Delegation 모델과 토큰을 생성해 통합 인증 서비스를 제공하는 Propagation 모델 그리고 양자의 장점을 조합한 Delegation & Propagation 방식을 이해한다면 현재 도입 대상 기업의 IT 인프라와 진행중인 서비스 및 애플리케이션의 특성에 적합한 EAM 시스템 도입을 결정하는데 도움이 될 것이다.

 URL암호화를 통한 SSO구현

가장 큰 분류로는 아마도 sso 해야할 사이트가 같은 도메인 그룹인지 여부를 파악해야 할것 같네요.
예를 들어서 aaa.xxx.com, bbb.xxx.com 은 둘다 xxx.com 도메인 그룹안에 포함되어 있기 때문에 이 경우 쿠키를 이용한 sso가 가능합니다.
이 같은 도메인 그룹의 경우 굳이 세션을 이용하지 않고 쿠키를 이용하는 이유는 aaa.xxx.com은 PHP로 제작된 사이트 bbb.xxx.com은 ASP로제작된 사이트..즉 각 서버의 플랫폼이 틀리다면 세션 공유가 안되는것은 잘 아실겁니다. 그래서 플랫폼에 상관없이 클라이언트에 의존되는 쿠키를 이용하게 됩니다.

반면에 서로 도메인이 틀리다면 어쩔수 없이 url로 암호화 시켜서 이리저리 주고 받으면서 sso인증 시켜줘야 합니다.

쿠키를 이용한 방법이나 url로 이용한 방법이나 서로 원리는 똑같습니다. 그래서 그나마 설명하기 쉬운 url을 이용한 방법으로 말씀드리겠습니다. 아무래도 예제를드는것이 간단할듯 -_-...

A사이트 : test.com
B사이트 : abcd.com

aaa란 유저가 A사이트에서 로그인후에 B사이트로 가게 되면 B사이트가 자동으로 로그인 되어있게 하는거잖아요.
(물론 aaa란 계정이A사이트에도 있고 B사이트에도 있어야겠지요)

이럴때 단순히 B사이이트로 자동 로그인 시키고자 한다면 아무래도 아이디/비밀번호가 필요할겁니다. 아래와 같이요

abcd.com/logijn.asp?id=aaa&pwd=1234

헌데 이 id=aaa&pwd=1234 이 부분이 url에 노출되면 상당히 위험하지요 그래서 이 부분을 암호화 시키는 겁니다. 제 홈피에 몇가지 암호화 하는 구문들이 있는데 대부분 URL 정보 노출시키고 싶지 않아서 암호화 시킨다고 적어둔 것들입니다.(제가적은것은 아니고 여기저기 돌아다니다가 -_-.. )

그래서 암호화 시키면 아래처럼 url 변하겠지요

abcd.com?/login.asp?암호된값=dpZe-==234s

요렇게 변할겁니다..(대충 적은것임 -_-) 요 login.asp 페이지에서는 아래와 같이

암호된값 = Request("암호된값")
디코딩된값 = 디코딩(암호된값)    ' 암호된값을 디코딩 함수에 넣어서 암호된값을 id=aaa&pwd=1234 형식으로 보이도록 한다.

id=aaa&pwd=1234 이 값들 보이면 다 끝난거지요..요것 그냥 split로 이리저리 분할하면 id는 aaa , pwd=1234란 값 쉽게 취할수 있습니다.

음..대충 이해가 가셨는지..위에서 설명한 암호화 함수는 그냥 일반 하나의 함수처럼 얘기했는지 제 홈피에 있는 암호화 함수는 암호할때/풀때 어떤 키값으로 풀어야 합니다. 즉 암호할때 a란 키값을 통해서 암호 시켰다면 풀때도 a란 키값으로 암호를 풀어야 합니다. 좀 더 보안상 좋지요..

암호화 방식도 좋지만 ID/pass 가 노출된다는 단점이 있기때문에, 서버가 다를경우 인증키를 생성하는 function 을
만들어서 각 서버에서 생성된 인증키를 비교하는 방식도 괜찮은 방식이겠죠.

쿠키를 이용한 방법은 잠깐 설명드리자만 aaa.com사이트에 로그인 하면 쿠키를 던져둡니다. 던진 값은 2개 입니다 하나는 키값 다른 하다는 암호화된 값 그래서 abcd.com 으로 접속하면 일단  그 abcd.com의 login.asp 페이지에서 던져진 쿠키가 있는지 검사합니다. 그래서 있다면 그 던져진 값들을 이용해서 암호푸는 겁니다. 그리곤 로그인 시키는 거지요. 

정리하면
SSO 는 Delegation 방식(솔루션 존재.)과 Propagation 방식(직접구현)이 있고.
Propagation 방식에는 Cookie 를 이용하는 방법과 URL 인증 방법 이 있겠다.
대부분의 SSO 는 Propagation 방식을 많이 사용하는듯하다!!

소프트웨어 업체 대표 김아무개(43)씨도 조달청이 발주한 웹 표준화 사업 입찰 결과를 확인하려다 마찬가지 상황에 부닥쳤다. 익스플로러 8에서는 국가 종합 전자조달 시스템인 ‘나라장터’를 쓸 수 없기 때문이다. 조달청은 지난 20일 공지를 올려 “엠에스 익스플로러 8에서 액티브엑스 기능을 쓸 수 없기 때문에, 기존에 사용중인 익스플로러 6, 7을 그대로 쓰라”고 안내했다.

.....(생략)

정부에서는 8.0의 시기를 MS 와 협의 또는 공조를 했을터인데, 왜 사전확인및 검증조차도 않했는지 대략 난감하다.
아마도 일반기업에서는 이미 6개월 정도 이전에 MS 에 문의 및 협조를 부탁하여 방안을 검토하여 대응책을
마련했을터인데 공공기관은 그것조차 안한것으로 들어나 어이가 없을 지경이다.

제발. 자신의 일이라고 생각하고 일을 해줬으면 좋겠네요. 아니 이거 당연한거 아닌가??

IBM in talks to buy Sun Microsystems