Mountie it!

KISA 무선단말기에서의 공인인증서 저장 및 이용 기술규격

2010-03-12T01:00:00.001-08:00

KISA 무선단말기에서의 공인인증서 저장 및 이용 기술규격

[공인인증서 관리 소프트웨어]

문서의 첫장에 나오는 개요에서 다음과 같이 기술하고 있다.

"본 규격은 무선단말기에서의 공인인증서비스 상호연동성 확보 및 이용 편의성을 고려하여 무선단말기내 공인인증서 관리 소프트웨어의 요구사항을 정의한다."

즉 "공인인증서 관리 소프트웨어"에 대한 기술규격이고

PureWeb에서는 유효하지 않은 규격이다.

[아이폰의 경우 동작구조]

다른 무선단말기는 자세히 살펴보지 않았고

아이폰에 대한 기술 부록4를 자세히 살펴보았다.

아이폰 공인인증서 App은 다음 두가지 기능을 가지고 있다.

"공인인증서 저장기능"

"공인인증서 획득기능"

공인인증서 저장기능은 다른 App에 존재하는 공인인증서를 아이폰의 공인인증서 App으로 보내서 저장하는 방식에 대한 것이고

공인인증서 획득기능은 다른 App에서 공인인증서가 필요할 경우 "공인인증서 App"을 호출하여 인증서를 획득하는 방식에 대한 것이다.

기업은행 App을 가정하여 동작방식을 순서대로 열거해보면

(공인인증서 저장기능 이용시)

1) 유저가 기업은행 App을 호출(ibkapp이라고 가정)

2) 유저가 공인인증서 저장을 위해서 "공인인증서 내보내기" 메뉴를 App에서 호출

3) 공인인증서 App을 호출하기 위해서는

kisa-cert-exchange://?cmd=certpush&caller_url_scheme=ibkapp&callback=01&cert=base64(pfx)

의 링크가 사용된다.

4) 이후 공인인증서 App이 실행되고 인증서를 불러들여 저장해두고 처리가 끝나면

ibkapp://?cmd=certpush&callback=01&result=00

으로 결과를 return한다.

(공인인증서 획득기능 이용시)

1) 유저가 기업은행 App을 호출(ibkapp이라고 가정)

2) 해당 App에는 공인인증서가 없어서 공인인증서를 가져와야한다.

3) 공인인증서 가져오기 메뉴를 호출하면

kisa-cert-exchange://?cmd=certget&caller_url_scheme=ibkapp&callback=01

의 링크로 공인인증서 App을 호출한다.

4) 공인인증서 App은 어딘가(?)로 공인인증서를 내보내고

ibkapp://?cmd=certget&callback=01&result=00&cert=base64(pfx)

으로 결과를 return한다.

[반쪽짜리 공인인증서 App]

공인인증서 사용을 위해서는

공인인증서 신규발급, 재발급, 갱신등의 행위가 꼭 필요한데

이런 행위는 여전히 Windows IE ActiveX에서만 가능하며

기술규격은 공인인증서의 사용에 대해서만 정의하고 있다.

즉 아이폰에서 사용하더라도 여전히 ActiveX는 필요하다는 의미.

향후 공인인증서 App에서 인증서 신규발급, 재발급, 갱신등이 지원된다는 의미는 달라질 수 있음.

그러나 지금 현재는 여전히 반쪽짜리임.

[피싱(Phishing)에 취약한 공인인증서 App]

공인인증서 App을 호출하기 위해서 Custom URL Scheme을 이용한다.

현재 "kisa-cert-excange"라고 명시해두었는데

이 구조를 국가 인프라에 도입해서 이용하는것은 상당히 아주 위험하다.

아래 몇가지 예를 들어보았는데 위험성에 대해서 판단해보시길

1. 일반 웹사이트를 통한 피싱(Phishing)

해커가 http://trust.me 라는 해킹사이트를 운영한다고 가정

해당 사이트에는 다음 링크를 포함하고 있음.

<a href=kisa-cert-exchange://?cmd=certget?caller_url_scheme=http://trust.me&callback=01>Login</a>

아이폰으로 접속한 유저가 "Login"버튼을 누르면 공인인증서 App이 실행되고 인증서 내보내기 절차를 진행.

내보낸 인증서는 어딘가(?)에 가 있을것이고

해커는 인증서를 그 어딘가(?)에서 가져온다.

2. 해킹 App을 통한 피싱

또다른 경우는

해커가 공인인증서 App과 동일한 Custom URL Scheme을 가지는 피싱 App을 올려두고 기술규격 Spec에 맞게 반응하도록 구성하였다면

유저가 은행 뱅킹 App을 실행하고 인증서 내보내기를 실행하는 순간

KISA 공인인증서 App이 실행되는것이 아니고 해커가 준비한 App이 실행되어 공인인증서를 해커 서버로 탈취해갈 수 있다.

App등록이 통제되는 상황에서는 아주 희박한 경우이겠지만 Jailbroken iphone에서는 가능성이 없지 않다.

Custom URL Scheme이 중복되면 iPhone에서는 가장 나중에 설치된 App이 호출된다.

3. 의도하지 않은 선량한 앱에 의한 피싱

만일 선량한 다른 개발자가 의도하지는 않았지만

my.specialapp.kisa-cert-exchange 라고 URL Identifier를 기록했다면

이 App도 역시 kisa-cert-exchange://... 에 반응하여 호출된다.

유저는 공인인증서 App이 호출되기를 기대하였지만 엉뚱한 App이 호출될 가능성이 존재하는것이다.

[Gateway Server에 대한 규격 부재]

기술규격에는 명시되어 있지만

App to App으로 데이터를 전송하기 위해서는 Gateway Server가 필요하다.

이미 기업은행이나 하나은행 App에서 그러한 구조를 취하고 있다.

공인인증서 App에서 내보내기한 공인인증서(Private Key를 포함)가 어딘가로 전달되는데

이곳이 어디인지, 어떻게 관리되어야하는지등이 명확하게 표현되어 있지 않다.

결국 나의 공인인증 개인키가 아이폰 어플에서 공인인증서가 필요로 할때마다 외부로 나갔다 들어오는 과정을 반복하는데

의도적으로 숨기는것인지

아니면 아직 규격을 정한만한 사항이 아니라는건지 궁금하다.

아주 핵심적인 규격 하나가 빠져있어서

현재의 기술규격 자체도 반쪽짜리 규격이다.

[투명한 논의과정 부재]

KISA 내부에서 어떤 논의 과정을 거쳐 이런 규격이 제정되었는지

회의록이라도 볼 수 있으면 좋겠다.

[References]

Custom URL Scheme관련해서는 아래 URL들을 참조하세요.

http://iphonedevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html

http://iphonedevelopertips.com/cocoa/launching-other-apps-within-an-iphone-application.html

http://www.handleopenurl.com

애플 유료앱 결제와 규제

2010-03-09T07:53:00.001-08:00

애플 유료앱 결제와 규제

아이폰이나 아이팟터치 사용자라면 한번쯤 유료앱을 결제후 다운로드 받아본 경험이 있을것이다.

유료앱은 돈을주고 구매하는 프로그램으로

국내소비자를 대상으로 한국어 서비스가 되며 국내 신용카드로 결제하게 된다.

이 과정에서 국내 법규정이 어떻게 적용되고 있는지 살펴보자.

1. iTunes에서 "Create New Account"메뉴의 첫화면이다.

2. iTunes Store 사용 약관 동의과정

사용 약관중에서

"귀하는 라이센스된 애플리케이션을 미합중국 법...

라이센스된 애플리케이션을 (a)미국의 수출 봉쇄 국가로...

(b) 미국 재무성의...

또는 미국 상무성 거부 인물 목록....

미국법에서 금지하는 목적으로 사용하지 않기로 동의합니다."

라는 약관조항이 보인다.

즉 미국법을 준수한다는 동의과정이 포함된것이 이상함.

3. iTunes Store 계정(Apple ID) 만들기

유료앱 구매를 위한 iTunes Store 계정을 만드는 항목이다.

우측 상단의 "보안 연결" 이라는 메세지가 눈에 들어온다.

4. 지불방법 선택

여기서부터 본격 카드결제 관련 정보를 입력한다.

카드정보 입력화면을 국내 법규정에 대비하여 비교해보면 아래와 같다.

4.1 본인확인을 위한 전자인증 (여신전문금융업 감독규정 제24조의 6)

관련규정에서는 신용카드사가 전자인증을 제공해야한다고 되어 있는데

실제 국내 카드사가 본인확인을 위한 전자인증을 제공하고 있는것 같지는 않다.

"보안 코드"라는 것을 통해서 카드를 실제로 소지하고 있는지 여부만을 확인한다.

실제 카드정보를 입력하면 다음단계에서 본인확인 절차가 있을 수 있으니

이 단계에서 예단하기는 시기상조.

4.2 30만원이상 결제시 공인인증서 적용 (전자금융거래법 시행세칙 31조)

iTunes Store를 통해 구매가능한 유료앱중에서 30만원이 넘는 것들도 상당수 존재한다.

그러나 이 결제화면에서 공인인증서 관련 일체의 요구사항을 볼 수 없다.

4.3 금융거래정보의 종단간(End to End) 암호화 (전자금융거래법 시행세칙 29조)

SSL을 적용하고 있는것으로 짐작됨

화면 하단에

"Apple uses industry-standard encryption to protect the confidentiality of user personal information"이라는 문구로 짐작

4.4 입력정보 보호대책 (전자금융거래법 시행세칙 29조)

유저가 입력하는 카드정보 입력을 보호하는 키보드 보안 프로그램이나

하다못해 스크린키보드도 보이지 않는다.

4.5 악성코드 예방대책 (전자금융거래법 시행세칙 29조)

안티바이러스나 방화벽등에 대한 항목은 찾아볼 수가 없다.

웹어플리케이션 보안 관련해서는 단단한 보호를 하였을걸로 짐작해볼수는 있음.

5. 계정생성됨

끝났다. 허무하다.

본인확인을 위한 전자인증이나 이런것 없이 그냥 끝났다.

이렇게 등록한 카드정보로 이제 자유롭게 iTunes Store의 상품을 마음껏 구매할 수 있다.

아이팟이나 아이폰등에서 자유롭게 구매할 수 있는것은 말할필요도 없고

아이패드나 윈도우즈, Mac OS등에서 제한없이 구매가능하다.

국내 유저가 국내 카드로 한국 iTunes Store에서 구매가능한 유료앱이다.

공인인증서 사용안하고 결제 잘된다.(당연히)

"국내와 국외에 다른 규제"

한국 쇼핑몰에 애플처럼 쇼핑몰을 구성하는것은 규제때문에 꿈도 꾸지 못한다.

그런데 애플은 국내에서 전자금융거래법이나 기타 다른 제도적 제약없이 자유롭게 상품을 판매하고 있다.

SK T Store나 삼성 앱스토어에서 이런식으로 AppStore를 꾸미면 경쟁력 있을것인데

결제방식에서부터 근본적으로 국내 AppStore와 애플 AppStore가 경쟁이 안된다.

본인확인을 안해도 되는 유튜브가 국내 1위 동영상 사이트가 되었지만

국내 업체들은 여전히 제도적 규제때문에 실명제를 준수하고 있다.

전자상거래에서도 각 쇼핑몰 업체별로 나름 안전하고 간편한 방식을 선택하여 영업하려고 해도

만만한 국내업체는 거래를 중단시키면서까지 제제를 가하지만

해외업체는 예외(?)가 적용되는 현실이 안타깝다.

이미 애플 iTunes Store를 보면 알듯이 전자상거래에는 국경의 제약이 없다.

국내 규제로 인해 전자상거래를 위축시키지 않았으면 하는 바램이다.

한국에서 ActiveX가 광범위하게 사용되는 이유

2010-03-04T05:33:00.001-08:00

한국에서 ActiveX가 광범위하게 사용되는 이유

국내에서 ActiveX가 광범위하게 사용되는 원인에 대해서 제가 알고 있는 몇가지 요소들을 기술해봅니다.

1. 공인인증서

공인인증기관이 MSIE ActiveX기반으로만 서비스를 제공합니다.

2. 신용카드 전자상거래 ISP결제

BC, 국민에서 설립한 자회사 K모사에서 개발하였고 ActiveX형태로만 동작합니다.
국민, BC카드의 전자상거래 결제는 모두 ActiveX로만 가능한 이유입니다.

3. 전자금융거래법 시행세칙 29조

안티바이러스 ActiveX, 키보드보안 ActiveX, 개인방화벽 ActiveX가 모두 이 규정에서부터 파생되었습니다.

4. 금융거래시 전자서명

금감원에서 금융거래시 전자서명을 요구하며
공인인증 전자서명은 현재 ActiveX로만 가능합니다.

5. 보안서버 구축

http://secsv.kisa.or.kr/secsv/jsp/secsv.jsp 참조
정보통신망 이용촉진 및 정보보호등에 관한 법률하위 시행령 하위 개인정보의 기술적 관리적 보호조치 기준 제5조에서

SSL방식과 응용프로그램방식을 모두 인정하고 있습니다.

응용 프로그램 방식은 공인인증서 사용모듈과 유기적으로 결합되어 하나의 ActiveX로 전자서명이나 End-to-End 암호화가 가능한점을 개발업체에서 장점으로 홍보하고 있어서 일반 업체에까지 광범위하게 ActiveX가 확산되게한 원인입니다.
전자상거래 안심클릭 결제에 ActiveX가 사용되는 주요 이유중 하나입니다.

6. MSIE Auto Popup 차단

MS에서 특허나 보안등 여러가지 이유로 Auto Popup을 차단하고 있습니다.
단 해당 서버 도메인이 Trusted Zone에 속하는 경우 Auto Popup이 가능합니다.
신용카드 안심클릭 결제등은 팝업구조로 결제가 진행됩니다.
많은 PG업체들이 결제팝업이 차단되는것을 방지하기 위해서 해당 업체 도메인을 MSIE Trusted Zone에 자동 추가하는 기능이 포함된 ActiveX를 결제시작하기전에 설치요구하고 있습니다.

7. iframe에 대한 오용

- ActiveX를 사용하더라도 이것이 꼭 필요한 단계에서만 사용하면 되는데 국내 현실은 일단 접속하는 모든 유저에게 ActiveX를 깔도록 요구합니다.
- 단순히 웹사이트를 둘러보기만 할 대다수 유저들에게 ActiveX를 깔도록 요구하는것은 불필요한 보안위험을 증대시킵니다.
- 실제로는 Javascript DOM 제어등을 통해 ActiveX를 꼭 사용해야한다면 그때 잠깐 활성화하여 사용할 수 있지만
- 상당수 업체들이 R&D가 부족하여 iframe등을 통해 무조건 ActiveX를 깔도록 요구합니다.

윈도우모바일6.1 해킹관련 PureWeb기반 보안대책

2010-02-01T05:50:00.001-08:00

윈도우모바일6.1 해킹관련 PureWeb기반 보안대책

http://news.donga.com/It/New/3/08/20100201/25872427/1&top=1

기사를 보면 윈도우모바일 6.1 해킹관련 기사가 크게 났다.

퓨어웹환경에서의 보안대책을 고민해보았다.

1. 해킹절차

1) 유저는 해커가 준비한 웹사이트 방문

2) 유저는 해커가 유도한 프로그램 다운로드하여 자신의 기기에 설치

3) 유저가 웹사이트 방문하여 입력하는 정보를 Key-Logging

4) Logging한 정보를 해커가 설치한 프로그램을 통해 해커서버로 전송

5) 해커가 유저를 대신하여 쇼핑몰에서 상품 구매

6) Key-Logger로 빼낸 정보를 이용자를 가장하여 입력

7) 이통사에서 SMS문자인증 메세지 발송

8) 원 유저의 폰에서 문자 수신

9) 원 유저 폰에 설치된 프로그램이 문자내용을 해커에게 전송

10) 해커는 쇼핑몰에서 SMS 인증번호 입력하여 상품정상결제

2. PureWeb기반 보안대책

2.1 입력정보 보호대책

2.1.1 Javascript Screen Keyboard이용하여 keylogging 방지

- Javascript입력정보는 Javascript sandbox내에서만 존재함

- screen keyboard 배열을 세션 연계하여 random하게 변경

2.1.2 Javascript 보안

- Javascript 무결성 검증

- Javascript 동적 로딩 및 난독화

- Caja를 이용하여 보호

2.2 악성코드 예방대책

2.2.1 취약점이 존재하는 OS및 브라우저를 이용한 결제접근 차단

- Server에서 Browser UA정보 확인하여 취약점이 존재하고 벤더제공 패치가 나오지 않은 경우 결제접근 차단

2.2.2 이용자에게 보안권고 및 인지동의과정 추가

- 프로그램을 함부로 설치하지 않도록 보안권고

- OS 보안 업데이트 권고

- 본격 안티바이러스 설치 권고(가능하다면)

2.3 카드정보등 주요정보 Client 저장금지

- screen keyboard로 입력된 카드번호등은 서버전송후 browser memory에서 제거

- 주요정보는 browser sandbox내에서만 잠간 존재했다가 사라짐

순수웹환경에서의 전자금융 서비스 보안방안

2009-12-23T20:00:00.001-08:00

순수웹환경에서의 전자금융 서비스 보안방안

ActiveX등의 Binary Plugin없이 순수웹(Pure Web)으로 전자금융서비스를 제공할 경우 어떤 보안대책이 필요할까

고민해보고 PCIDSS나 전자금융거래법 시행세칙등을 참조하여

최소한 아래와 같은 요구사항은 충족해줘야겠다는 생각이다.

이미 많은 기관들이 아래 보안요구사항들을 충족하고 있겠지만 확인하는 차원에서 한번더 정리해본다.

[순수웹환경에서의 전자금융서비스 보안]

1. 안전한 네트웍을 구축하고 유지

1.1 방화벽을 설치하고 유지

1.1.1 방화벽 구성 기준 수립

- 변화관리 시스템 유지 (모든 설정변경사항을 승인하고 테스트하는 공식 절차가 존재해야함.)

- 최신의 네트워크 구성도 유지

- 인터넷과 내부 네트워크 사이에 DMZ Network 운용

- 네트웍 구성요소에 대한 조직, 역할 및 책임을 정의

- 모든 서비스, 프로토콜, 포트 사용에 대한 문서화 및 사용근거 명시

- 안전하지 않은 프로토콜 사용시 이에 대한 보안대책 수립하고 문서화해야함.

- 최소 6개월마다 룰셋 검토해야함.

1.1.2 방화벽 및 라우터 구성

- Inbound / Outbound 트래픽 제어

- default deny rule

- 라우터 설정파일의 보호 및 동기화

- 무선네트워크와 내부시스템사이에 방화벽 설치

1.1.3 내부 시스템에 대한 외부자의 직접접근 제한

- 외부자의 이용가능한 프로토콜 제한

- DMZ Network을 거치도록 네트웍 구성

* 외부에서 Inbound traffic은 DMZ 내의 IP로 제한

* 내부 시스템에서의 outbound traffic도 DMZ내의 IP로 제한

* 필요시 forward / reverse Proxy 구성 운영

* reverse proxy는 웹방화벽으로 대체가능

- 방화벽에서는 Stateful Inspection을 적용 (이미 체결된 접속만을 네트워크로 허용)

- Database는 DMZ으로부터 분리된 구간에 위치시킴

- NAT나 PAT처럼 내부주소가 그대로 공개되지 않도록 주소변환 기술 이용

1.1.4 개인방화벽 소프트웨어 설치 또는 활성화

1.1.4.1 내부 사용자 시스템

- 방화벽 설정은 회사에서 정한 표준규칙을 따라야함.

- 개인이 임의로 방화벽 설정을 해제할 수 없도록 해야함.

1.1.4.2 외부 사용자 시스템

- 서버에서 사용자 개인 PC 환경을 직접 제어할 수 없다는 기본적인 사실 인지

- 다양한 운영체제에 맞는 개인 방화벽 프로그램이나 활성화하는 방법을 자세하게 안내

1.2 안전한 시스템 구성

1.2.1 벤더제공 디폴트값 변경

- SNMP Community String이나 기본 패스워드 등 변경

- 무선환경에 대해서도 디폴트값 변경

1.2.2 시스템 설정 기준 수립

- 시스템 설정 기준은 알려진 모든 보안취약점에 대응하도록 수립되어야함.(SANS, NIST, CIS등 업계가 인정하는 보안강화 기준을 참조)

- 서버당 하나의 주요 기능만을 구현

- 불필요한 서비스나 프로토콜은 비활성화

- 오용방지를 위한 시스템 보안 파라미터 설정

- 스크립트, 드라이버, 기능, 하위시스템, 파일시스템, 불필요한 웹서버등 모든 불필요 기능 삭제

1.2.3 모든 전송데이터에 대한 암호화

- 콘솔 접근을 제회

- SSH, VPN또는 SSL/TLS등의 기술을 이용

2. 고객정보 보호

2.1 저장된 고객정보 보호

2.1.1 고객 개인정보는 최소범위에서 저장

- 법적, 제도적 요구사항을 감안하여 데이터 보유 및 폐기정책 수립

- 데이터 보유 및 폐기정책에 따른 자동삭제 소프트웨어 구성

2.1.2 중요한 개인인증 데이터를 저장하지 않음.

- 중요 개인인증 데이터는 암호화 여부와 관계없이 저장하지 않음.

- 중요 개인인증 데이터를 수신이후 삭제하는 경우 복구 불가능하게 데이터를 삭제해야함.

2.1.3 중요 개인정보 출력시 마스킹 처리

- 전체의 일부만 표시

2.1.4 고객정보는 암호화하여 저장

- 모든 로그파일에 개인정보가 존재하지 않아야함.

- 백업매체 저장되는 경우도 암호화하여 저장해야함.

- 모든 운용자 PC에 개인정보가 존재하지 않아야함.

- 로그파일이나 개인PC에 개인정보가 존재하지 않음을 자동화된 프로그램으로 검증해야함.

2.1.5 암호화에 사용된 암호화키는 안전하게 보호되어야함.

- 암호화키에 대한 접근을 최소한의 관리자로 제한

- 암호화키를 최소한의 장소와 형태로 안전하게 저장

- 키관리 프로세스를 문서화하고 정해진 절차를 따라야함.

- 암호화키는 강력한 보안비도로 생성

- 암호화키는 안전한 과정을 거쳐 배포

- 암호화키는 안전하게 저장되어야함.

- 정기적으로 암호화키를 보호해야함.

- 암호화키는 2인 이상에 의해 이중통제되어야함.

- 암호화키는 승인받지 않고 교체될 수 없어야함.

- 암호화키 관리자의 이해와 책임을 수용하는 동의서를 작성하고 비치해야함.

2.2 공중망을 통한 고객정보 데이터 전송 암호화

2.2.1 공중망의 범위

- 인터넷

- 무선기술을 이용한 네트웍 (GSM, CDMA, GPRS, WIFI, 기타)

2.2.2 SSL/TLS, IPSEC등과 같은 보안 프로토콜을 사용해야함.

- 강력한 보안비도의 Symmetric Algorithm이 사용되어야함.

- 신뢰할 수 있는 CA인증서여야함.

- SSLv3/TLSv1등 안전한 SSL Protocol을 사용해야함.

- 사용자가 SSL 서버인증서와 도메인 및 사이트운영 기관을 명확히 확인할 수 있도록 EV(Extended Validation) SSL 서버 인증서를 이용

2.2.3 안전한 무선네트워크 암호화 적용

- WEP 사용 금지

- IEEE 802.11i등 강력한 암호화 적용

2.2.4 일반 사용자 메시징 기술을 통해 주요 고객정보 전송금지

- E-Mail, Messenger, Chat등을 통해 고객정보 전송금지

3. 보안취약점 관리

3.1 안티바이러스

3.1.1 내부사용자

- 운영자 PC에는 안티바이러스 소프트웨어를 적용

- 바이러스 감염가능한 서버시스템에도 안티바이러스 소프트웨어 적용

- 모든 시스템의 안티바이러스 적용여부를 확인할 수 있어야함.

- 안티바이러스 감사 로그를 생성할 수 있어야한다.

3.1.2 외부사용자

- 서버에서 사용자 개인 PC환경을 직접 제어할 수 없다는 기본적인 사실에 인지

- 다양한 운영체제에 맞는 안티바이러스 프로그램이나 활성화하는 방법을 자세하게 안내해야함.

3.2 안전한 시스템과 어플리케이션을 개발하고 유지

3.2.1 내부시스템

- 모든 시스템과 소프트웨어에는 벤더제공 최신 보안 패치를 설치해야함.

- 새로운 보안취약점을 식별하는 프로세스를 수립해야함.

- 확인된 새로운 보안취약점에 대한 대응방안을 "시스템 설정기준" 문서에 반영해야함.

3.2.2 외부 사용자 시스템

- 서버에서 사용자 개인 PC환경을 직접 제어할 수 없다는 기본적인 사실 인지

- 사용자 이용환경에 대한 보안패치 안내

- 사용자에게 보안업데이트이 중요성과 설치방법을 각 운영체제별로 충분히 안내

- 윈도우 운영체제일 경우 OS Update나 KISA에서 제공하는 PC자동보안 업데이트 프로그램을 설치안내

3.3 소프트웨어 개발 라이프사이클 전반에 걸쳐 정보보호 관련 사항을 통합해야함.

3.3.1 반드시 운영시스템 적용전 테스트를 수행

- 모든 입력값 검증테스트 수행

- 적절한 에러처리 검증 테스트 수행

- 안전한 암호화 저장 검증 테스트 수행

- 안전한 커뮤니케이션 검증 테스트 수행

- 적절한 역할기반 접근제어(RBAC) 검증 테스트 수행

3.3.2 개발, 테스트 및 운영환경을 분리해야함.

3.3.3 개발, 테스트 및 운영환경에 대한 직무를 분리해야함.

3.3.4 운영데이터를 테스트나 개발을 위해 사용하지 않아야함.

3.3.5 운영시스템 가동전 테스트트 데이터나 계정을 제거해야함.

3.3.6 어플리케이션 가동전, 고객배포전 개발계정, 사용자ID, 임시 패스워드 제거해야함.

3.3.7 제3자에 의한 개발코드 리뷰를 거쳐야함.

- 코드 작성자 외의 제3자에 의한 코드리뷰가 필요

- 코드 리뷰 결과는 경영층에 의해 검토되고 승인되어야함.

- 코드 리뷰시 OWASP와 같은 코딩 지침에 따라 개발되었는지 검토해야함.

3.4 변경관리절차에 따라 시스템 구성요소 변경

- 변경의 영향에 대한 문서화

- 적합한 관리자의 승인

- 운영기능 테스트

- 복귀(Back-out) 절차

3.5 OWASP 취약점 대응

- 크로스사이트 스크립팅(XSS) 대응

- SQL Injection등 Injection 오류에 대응

- 사용자가 어플리케이션에 실행가능한 악성파일을 올릴 수 없고 실행되지 않도록 악성파일 실행을 방지해야함.

- 시스템 내부 Object를 사용자에게 노출하지 않도록 불안전한 직접 객체 참조 방지

- 크로스 사이트 요청변조(CSRF) 방지

- 오류 메세지등에서 주요정보가 유출되지 않도록 정보유출과 부적절한 에러처리 방지지

- 취약한 인증 및 세션관리 방지

- 불안전한 암호화 저장 방지

- 모든 인증과 민감한 통신에 적절한 암호화를 적용하여 불안전한 통신을 예방

- URL접근통제 실패 대응

- 기타 OWASP version별 보안취약점에 대하여 대응해야함.

3.6 웹어플리케이션 보호

- 정기적으로 자동화된 웹어플리케이션 취약점 보안측정 도구 혹은 방법으로 취약점 검토

- 웹방화벽 설치

3.7 Anti keylogger

- 사용자 개인 PC가 침해되었더라도 전자금융거래에 필요한 최소한의 보안성을 확보하기 위해 키보드 해킹방지 솔루션 적용할 수 있음.

- 자바스크립트 기반의 "Onscreen Keyboard"를 이용하여 사용자가 키 입력을 하지 않도록 유도

- 키 배열은 세션별로 Random하게 배치

3.8 자바스크립트 보안

- 자바스크립트의 무결성(Integrity)를 확인할 수 있는 체계를 수립하여 적용

- 자바스크립트 난독기(Obfuscation)을 적용할 수 있음.

- 자바스크립트의 일부를 서버에서 필요시 동적으로 로딩하여 사용

- 자바스크립트의 주요 소스를 세션정보와 연계하여 Static하게 재사용 불가하도록 구성

3.9 피싱방지를 위한 조치

- 사용자 아이디 입력 페이지와 로그인 페이지를 순차로 배치하고

- 로그인 페이지에서 해당 사용자가 미리 선택한 seal이나 site key아이콘이 뚜력이 드러나도록 설계한다.

- 서버가 EV SSL 인증서를 채택하는 경우 사용자들이 EV SSL 인증서 채택 서버에 접속해 있음을 확인하고

- 로그인 정보를 입력하도록 해당 정보 입력란 근처에 설명, 안내한다.

- 사용자의 명시적 요청이 없는한 서버가 사용자에게 명세서, 기타 안내 메일을 보내지 않는다.

3.10 부인방지

3.10.1 사전 약정에 의한 부인방지 효력 부여

- 부인방지 효력은 오프라인 서명이나 인감날인 및 온라인 공인 전자서명으로 발생됨

- 사전 약정과정에서 온라인에서 특정 인증정보 사용시 부인방지효력을 명시하고 동의받음.

- 특정 인증정보는 아래와 같은 사항을 고려한다.

* OTP 인증코드사용

* 이체 비밀번호 사용

* 로그인 비밀번호 재입력

* 기타 플랫폼 독립적인 별도 방식 이용

3.10.2 기술적 부인방지

- 계좌이체와 같은 금융거래시 악성 코드의 Form데이터 조작에 의해 사용자의 보안빙자 자체에 위해가 가해질 수 있음.

- 공격에 의한 데이터 조작으로 부인방지 효력상실을 방지하기 위한 기술적 절차적 수단을 강구한다.

* 실시간 수행하지 않고 시차를 두어 Queue에 쌓아둔 후 사용자에 의한 추심 인증이 있을때 거래를 승인한다.

3.10.3 추심인증

- 일정조건의 거래에 대해서 사용자가 접속한것과 다른 채널 (SMS, OTP, 전화 등)을 통해서 2차 인증하는 정책을 유지해야함.

4. 강력한 접근통제

4.1 업무상 알 필요가 있는지에 따라 개인정보 접근제한

4.1.1 해당 데이터가 필요한 직원에게만 접근 허용

- 사용자 ID는 직무수행에 필요한 최소권한으로 제한

- 권한할당은 직원의 직무분류와 기능을 근거로

- 공식적인 관리자의 승인절차를 거침

- 자동화된 접근통제 시스템의 구현

4.1.2 Default Deny 접근통제 정책 설정

- 모든 시스템 구성요소를 포함

- 직무분류와 기능을 기준으로 개인별 권한 할당

4.2 사용자별 고유 ID 부여

4.2.1 시스템에 접근하는 모든 사용자에게는 사용자를 구분할 수 있는 고유 ID를 발급해야함.

4.2.2 고유ID는 패스워드등 추가 인증방식으로 사용자를 인증해야함.

4.2.3 원격 접속시 2-Factors 인증 적용해야함.

4.2.4 모든 패스워드에 대해서 강력한 암호화를 적용해야함.

4.2.5 공식적인 사용자 인증 및 패스워드 통제절차를 마련해야함.

- 사용자의 추가, 삭제, 수정에 대한 통제절차를 마련해야함.

- 패스워드 재설정전 사용자 신원확인

- 초기설정 패스워드는 즉시 변경 유도

- 퇴사/ 탈퇴시 접근권한 즉시 말소

- 최소 90일마다 미사용 사용자 계정 재거 또는 정지

- 원격유지보수를 위한 계정은 일정시간만 사용가능하게 설정

- 모든 사용자에게 패스워드 절차와 정책 배포

- 공용 패스워드사용 금지

- 패스워드는 90일마다 변경

- 최소 7자리의 패스워드 자릿수

- 영문과 숫자를 포함한 복잡한 패스워드 사용

- 과거 4회까지의 패스워드 재사용금지

- 6번이상 접근실패시 사용자 계정 자동잠금

- 계정잠금시 최소 30분간은 유지

- 세션이 15분이상 Idle상태인 경우 자동 Timeout

- 데이터베이스에 대한 접근통제 포함

4.2.6 외부 사용자에 대한 두가지 이상 요소로 사용자 인증

- 명확하고 안전하게 사용자 인증을 하기 위ㅐ서 최소한 2가지 이상의 방식을 복합하여 사용자 인증을 수행

- 복합 사용가능한 인증요소로 다음사항을 고려

* 패스워드 (조회 또는 이체에 복수 사용 가능)

* 일회용 암호 생성기(OTP) 혹은 모바일 OTP 소프트웨어

* 모바일 SMS 인증

* SSL Client Authentification하의 공인인증서 로그인

- 위 인증방식들을 제시하고 이중 사용자가 2개 이상을 복합적으로 선택하여 인증을 수행할 수 있도록 제공

4.3 물리적 접근통제

4.3.1 적절한 출입통제 사용

- DVR등을 통한 감시

- 네트웍 잭에 대한 접근통제

- 무선 AP에 대한 접근통제

- 휴대용 장비에 대한 접근통제

4.3.2 직원과 방문자 식별절차 마련

4.3.3 모든 방문자에 대한 적절한 통제

4.3.4 방문자 활동기록 보관

4.3.5 안전한 백업매체 보관

4.3.6 개인정보를 포함한 종이 및 물리적 전자매체에 대한 보호

- 해당 매체가 기밀로 식별되도록 분류

- 이동시 추적가능한 안전한 방법으로 전달

- 이동에 대한 관리자 승인

4.3.7 개인정보를 담고 있는 저장소나 매체에 대한 엄격한 접근통제

- 매체목록을 유지하고 연 1회 재고조사

4.3.8 불필요 정보에 대한 적절한 파기

- 복구불가능한 방법으로 파기한다.

- 종이 분쇄기 이용

- 전자매체에 대한 DeGausser이용 파기

5. 모니터링 및 테스트

5.1 모든 접근을 추적하고 감시

5.1.1 모든 접근시도에 대한 개별 사용자 연관 프로세스 수립

5.1.2 자동화된 감사추적기능 구현

- 사용자 식별

- 이벤트 종류

- 날짜와 시간

- 성공 혹은 실패 표시

- 이벤트의 시작지점

- 영향받는 데이터, 시스템 구성요소 또는 자원으 신원 또는 이름

5.1.3 시간동기화 설정

5.1.4 감사기록에 대한 무결정(Integrity) 보호

5.1.5 모든 로그에 대한 일일 점검

5.1.6 로그기록은 최소 1년간 보관

5.2 보안시스템 및 프로세스에 대한 정기적 시험

5.2.1 분기별 1회 무선보안 취약점 시험

5.2.2 정기적 네트웍 취약점 스캐닝

- 최소 분기별 1회

- 내부 및 외부 취약점 스캐닝

5.2.3 정기적 침투시험

- 내부 및 외부 네트워크 계층 침투 시험

- 내부 및 외부 어플리케이션 계층 침투 시험

- 침투시험시 알려진 모든 해킹기법을 이용한 침투 시험실시

5.2.4 IDS/IPS를 이용하여 시스템 보호

5.2.5 시스템 파일 무결성(Integrity) 감시 소프트웨어 운용용

6. 보안정책관리

6.1 정보보호 정책의 수립, 공표, 유지관리 및 배포

- 여기서 언급되는 모든 보안요구사항이 다루어져야함.

- 위협과 취약점을 파악하고 공식적인 위험평가를 수행하는 연간 프로세스가 포함되어야함.

- 최소한 매년 검토되어야함.

6.2 일일 보안점검 절차 수립

6.3 직원들이 사용하는 중요한 기술들에 대한 사용정책 제정

- 사용에 대한 명시적 관리자 승인

- 기술사용에 대한 인증

- 장비목록과 사용자 목록 유지

- 소유자, 연락처, 사용목적이 명시된 라벨링

- 해당기술의 합당한 사용

- 해당기술에 대한 네트워크상의 합당한 위치

- 회사가 승인한 제품 목록

- 특정 시간동안 활동이 없을 경우 자동 세션 종료

- 벤더에 의한 운격접근기술은 필요시만 이용하고 사용후 즉시 구동중지

- 원격접근시 데이터 복사, 이동, 저장 금지

6.4 모든 직원과 계약업체의 정보보호 관련 책임을 명확히 규정

6.5 직원 또는 팀에게 정보보호 관리 책임 할당

- 정보보호 정책과 절차의 수립, 문서화 및 배포 책임

- 보안경고 및 정보 감시/분석하고 적절한 인력에게 배포하는 책임

- 보안사고 대응 및 보고절차를 수립/문서화/배포 책임

- 사용자 계정 관리 책임

- 데이터 접근 감시 및 통제 책임

6.6 정보보호 중요성을 인식할 수 있는 공식적인 보안인식 프로그램 이행

6.7 직원고용이전 적격 심사 수행

6.8 외부 서비스 업체와의 상호연동을 위한 정책과 절차를 유지하고 이행

6.9 침해사고 대응계획 수립

한국형 전자상거래 서비스 제공자간 상호연동 표준안(KECIS)

2009-12-22T23:13:00.001-08:00

한국형 전자상거래 서비스 제공자간 상호연동 표준안

Korea Electronic Commerce Interoperability Standard

(분산환경에서 서비스 제공자들간의 상호 연계를 위한 데이터 송수신 표준 구조)

1. KECIS가 왜 필요한가?

- 다양한 서비스 제공자간의 표준화된 데이터 송수신 "방법" 부재

- 다양한 서비스 제공자간의 표준화된 데이터 송수신 "구조" 부재

- 위 "부재"로 인해 서비스 연동을 위한 중복된 Resource 소모, 복합적인 서비스 연계 불가

- 유저가 쇼핑몰(Shopping Service Provider)에 접근하는 경우
- 공급자는 유저에 대하여는 자신의 방식으로 서비스를 제공한다.
- 공급자는 자신과 전용으로 연결되어 있는 각각의 서비스 제공자와 별도 연결.

==> 각 공급자간의 표준 데이터 송수신 방법 부재

- 분산환경하의 결제서비스 공급자(Payment Service Provider)를 포함한 다수의 공급자들(Providers)이 자유롭게 결제및 인증 구조에 참여할 수 있는 표준화된 데이터 송수신 구조 확립이 필요

1.1 ECML을 이용한 구조 표준화

- XML Encryption으로 데이터 암복호화

- XML Signature으로 데이터 전자서명/서명검증

- 공인인증 인프라 이용

1.2 SAML이용하여 송수신 방법 표준화

2. KECIS는 누구에게 필요한가?

2.1 분산환경에서의 다양한 공급자들

다양한 형태의 서비스 공급자들이 인터넷 상이 존재한다.

- 쇼핑몰 서비스 공급자

- 신용카드 결제서비스 공급자

- 휴대폰 결제서비스 공급자

- 계좌이체 결제서비스 공급자

- 공인인증 인증서비스 공급자

- i-PIN 인증서비스 공급자

- OpenID 인증 서비스 공급자

- 배송서비스 공급자

- 문자발송서비스 공급자

이 공급자들은 나름의 방법으로 서비스를 유저에게 제공

3. KECIS에서는 공급자들간 무엇을 주고받는가?

3.1 K-ECML 포맷의 XML Message

3.1.1 ECML (Electronic Commerce Modeling Language)

- ECML v1 by RFC2706 at 1999

- ECML v1.1 by RFC3106 at 2001

- ECML v2.0 by RFC4112 at Jun/2005

- IETF에서 기술적인 개발 및 변경관리 수행

3.1.2 K-ECML as ECML addon

- 국내 카드사 코드 추가

- 국내 카드거래 종류 추가 (금액인증, ISP, 안심클릭 등)

- 국내 결제수단 추가 (계좌이체, 휴대폰 결제, 가상계좌 입금통지 등)

3.2 K-ECML Field List

http://spreadsheets.google.com/pub?key=twnKwUenX4TKLP9-NJqFOEA&output=html

4. KECIS에서는 공급자들간 어떻게 데이터를 주고받는가?

4.1 SAML 이용

- SAML의 데이터 송수신 구조 응용

- 유저 브라우저가 데이터 송수신의 라우터 역할을 함.

4.1.1 SAML Use Case Diagram

- Google Login with SAML

4.2 KECIS의 SAML 응용 데이터 흐름도

4.3 이용자와 다수의 공급자

각 공급자는 기존의 존재하는 자신만의 방식으로 그대로 서비스를 제공하면서
다른 서비스 제공자와 서비스 결과를 표준화된 방식으로 주고받을 수 있다면

하나의 공급자가 모든 서비스를 묶어서 힘들게 제공할 필요없이

자신이 가장 잘하는 서비스를 집중하여 유저에게 제공하며
자신이 보유하고 있지 않은 서비스를 해당 서비스 공급자에게 표준적인 방법으로 요청(*)하고
그 결과를 역시 표준적인 방법으로 응답받아 확인(*) 하고
다음 프로세스를 진행할 수 있다.

각 공급자간의 데이터 송수신은 XML Message를 기반으로 하며

공급자의 공인인증서로 상호 XML 전자서명 - 서명검증 하거나
XML 암호화 - 복호화 하여 데이터를 주고받으며
주고받는 데이터의 구조는 XML Schema 표준에 의하여 정의한다.

4.4 다수 공급자간의 Use Case Diagram

5. KECIS는 구현되어 있는가?

5.1 오픈소스로 공개되어 있음.

https://sourceforge.net/projects/kecis/

5.2 KECI Public Server

- java daemon

- 공인인증 Public Key만을 Handling

- XML Request Message에 대한 공인인증 공개키 암호화

- XML Response Message에 대한 공인 전자서명 검증

- Public Key에 대한 CRL checking

5.3 KECI Private Server

- java daemon

- 공인인증 Public & Private Key pair handling

- 공인인증 Private Key의 HSM 보관을 위한 Interface

- KECI Public Server의 모든 기능 포함

- XML Encryption / Decryption

- XML Signature / Verification

5.4 client Libraries

- JSP로 구현

- KECI Public Server와 TCP/IP Socket 통신

- K-ECML XML Message 생성 / 파싱

- DOM Communication을 위한 javascript library 포함

6. KECIS구조하의 상호연동 시나리오

6.1 2곳의 서비스 제공자간 상호연동 시나리오

6.1.1 상점과 결제대행사

머천트

머천트는 고객이 상품선택을 완료하면
K-ECML format의 XML Message 생성
KECI Public Server를 통해 결제대행사의 공인인증서로 요청정보 암호화
유저 브라우저를 통해 해당 요청정보를 결제대행사로 전송

결제대행사

결제대행사에서는 요청정보를 공인인증서의 개인키로 복호화
고유한 프로세스로 결제처리
결제결과를 KECI Private Server를 이용하여 전자서명
서명된 메세지를 유저 브라우저를 이용하여 전송

머천트

결제대행사에서 유저브라우저를 거처 전송해온 정보 수신
KECI Public Server를 이용하여 서명 검증
결제가 완료된것을 확인한 머천트는 유저에게 상품 제공

6.1.2 상점과 은행

상점

고객이 상점의 상품 선택
KECI client library를 이용하여 K-ECML XML Message 생성
생성된 K-ECML Message를 KECI Public Server로 암호화
암호화된 "요청" 메세지를 은행으로 전송

은행

유저 브라우저를 거쳐 암호화된 메세지 수신
KECI Private Server를 통해 해당 메세지 복호화
은행 웹사이트내에서 계좌이체 진행
계좌이체 결과를 KECI Private Server로 전자서명
서명된 메세지를 유저 브라우저를 통해 상점으로 전송

상점

은행에서 유저 브라우저를 거쳐 전송되어온 서명된 메세지 수신
KECI Public Server통해 공인 전자서명 검증
계좌이체가 완료된것을 확인후 유저에게 상품 제공

6.2 n개의 서비스 제공자간

6.2.1 상점, 은행, 공인인증기관

상점

고객이 상품 선택
KECI Public Server로 요청정보 암호화
유저브라우저 통해 은행으로 계좌이체 요청 전송

은행

암호화 메세지 수신
KECI Private Server통해 정보 복호화
계좌이체 시작
본인확인을 위해 본인확인 요청 정보 KECI Public Server통해 암호화
공인인증기관으로 전송

공인인증기관

본인확인 요청 접수
공인인증기관 웹사이트에서 유저와 본인확인 진행
본인확인결과를 KECI Private Server로 전자서명
은행으로 본인확인 결과 전달

은행

전자서명된 본인확인 정보 수신
계좌이체 처리
계좌이체 처리완료 정보를 KECI Private Server로 전자서명
유저브라우저를 통해 상점으로 이체결과 전송

상점

계좌이체 결과 수신
KECI Public Server로 서명검증
유저에게 상품제공

6.2.2 n개의 서비스 제공자들

암호화된 요청정보 수신
KECI Private Server로 데이터 복호화
서비스 제공자의 고유한 서비스 제공
서비스 제공 결과를 KECI Private Server통해 전자서명
전자서명된 결과를 원 요청자에게 응답

7. References

8. 작성자

이동산 (Mountie Lee)

mountie@paygate.net

전자정부 세션보안 ActiveX

2009-11-02T08:54:00.000-08:00

전자정부 사이트(www.g4c.go.kr)에 처음 접속하면
접속하자 마자 무슨 ActiveX를 설치하라고 나온다.
세션보안을 위한 XecureWeb을 설치하다는것인데
..

유저가 단순히 사이트 조회만을 위해 방문하든
민원을 신청하기 위해 방문하든 상관하지 않고 무조건 설치를 요구한다.

세션보안을 위한 것이라면 "정보통신망 이용촉진 및 정보보호 등에 관한 법률"및 그 하위 규정을 보면 분명하게
SSL과 응용프로그램방식 2가지를 모두 인정하고 있다.

당연하게 SSL 보안웹서버를 구성해야하는것이 아닌가?
웹 접근성을 적극 추진하고 있는 전자정부 사이트인데
아직도 응용프로그램 방식 보안웹서버를 구성하고 있다는것이

이해가 안된다.

XecureWeb이 다목적 프로그램인것은 알고 있다.
단순히 세션보안만을 위한것이 아니고 나중에 민원신청시에 다양한 기능이 동작한다.

그러나 그건 그 업무를 할 유저에게만 제시하는것이 적당하지

사이트 처음 접속하는 불특정 다수의 유저에게 무조건 설치를 강요하는것은 바람직하지 않다.

그 업무를 할 유저에게만 어떻게 제시할 수 있을까?

기술적으로는 아래와 같은과정으로 처리할 수 있다.

1. 페이지내에 < id="'xecureuse'"> < / div > tag를 하나 준비한다.
이 div tag내에는 아직 아무런 내용이 없다.

2. 만일 유저가 민원 신청을 위하여 xecureweb이 필요하다면
javascript으로 DOM element을 하나 생성한다.
그 과정은

var xecureobject = '';
document.getElementById('xecureuse').innerHTML = xecureobject;

이렇게 하면 다이나믹하게 object tag가 page내에 생성된다.
물론 단순하게 object tag만 넣기보다 실제 서비스를 위해서는 좀더 복잡한 콘트롤이 필요하다.

그렇지만 서비스 제공자가 좀더 복잡하게 콘트를하여 유저가 좀더 편리함을 느낀다면
그게 더 낳은 방식이다.

위의 개념은 activex control이 꼭 필요하더라도
무작정 불특정 다수의 유저에게 강요하기 보다
위와같은 dynamic object creation등을 통하면 기술적으로 해법이 존재하며
서비스 제공자가 무관심해서 안하는것이다.

정리하면

* 일단 세션보안은 무조건 SSL : 이것만 해도 웹 접근성이 엄청나게 증가된다.(사이트 방문하는 수많은 readonly user 지원)
* ActiveX control이 필요하다면 필요할때만 DOM element를 생성해서 사용

이정도만 해서 엄청난 웹 접근성 향상이 기대된다.

전자정부 사이트뿐만 아니라 다른 사이트도 마찬가지.

아이폰으로 첫번째 업로드

2009-10-18T16:55:00.001-07:00

아이튠즈하나에
아이폰 아이팟터치 애플티비 맥 피시등 단말제품을 통합하는 정책이 재미있다.
사용자는 자신의 콘텐츠를 어느 서비스에 통합할건지 선택의 기로에 서 있다

컨텐츠통합을 애플서비스로할건지, 구글로 할건지, 마이크로소프트 서비스로할건지, 야후로 할건지 등등

- Posted using BlogPress from my iPhone

New Payment & Identity Infrastructure

2009-04-06T17:58:00.001-07:00

분산환경에서의 결제 및 인증 구조

Decentralized Payment & Identity Structure

1. 목적

- 분산환경하의 결제서비스 공급자(Payment Service Provider)를 포함한 다수의 공급자들(Providers)이 자유롭게 결제및 인증 구조에 참여할 수 있는 표준화된 데이터 송수신 구조 확립

2. 데모

- iPhone Payment Demo : http://www.youtube.com/watch?v=HgUkpHiHH2w
- LG OZ Phone : http://www.youtube.com/watch?v=aPFSvEVEnLw

특정 Payment Provider를 통한 Payment Demo임.

이미 모바일 Full browsing단말 등 웹표준 환경에서 결제가 가능함을 보여주는 동영상

3. 웹표준 환경에서의 결제 동작구조

3.1 기존의 IE 의존 구조

3.2 웹표준 환경에서의 동작구조

3.3 전통적 방식의 HTML Presentation

* Server에서 HTML Page를 완성하여 Client로 전송하면 Client에서는 그대로 보여줌.

3.4 JSON Response에서의 HTML Presentation

* Server에서는 데이터만을 JSON format으로 변경하여 Client로 전송

* Client에서는 데이터를 재가공하여 화면 표시

* 서버는 경량의 데이터만을 Handling

3.5 DOM Request - JSON Response 구조

4 법적이슈

4.1 전자금융거래법 시행세칙 29조 2항 3호

"이용자 PC에서의 정보유출을 방지하기 위해 이용자의 접속시 우선적으로 이용자 PC에 개인용 침입탐지시스템, 키보드해킹방지 프로그램 등의 보안프로그램을 설치할 것 (다만, 고객의 책임으로 본인이 동의하는 경우에는 보안프로그램 해제가능)"

==> 이용자의 선택권 명시

==> 금감원의 공식답변 "이용자 선택권 부여여부를 전자금융업자가 결정할 수 있다" 임.

==> 페이게이트는 전자금융거래법상의 전자금융업자

==> 페이게이트는 개인보안프로그램 이용에 대한 이용자 선택권을 활성화함.

* 이용자는 전자금융업자가 제공하는 개인보안 프로그램들을 그대로 이용하거나

* 본인이 별도 유료 구매한 개인보안 프로그램을 이용하고 전자금융업자가 제공하는 프로그램을 이용하지 않을 수 있음.

4.2 키보드 보안

- 스크린 키보드 방식으로 키보드 보안을 이용자에게 제공

- 이용자는 키보드 보안방식을 이용할지 여부를 결정

4.3 공인인증서

- 전자금융거래법 시행세칙 제31조의 공인인증 사용예외 규정에 부합되는 경우 공인인증서 미사용.

4.4 공인인증서 미사용시 거래안정성 확보방안

- 신용카드 금액인증 + 프로파일 DB

5. 공급자 (Provider)

5.1 분산환경에서의 다양한 공급자들

- 쇼핑몰 서비스 공급자

- 신용카드 결제서비스 공급자

- 휴대폰 결제서비스 공급자

- 계좌이체 결제서비스 공급자

- 공인인증 인증서비스 공급자

- i-PIN 인증서비스 공급자

- OpenID 인증 서비스 공급자

- 배송서비스 공급자

- 문자발송서비스 공급자

5.2 이용자와 공급자

- 유저가 쇼핑몰(Shopping Service Provider)에 접근하는 경우

- 공급자는 유저에 대항 웹표준 UI만을 신경쓰면 됨.

- 공급자는 자신과 전용으로 연결되어 있는 각각의 서비스 제공자와 별도 연결.

==> 각 공급자간의 표준 데이터 송수신 방법 부재

5.3 이용자와 다수의 공급자

- 각 공급자가 이용자와 직접 통신이 필요한 경우들이 다수 존재함.
- 결제서비스 제공자는 주요 결제정보(카드번호 등)를 이용자로부터 직접 받아야함.
- 인증서비스 제공자는 주요 인증정보(주민번호 등)을 이용자로부터 직접 받아야함.
- 공급자간에 상호 교류가 필요한 경우가 아주 많음.

==> 공급자간의 데이터는 XML 메세지 표준을 이용

5.4 다수 공급자간의 Use Case Diagram

5.5 기준이 되는 표준 기술들

5.5.1 DOM

- W3C 표준
- DOM Request는 Google AdSense, Yahoo API등 광범위하게 사용되는 비동기 통신 방법임.

5.5.2 XML Messaging

- XML Schema, XML Signature, XML Encryption으로 W3C 권고사항.
- Application Layer에서 데이터 암복호화에 대한 구조적 접근 가능하게 함.
- 다수의 XML 암호화 관련 제품들이 소개되고 있음.
- Luna XML : XML Messaging 처리 HSM
- OpenOCES : XML Messaging 처리 서버 및 클라이언트 오픈소스 프로젝트
- OpenSigner : XML Messaging처리하는 자바 및 공인인증서 기반 오픈소스 프로젝트

5.5.3 JSON

- XML data와 상호 변환 호환성 제공
- www.json.org

5.5.4 SAML

- Security Assertion Markup Language
- http://en.wikipedia.org/wiki/SAML
- http://blog.sdnkorea.com/blog/501 : SAML을 이용한 SSO 구현

삼성생명 보험계약종합안내

2008-12-25T20:33:00.001-08:00

아래 내용으로 삼성생명에 메일을 보냈더니

담당자가 직접 수정한 메일을 보냈습니다.

그리고 앞으로 될때까지 직접 챙기겠다고 합니다.

담당자 메일을 웹사이트 접속이 불가하여

인터넷 검색엔진에서 이용자 약관내용을 찾았고 그 안의 담당자 메일이 있어 거길로 발송하였습니다.

-----------

삼성생명 보험계약종합안내 메일 오류 관련 개선 요청

안녕하세요.
저는 삼성생명 고객인 이*산입니다

IT산업에 종사하고 있고
주로 Mac OSX에서 Firefox browser를 사용합니다.

최근 삼성생명에서 발송하는 보험계약종합안내 메일에서
파이어폭스나 리눅스 유저를 고려하여 일반메일 재발행 신청하기라는 기능이 추가되었는데

아래와 같은 문제가 있어서 자세하게 안내해드립니다.

기왕 파이어폭스나 리눅스, 매킨토시 유저를 지원하기로 하였으면
그 유저입장에서 정확하게 동작하는지 확인후 안내하고 실제로 동작할 수 있도록 조치해주십시오.

1. 아래 그림처럼 삼성생명에서 메일을 받았습니다.

2. 저는 Mac OSX에서 파이어폭스를 주로 사용하고 있는데
메일 내용중 "보안프로그램(Active-X)은 일부 운영체계(윈도우비스타, 파이어폭스, 리눅스, 매킨토시 등) 및 일부 회사 메일의 경우 첨부파일이 개봉되지 않을 수 있으니 아래 [일반메일 재발행 신청하기]에서 일반메일을 신청하시기 바랍니다"라고 하는 안내문구가 보여서 [일반메일 재발행 신청하기] 링크를 클릭하였습니다.
몇단계 확인 alert 창이 뜬 이후 일반메일 신청 화면이 아래 그림처럼 나옵니다.

3. 주민번호 뒤번호 7자리를 입력하면 아무런 반응이 없습니다.
혹시나해서 Firefox의 JavaScript 오류 정보 창을 열어보니 아래와 같은 사이트 오류가 확인되었습니다.

4. 혹시나 해서 [에러 발생시 신청방법] 링크를 클릭하면 아래 그림처럼 ActiveX 설치를 시도하고 다음 단계로 진행을 할 수 없습니다.

PCI DSS Guide관련 블로그 오픈

2008-12-18T00:32:00.000-08:00

PCI DSS 안내하는 블로그를 오픈하였습니다.
http://pcidssguide.blogspot.com

살펴보세요

웹표준과 지불결제

2008-12-18T00:19:00.001-08:00

웹표준과 지불결제

1. 웹표준

1.1 전세계 브라우저 점유율 (by NetApplications)

* MSIE점유율은 줄어들고 있고 Firefox는 상승중

1.2 대한민국 브라우저 점유율 종합 (by NetApplications)

* 국내 MSIE점유율 종합은 96.59%(4월), 95.65%(5월)

1.3 지불결제가 필요한 쇼핑분야 점유율(by internettrend)

* 쇼핑분야는 국가평균보다 점유율이 더 높음

* 기간별 변화율 추이는 점차 줄어들고 있음.

1.4 국가별 MSIE Market Share 비율 (by NetApplications)

* 오차율을 감안한다면 "South Korea"는 세계 최고의 MSIE Market Share 비율을 보이고 있음.

1.5 페이게이트 결제를 사용하는 특정 업체의 브라우저 점유율 (by analytics.google.com)

누적5월까지

누적6월까지

1.6 웹표준 이전과 이후

웹표준 이전	웹표준 이후
유저환경에 대한 기술적 별도 대응 - IPTV환경 따로 - 모바일환경 따로 - PC환경 따로	동일한 하나의 기술로 모든 시장환경에 대응 PC, 모바일, IPTV 환경의 구분 불필요

1.7 웹표준은 돈이되는 기술

구분	웹표준 미준수업체	웹표준 준수업체
MSIE PC Market (95%)	유저의 95% 수용, but 시장이 점점 줄어들고 있음.	(좌동)
Non-MSIE PC Market (5%)	X	숨어있는 새로운 5% 유저 수용, 매출 5% 증대 가능성
Mobile Full Browsing Market (00%)	X	무한 가능성 가진 새로운 유저층 수용, 매출 증대 가능성 가늠불가
IPTV Setup Market (00%)	X	무한 가능성 가진 새로운 유저층 수용, 매출증대 가느성 가늠불가
냉장고에 붙은 embeded device	X	숨어있는 새로운 유저 수용, 매출증대 가능성
기타 웹표준 순수 device(iphone, PSP, XBox...)	X	숨어있는 새오운 유저 수용, 매출증대 가능성

1.8 Mobile Device에서 결제 demo

LGT 아르고 via OZ Service : http://kr.youtube.com/watch?v=aPFSvEVEnLw
PayGate Payment flow : http://docs.google.com/a/paygate.net/Doc?docid=dhm28v4q_1634dfbqbvdq
iPod touch 결제 : http://video.google.com/videoplay?docid=3754602460068350773
iPhone : http://kr.youtube.com/watch?v=HgUkpHiHH2w

1.9 지불결제분야의 웹표준 활성화를 위한 요건

사업적	매우 매력적
기술적	제약 없음.
제도적	공인인증서 의무사용 개인보안프로그램 의무사용 기타등등.

2. 지불결제 및 보안에 대한 이해

2.1 보안방식의 변화 필요

현재	희망사항
보안당국이 국민 개개인의 보안을 모두 책임지려는 불가능한 자세 국가가 전국민을 보호	개인의 선택권(자율성, 권한)을 존중하는 방향으로 개선 필요 국가의 보호도 필요하지만 내 PC를 내가 보호할 수 있도록 개인의 선택권 존중. 국가가 전국민을 보호 + 자신을 내가 추가로 보호

* 전자금융거래법 시행세칙 29조 2항 3절 : 전자금융업자에게 국민 개개인의 이용자 PC에 프로그램을 설치하도록 요구함. 본질적으로 이용자의 동의 및 허용이 있어야 가능한 조항

2.2 사용자에 대한 관점 변화 필요

현행	희망사항
사용자는 무지하고 피동적이고 잠재적인 범죄자이다.	사용자는 똑똑하고 능동적이고 선량하다 ==> 개인의 선택권 존중해야함

2.3 전자금융거래와 전자서명법의 공인인증서

구분	전자금융거래법	전자서명법
공인 전자서명/서명검증	요구됨	요구됨
데이터 암복호화	요구됨	요구되지 않음.

==> 데이터 암복호화와 서명 /서명검증의 명확한 분리 필요 ==> 현재는 전자금융거래시 사용되는 공인인증서가 사실상 데이터 암복호화를 포함하여 사용.

3. 전자서명법과 공인인증서

3.1 인감제도와 공인인증서 비교

구분	인감제도	공인인증서
취지	오프라인에서 국민 누구든지 자유롭게 상대방의 신원 및 의사 확인	온라인에서 국민 누구든지 자유롭게 상대방의 신원 및 의사 확인
본인의 표시	인감도장	공인인증서 Private Key
본인의 표시에 대한 제3자 증명	인감증명서	공인인증서
본인의사 표시	인감 날인	공인 전자서명
신원확인	인감증명서 대조	공인전자서명 서명검증
누구나 자유롭게	날인하고 대조	서명하고 검증 불가능
어떠한 영역에 대해서도	적용	불가능 (금융거래등에만 제한적 사용)

3.2 전자서명법상의 공인인증기관의 의무

- 전자서명 가입자 설비 제공 의무 : 전자서명 생성을 위한 소프트웨어 제공 - 서명검증을 위한 쉬운 수단 제공 의무 : 전자서명 검증을 위한 쉬운 수단 제공

3.3 공인인증기관이 가입자 설비를 제공하면 기존 보안업체들은 모두 다 망하는가?

현재	희망사항
아주 많은 업체들(공인인증기관 포함)이 기초적인 공인인증서 전자서명, 서명검증 소프트웨어 반복하여 제작 => 리소스 낭비	6개 공인인증기관이 검증된 가입자 설비 제공, 기존보안업체들은 좀더 창의적인 업무에 집중가능(데이터 암복호화, 키관리, 기타 응용 서비스 분야) 기존 보안업체뿐만 아니라 다양한 사업체들이 참여로 인한 활성화
공인전자서명/서명검증을 할 수 있는 소프트웨어를 만들기 위해서는 돈이 많거나 기술이 뛰어나거나 시간이 아주 많아야함.	구멍가게 쇼핑몰 아저씨도 이용가능

4. 웹표준 지불결제처리를 위한 기술적/제도적 대안

4.1 주요 이슈 및 대안 요약

구분	현행	대안
키보드보안	ActiveX Control 자동설치	OnScreen Keyboard
개인보안프로그램(방화벽, 안티바이러스)	ActiveX Control 자동설치	유저가 능동적으로 사전 설치, 기설치 유저는 추가설치 없이 진행허용
공인인증서	ActiveX Control 가입자설비	- 사용안함(예외규정 준용) - Java Applet (KLDP OpenSigner) - XPCOM (전자정부) - 신용카드 금액인증

4.2 키보드보안 방안

- 유저가 원하는 경우 사용하지 않고 진행가능하도록 선택권 부여해야함. (시행세칙 29조 기 명시) - Auto Form Filler 활성화 - OnScreen keyboard : 광범위하게 사용되는 검증된 방식, 국내 다수 금융기관에서 이용 - Smart Card등 PKCS#11 device이용한 보완 - 기타 : http://en.wikipedia.org/wiki/Keystroke_logging 참조 *국민은행 온스크린 키보드 보안 적용 화면

4.3 개인보안프로그램

- 유저가 원하는 경우 사용하지 않고 진행가능하도록 선택권 부여해야함. (시행세칙 29조 기 명시) - 유저가 능동적으로 사전 설치할 수 있도록 프로그램 목록 제시 * 페이게이트의 경우

4.4 공인인증서 사용예외 (시행세칙 31조)

- 본인 계좌에 대한 조회 업무 - 전화, CD/ATM 등과 같이 공인인증서의 설치·운용이 불가능한 수단을 이용한 전자금융거래 - 등록금, 원서접수비 등 본인확인이 가능하고 입금계좌가 지정되어 있는 경우 - 전자상거래에서 지급결제로서 30만원 미만의 신용카드 결제 또는 온라인 계좌이체 - 전자화폐, 선불전자지급수단을 온라인상에서 사용하는 경우 - 금융기관 등이 범위를 정하여 공인인증서 적용을 제외할 것을 감독원장에게 요청하고 감독원장이 이를 승인하는 경우

4.5 신용카드 금액인증

- 이용자(페이게이트도 이용자임)의 자유로운 창의력을 저해하지 않았을때 도출될 수 있는 결과물의 한 예.
- 시행세칙 31조의 "본인 계좌에 대한 조회업무"에 대한 공인인증서 적용예외 규정을 기반으로 공인인증서를 사용하지 않음.
- 공인인증서 미사용시 발생할 수 있는 신원확인 요구사항을 "신용카드 금액인증"이라는 기술로 보완

[신용카드 금액인증 50만원 결제예시] 1) 서버에서 1회용 비밀번호 생성로직으로 난수 발생하여 신용카드 거래 1차승인 (237698원) 2) 승인금액을 고객에게 안내하지는 않음. 3) 고객은 자신의 카드발행사에서 승인금액이 얼마인지 확인 (다양한 확인방식 병행, SMS문자, 웹사이트조회, 팩스조회, 전화조회, 방문조회 등) 4) 승인금액을 인증코드로 입력하면 서버에서 1차 승인금액과 비교 5) 나머지 잔액 추가승인하여 결제 완료

신용카드 금액인증에 관한 보다 자세한 내용은 아래 URL 참조 http://docs.google.com/a/paygate.net/Doc?id=dhm28v4q_1631cd5kj9dk

4.6 ActiveX Control이용방식 개선

- ActiveX Control 사용이 꼭 필요한 경우가 여전히 존재함

- 꼭 ActiveX를 사용해야한다면 아래와 같이 사용방식을 개선

현행	개선
- Page Head에 걸어버리거나 <html> <head> <OBJECT ....>...</OBJECT> </head> - 사이트 전역에 반영되는 Hidden frame에 넣어버리면 IE가 아닌 브라우저들은 접근자체가 불가해짐.	- ActiveX가 꼭 필요할때만 DIV tag 안에서 선언하여 이용. <div id=forActiveX></div> document.getElementById('forActiveX').innerHTML = '<OBJECT...>...</OBJECT>'; - 이용후에는 Div tag내용 삭제 document.getElementById('forActiveX').innerHTML = '';
ActiveX를 이용하여 Client와 Server간의 세션 보호	SSL이용

Latest Browser MarketShare

2008-12-17T18:36:00.001-08:00

CreditCard Amount Authentication

신용카드 금액인증.

1. Basic Concept

Credit Card Amount Authentication authenticates card holder with the approval amount.
The AA(Amount Authentication) server generate random unique amount (AA code) and get the approval with it.
The card holder have to find the approved amount from his card issuer
If the amount (submitted from card holder) is same to AA code, the authentiation is completed.

2. Basic Concept Flow

2.1 Basic Concept Flow2

3. Benefit

It’s Easy and Strong

It is very easy to understand and implement
But it’s also strong

Issuer independent

AA mechanism covers 100% card issuers
even if they are not yet ready.

Platform independent

With the minimal authentication value (Amount)
AA works on any platforms (PC, Mac, Wireless Phone, etc)

Fraud free

AA mechanism is strong enough to down fraud rate to 0%

4. General Information about AA

AA operator have to meet the PCIDSS compliant
Initiated from PayGate Inc.

PayGate Inc., Seoul, Korea
www.paygate.net

If any questions, send mail to Mountie Lee (mountie@paygate.net)

2008-01-30T07:50:00.000-08:00

Cross-Domain 문제 해결 방법

by 이동산 — 최종 수정일: 2006-04-25 10:53

Cross-Domain 문제 해결방법에 대한 조사결과

AJAX를 살펴보면서 Cross-Domain 제한의 문제점에 봉착함.

Cross-Domain의 Pattern은 아래 3가지로 나눠볼 수 있음.

1. from one single domain to many targets

2. from many sources to one single target

3. from many sources to many targets.

지금 고민하는것은 2번항목임.

[지금까지 찾은 해결방법]

(1) Proxy Server 이용 : 최초 시도한 방법인데 이건 사실상 위 1번 항목에 해당하는것으로 적당하지 않고 또한 cookie나 session문제등이 있어서 몇번 사용해보다고 취소함.

(2) SignedJavaScript : Netscape계열에서만 되며 JavaScript에 대한 전자서명시 서명된 javascript는 cross-domain 제약을 극복하여 자유롭게 다른 사이트와 통신가능함. MSIE에서는 동작하지 않는다는 문제점이 있고 아직 테스트해보지 못함.

(3) Flash4AJAX : 지금까지 찾은 최상의 방법인데 ActiveX/Plugin을 사용하기는 하지만 광범위하게 배포된 Flash를 이용하여 구현함으로 Cross-Browser문제는 쉽게 극복가능함. 그러나 Flash에 대해서 잘 모르기 때문에 좀더 살펴보고 있음.

(4) JSON + WebServices : 야후 API에서 사용하고 있는데 Target서버에서 JSON Format으로 Output을 뿌려줘야하는 문제 있음. 아직 테스트 못함.

(5) ActiveX : 어떻게 보면 가장 손쉬운 방법인데 일단 하나 만들어 사용중이기는 하지만 Cross-Browser 문제해결에는 적절치 못함.

(6) Windows TrustedZone 등록 : Source Domain상의 유저가 해당 Source Domain을 Windows TrustedZone에 등록해버리면 어디든 나갈 수 있는데 사실 말이 안됨. 보안상 엄청 위험하기도함.

(7) IFrame 이용 : iframe이용하면 일단 AJAX Cross-Domain 문제는 해결되지만 frame간의 cross-domain 문제가 새롭게 대두됨. cross-domain cookie등 Security issue가 꾸준하게 제기되어온 사항임. 일단 target server로 Get Method로 데이터를 넘기기만 하는 형태로는 쓸만함. (결과수신은 아주 어려움)

[ 최종 선택한 방법 : JSON ]

JSON Format으로 결과 전달하고 Callback method로 해당 결과 수신하는 방법이 정답임.

우선 단점 : Request시 GET Method에 해당하는 정보만 전달가능하므로 정보전달 양이 한계가 있음. 그리고 미동기 통신이 안되는 문제점 있음.

그리고 장점 : 대용량 Response를 받을 수 있음. 사실상 브라우저 및 네트웍 성능에 달려 있음. 아무런 ActiveX나 Plugin이 필요치 않음. Cross-Browser 사실상 지원. JavaScript Tag가 먹히는지 여부 실제 확인 필요

(Concept)

1) Client에서 JSon Request URL 생성

2) Javascript createElement tag로 script 객체 생성

3) DOM에 해당 객체 추가하여 실제 반영. 객체추가시 즉각 Remote Server의 CGI/JSP/PHP 호출

4) Remote Server에서는 Request에 따른 업무 처리 후 결과를 callback method로 둘러싼 JSON Format으로 생성하여 화면 송출

5) Browser에서는 결과가 실제로는 script tag 내에 위치하면서 callback method를 호출한것과 동일한 효과발생.

6) callback method내에서 필요한 client측의 업무 처리.

JSON은 AJAX 통신은 아님 사실상 Dynamic Script Creation에 해당되며 script creation시 Remote Server의 script를 불러오는 형태임.

실제 업무에서 JSON과 AJAX를 적절히 섞어 쓸 필요 있음.

2008-01-30T07:43:00.000-08:00

SAML을 이용한 SSO Service의 구현

이동산, Mountie Lee
mountie@paygate.net

1. 개요

SAML은 웹 브라우저에서의 SSO문제를 해결하기 위해서 OASIS의 연구결과로 탄생하였다.

인트라넷 레벨에서의 SSO는 다양한 방식들이 이용되어왔고 구현에 있어서도 크게 문제될요소는 적다.

예를 들어 Cookie 기반의 SSO, LDAP기반의 SSO, 인증서 기반의 SSO등이 있다.

그러나 도메인간의 SSO 구현을 위한 방식은 통제할 수 없는 외부 환경을 포함하므로 통일된 하나의 표준방식이 필요하게 되었고

SAML은 이러한 도메인간의 SSO구현을 가능하게하는 XML 표준이다.

사용되는 용어에 대해서 알아보자.

SAML : Security Asserting Markup Language, http://en.wikipedia.org/wiki/SAML 참조

SSO : Single Sign On 하나의 일관된 인증방식으로 여러 서비스에 로그온할 수 있는 방법

ACS : Assertion Consumer Service, Identity Provider에 의하여 인증된 사용자에 대한 정보가 담긴 SAML response정보를 verify 하고 서비스를 제공할 수 있도록 포워딩 한다

SAML에는 3가지 중요한 구성원이 존재한다.

Service Provider : 서비스를 제공하는 주체

유저 : 서비스를 이용하는 사용자

Identify Provider : 유저에 대한 인증을 담당하는 주체

SAML의 특징은 Cross domain상황에서 표준화된 방식으로 SSO를 구현할 수 있으면서
Platform에 관계없이 다양한 환경에서 표준적인 방법으로 SSO 구현이 가능하다는 것이다.
실제 다양한 iPhone등 다양한 플랫폼에서 테스트해본 결과 잘 동작한다.

2. SAML Basic Steps

아래 그림은 Wikipedia에서 제시한 흐름도이다.

Google에서도 아래 그림을 제시하고 있다.

각 단계별 과정을 설명하면 아래와 같다.

1단계 : 유저는 서비스 제공자(Service Provider)에게 접근한다. (서비스 이용을 위하여)

2단계 : 서비스 제공자는 SAMLRequest를 생성한다. 생성된 SAMLRequest은 XML format의 텍스트로 구성된다.

3단계 : 유저의 브라우저를 이용하여 인증 제공자(Identity Provider)로 Redirect 한다.

4단계 : 인증 제공자(Identity Provider)는 SAMLRequest를 파싱하고 유저인증을 진행한다.

5단계 : 인증제공자(Identity Provider)는 SAML Response를 생성한다.

6단계 : 인증제공자(Identity Provider)는 유저 브라우저를 이용하여 SAMLResponse data를 ACS로 전달한다.

7단계 : ACS는 Service Provider가 운영하게 되는데 SAMLResponse를 확인하고 실제 서비스 사이트로 유저를 Forwarding한다.

8단계 : 유저는 로그인에 성공하고 서비스를 제공받는다.

위 단계중 SAMLResponse가 중요한 역할을 하는데 Identity Provider로서 SAMLResponse에 대하여 전자서명하고 ACS가 전자서명을 검증하여 유효한 Response인지를 확신할 수 있게 된다.

Identity Provider는 자체적인 다양한 방식으로 유저인증을 진행할 수 있으며 서비스 제공자는 Identity Provider를 신뢰하여 인증의 전권을 Identity Provider에 의존하게 되어 Identity Provider의 신뢰 및 책임부분이 중요한 요소이다.

3. SAML SSO 실제 구현

SAML SSO를 실제 구현해가면서 어떻게 동작하는지 살펴보자.

3.1 사전 준비

구현은 Service Provider로서의 단계와 Identity Provider로서의 단계를 모두 포함하여 Full Cycle을 순환할 수 있도록 하지만

실제로는 대부분 Service Provider나 Identity Provider의 역할중 어느 한 역할을 주로 하게 될것이다.

필요한 핵심 Library는 아래와 같다.

OpenSAML 2.0 Library

download from http://www.opensaml.org
OpenSAML 2.0은 JDK1.5에서 동작

xmldsig, xmlsec library,

from sun java web services development pack,
http://java.sun.com/webservices/downloads/previous/webservicespack.jsp

JDOM library

http://www.jdom.org

기타 apache commons의 유용한 Library들을 필요에 맞게 사용한다.

RSA Keypair를 준비한다.

openssl을 이용한 keypair 생성 command

$ openssl genrsa -out sso_private.pem 1024
$ openssl rsa -in sso_private.pem -pubout -ourform DER -out sso_public.der
$ openssl pkcs8 -topk8 -inform PEM -outform DER -in sso_private.pem -out sso_private.der -nocrypt

생성된 2개의 파일은 sso_private.der, sso_public.der이다.

한가지 주의할점은 sso_public.der은 우리가 통상적으로 알고 있는 인증서(certificate)가 아니다.
certifificate는 인증기관으로부터 public key의 유효성을 인정받은 경우에 인증기관의 전자서명이 첨부되어 발행되는데
여기서는 original rsa public key만으로 SSO를 구현한다.

대신 신뢰성을 확보하기 위하여 identity provider의 public key는 신뢰성 있는 방식으로 service provider에게 전달되어야하며
이 전달과정이나 identity provider의 private key 관리에는 주의를 기울여야한다.

SAML에서 이용하는 xmldsig spec이나 구현 사례를 봐도 인증서를 탑재하여 SAML SSO를 분명히 진행할 수 있다.
이 경우에는 identity provider의 public key를 특별한 방법으로 전달할 필요 없이
service provider는 신뢰할 수 있는 CA(Certificate Authority)가 보장하는 전자인증서를 확보하고 인증서 CRL 또는 OCSP checking등을 추가할 수 있을것이다.

3.2 SAMLRequest 생성 및 redirect

이 단계에서는 유저가 서비스 제공자의 사이트에 접속하고 SAML SSO 로그인을 진행하기 위해 SAMLRequest 생성 및 redirect의 과정을 설명한다.

3.2.1 ServiceProviderForm : 실제 유저가 최초로 접근하는 페이지이다. 여기서부터 시작

</form>

* loginForm : Identity Provider에 위치하는 인증을 위한 로그인 폼

* providerName : 서비스를 제공하는 Service Provider Name

* RelayState : ACS에서 인증을 마친후 최종적으로 Redirecting하게 되는 서비스 제공 페이지 URL

* acsURI : Identity Provider가 보낸 SAMLResponse를 검증(Verify)하고 실제 서비스 제공사이트로 Forwarding하게 되는 URL

3.2.2 CreateRequestServlet : SAMLRequst 데이터 생성 단계

먼저 Parameter를 받고

String ssoURL = request.getParameter("loginForm");
String providerName = request.getParameter("providerName");
String RelayState = request.getParameter("RelayState");
String acsURI = request.getParameter("acsURI");

public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String ssoURL = request.getParameter("loginForm");
String providerName = request.getParameter("providerName");
String RelayState = request.getParameter("RelayState");
String acsURI = request.getParameter("acsURI");
.....
}

SAMLRequest xml data를 생성

String SAMLRequest = createAuthnRequest(acsURI, providerName);

private String createAuthnRequest(String acsURL, String providerName)
throws SamlException {
String filepath = getServletContext().getRealPath("t/sso/saml/templates/" + SAML_REQUEST_TEMPLATE);
String authnRequest = Util.readFileContents(filepath);
authnRequest = StringUtils.replace(authnRequest, "##PROVIDER_NAME##", providerName);
authnRequest = StringUtils.replace(authnRequest, "##ACS_URL##", acsURL);
authnRequest = StringUtils.replace(authnRequest, "##AUTHN_ID##", Util.createID());
authnRequest = StringUtils.replace(authnRequest, "##ISSUE_INSTANT##", Util.getDateAndTime());
return authnRequest;
}

Identity Provider로 redirect할 URL생성

String redirectURL = computeURL(ssoURL, SAMLRequest, RelayState);

private String computeURL(String ssoURL, String authnRequest,
String RelayState) throws SamlException {
StringBuffer buf = new StringBuffer();
try {
buf.append(ssoURL);

buf.append("?SAMLRequest=");
buf.append(RequestUtil.encodeMessage(authnRequest));

buf.append("&RelayState=");
buf.append(URLEncoder.encode(RelayState));
return buf.toString();
} catch (UnsupportedEncodingException e) {
throw new SamlException(
"Error encoding SAML Request into URL: Check encoding scheme - "
+ e.getMessage());
} catch (IOException e) {
throw new SamlException(
"Error encoding SAML Request into URL: Check encoding scheme - "
+ e.getMessage());
}
}

CreateRequestServlet.java 구현 종합

/*
* CreateRequestServlet
*/
public class CreateRequestServlet extends HttpServlet {

private static final String SAML_REQUEST_TEMPLATE = "AuthnRequestTemplate.xml";

public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {

String returnPage = "service_proc.jsp"; // 실제 forwarding수행할 JSP
response.setHeader("Content-Type", "text/html; charset=UTF-8");
response.setContentType("text/html; charset=UTF-8");

// get PARAMETERS
String ssoURL = request.getParameter("loginForm");
String providerName = request.getParameter("providerName");
String RelayState = request.getParameter("RelayState");
String acsURI = request.getParameter("acsURI");

String SAMLRequest;
String redirectURL;

try {
// create SAMLRequest
SAMLRequest = createAuthnRequest(acsURI, providerName);
request.setAttribute("authnRequest", SAMLRequest);

// compute URL to forward AuthnRequest to the Identity Provider
redirectURL = computeURL(ssoURL, SAMLRequest, RelayState);
request.setAttribute("redirectURL", redirectURL);

} catch (SamlException e) {
request.setAttribute("error", e.getMessage());
}

request.getRequestDispatcher(returnPage).include(request, response);
}
}

AuthnRequestTemplate.xml 참조

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="##AUTHN_ID##"
Version="2.0"
IssueInstant="##ISSUE_INSTANT##"
ProtocolBinding="urn:oasis:names.tc:SAML:2.0:bindings:HTTP-Redirect"
ProviderName="##PROVIDER_NAME##"
AssertionConsumerServiceURL="##ACS_URL##"/>

3.2.3 service_proc.jsp : Identity Provider로 SAMLRequest를 forward

<%@page import="net.paygate.saml.util.RequestUtil"%>
<%@page import="java.net.*"%>
<%
String error = (String) request.getAttribute("error");
String authnRequest = (String) request.getAttribute("authnRequest");
String redirectURL = (String) request.getAttribute("redirectURL");
%>
<html><head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"><title>SAML-based Single Sign-On Service </title></head>
<%
if (error != null) {
%>
<body><center><font color="red"><b><%= error %></b></font></center><p>
<%
} else {
if (authnRequest != null && redirectURL != null) {
%>
<body onload="document.location = '<%=redirectURL%>';return true;">
<h1 style="margin-bottom:6px">Submitting login request to Identity provider</h1>
<%
} else {
%>
<body>
<center><font color="red"><b>no SAMLRequest or redirectURL</b></font></center><p>
<%
}
}
%>
</body></html>

3.3 SAMLRequest를 받고 유저인증 진행 단계

이 단계는 Identity Provider에서 진행하게 된다.
유저인증은 각 Identity Provider별로 다양한 방법을 취할 수 있고 여기서는 LDAP 인증을 사용하고 있다.

3.3.1 login_form.jsp : 기본적인 유저 인증 정보를 입력받는다.

Parameter를 받고

String SAMLRequest = request.getParameter("SAMLRequest");
String RelayState = request.getParameter("RelayState");

SAMLRequest를 Parsing한다.

String requestXmlString = ProcessResponseServlet.decodeAuthnRequestXML(SAMLRequest);
String[] samlRequestAttributes = ProcessResponseServlet.getRequestAttributes(requestXmlString);

사용자 이름과 비밀번호를 입력받고

IdentityProviderForm을 생성한다.

login_form.jsp 구현 종합

<%
String SAMLRequest = request.getParameter("SAMLRequest");
String RelayState = request.getParameter("RelayState");
String ServiceProvider = "";
if (SAMLRequest == null || SAMLRequest.equals("null")) {
ServiceProvider = "";
} else {
String requestXmlString = ProcessResponseServlet.decodeAuthnRequestXML(SAMLRequest);
String[] samlRequestAttributes = ProcessResponseServlet.getRequestAttributes(requestXmlString);
String issueInstant = samlRequestAttributes[0];
ServiceProvider = samlRequestAttributes[1];
String acsURL = samlRequestAttributes[2];
}
%>

<html><head><title>SSO Login Page</title></head>
<body>
<h1><%=ServiceProvider%> Service Login</h1>
<form name="IdentityProviderForm" action="https://api.paygate.net/t/sso/saml/ProcessResponseServlet.jsp" method="post">
<input type="hidden" name="SAMLRequest" value="<%=SAMLRequest%>"/>
<input type="hidden" name="RelayState" value="<%=RelayState%>"/>
<input type="hidden" name="returnPage" value="./login_proc.jsp">
username : <input type="text" name="username" id="username" size="18">
<br>
password : <input type="password" name="password" id="password" size="18">
<br>
<input type="submit" value="로그인">
</form>
</body></html>

3.4 유저 확인후 SAMLResponse 생성

3.4.1 ProcessResponseServlet

login_form.jsp에서 parameter를 받는다.

String SAMLRequest = request.getParameter("SAMLRequest");
String returnPage = request.getParameter("returnPage");
String username = request.getParameter("username");
String password = request.getParameter("password");
String RelayState = request.getParameter("RelayState");

public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String SAMLRequest = request.getParameter("SAMLRequest");
String returnPage = request.getParameter("returnPage");
String username = request.getParameter("username");
String password = request.getParameter("password");
String RelayState = request.getParameter("RelayState");
...
}

SAMLRequest를 parsing한다.

String requestXmlString = decodeAuthnRequestXML(SAMLRequest);

public static String decodeAuthnRequestXML(String encodedRequestXmlString) throws SamlException {
try {
Base64 base64Decoder = new Base64();
byte[] xmlBytes = encodedRequestXmlString.getBytes("UTF-8");
byte[] base64DecodedByteArray = base64Decoder.decode(xmlBytes);
try {

Inflater inflater = new Inflater(true);
inflater.setInput(base64DecodedByteArray);
byte[] xmlMessageBytes = new byte[5000];
int resultLength = inflater.inflate(xmlMessageBytes);

if (!inflater.finished()) {
throw new RuntimeException("didn't allocate enough space to hold decompressed data");
}

inflater.end();
return new String(xmlMessageBytes, 0, resultLength, "UTF-8");

} catch (DataFormatException e) {

ByteArrayInputStream bais = new ByteArrayInputStream(base64DecodedByteArray);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
InflaterInputStream iis = new InflaterInputStream(bais);
byte[] buf = new byte[1024];
int count = iis.read(buf);
while (count != -1) {
baos.write(buf, 0, count);
count = iis.read(buf);
}
iis.close();

return new String(baos.toByteArray());
}

} catch (UnsupportedEncodingException e) {
throw new SamlException("Error decoding AuthnRequest: Check decoding scheme - " + e.getMessage());
} catch (IOException e) {
throw new SamlException("Error decoding AuthnRequest: Check decoding scheme - " + e.getMessage());
}
}

SAMLRequest에서 Attribute을 발췌한다.

String[] samlRequestAttributes = getRequestAttributes(requestXmlString);
String issueInstant = samlRequestAttributes[0];
String providerName = samlRequestAttributes[1];
String acsURL = samlRequestAttributes[2];

public static String[] getRequestAttributes(String xmlString) throws SamlException {
Document doc = Util.createJdomDoc(xmlString);
if (doc != null) {
String[] samlRequestAttributes = new String[3];
samlRequestAttributes[0] = doc.getRootElement().getAttributeValue("IssueInstant");
samlRequestAttributes[1] = doc.getRootElement().getAttributeValue("ProviderName");
samlRequestAttributes[2] = doc.getRootElement().getAttributeValue("AssertionConsumerServiceURL");
return samlRequestAttributes;
} else {
throw new SamlException("Error parsing AuthnRequest XML: Null document");
}
}

User 인증을 진행한다.

boolean isValiduser = login(username, password);

private boolean login(String username, String password) {
LdapLoginHandler ldaplh = new LdapLoginHandler();

if (password.length() < 1) return false;
if (ldaplh.isValidOfficeUser(username, password)) {
return true;
} else {
return false;
}
}

* 실제 인증은 Identity Provider의 사정에 맞게 다양한 방식으로 진행한다.

RSA Keypair loading

String publicKeyFilePath = keysDIR + "paygate_public.der";
String privateKeyFilePath = keysDIR + "paygate_private.der";
RSAPrivateKey privateKey = (RSAPrivateKey) Util.getPrivateKey(privateKeyFilePath, "RSA");
RSAPublicKey publicKey = (RSAPublicKey) Util.getPublicKey(publicKeyFilePath, "RSA");

SAMLResponse의 유효기간정보 설정, 현시점부터 24시간 유효하게 설정함

long now = System.currentTimeMillis();
long nowafter = now + 1000*60*60*24;
long before = now - 1000*60*60*24;

SimpleDateFormat dateFormat1 = new SimpleDateFormat("yyyy-MM-dd'T'hh:mm:ss'Z'");
java.util.Date pTime = new java.util.Date(now);
String notBefore = dateFormat1.format(pTime);
java.util.Date aTime = new java.util.Date(nowafter);
String notOnOrAfter = dateFormat1.format(aTime);

request.setAttribute("notBefore", notBefore);
request.setAttribute("notOnOrAfter", notOnOrAfter);

인증을 거친 로그인 유저네임과 유효기간을 포함한 전자서명전의 SAMLResponse XML data생성

String responseXmlString = createSamlResponse(username, notBefore, notOnOrAfter);

private String createSamlResponse(
String authenticatedUser,
String notBefore,
String notOnOrAfter) throws SamlException {
String filepath = getServletContext().getRealPath("t/sso/saml/templates/" + samlResponseTemplateFile);
String samlResponse = Util.readFileContents(filepath);
samlResponse = StringUtils.replace(samlResponse, "##USERNAME_STRING##", authenticatedUser);
samlResponse = StringUtils.replace(samlResponse, "##RESPONSE_ID##", Util.createID());
samlResponse = StringUtils.replace(samlResponse, "##ISSUE_INSTANT##", Util.getDateAndTime());
samlResponse = StringUtils.replace(samlResponse, "##AUTHN_INSTANT##", Util.getDateAndTime());
samlResponse = StringUtils.replace(samlResponse, "##NOT_BEFORE##", notBefore);
samlResponse = StringUtils.replace(samlResponse, "##NOT_ON_OR_AFTER##", notOnOrAfter);
samlResponse = StringUtils.replace(samlResponse, "##ASSERTION_ID##", Util.createID());
return samlResponse;
}

* createID()는 UniqueID를 생성하는 함수임.
* getDateAndTime()은 SAML date format에 맞게 날짜시간정보를 생성하는 함수임.
* SAML date format : yyyy-MM-ddThh:mm:ssZ (예: 2008-01-30T23:05:23Z)

SAMLResponse에 대하여 전자서명

String signedSamlResponse = SAMLSigner.signXML(responseXmlString, privateKey, publicKey);
* 이때 publicKey는 SAMLResponse message에 포함되지만 데이터 암호화에는 사용되지 않는다.
* xmldsig.jar, xmlsec.jar가 필요함

서명된 SAMLResponse를 포함하여 ACS로 forwarding한다.

request.setAttribute("samlResponse", signedSamlResponse);
request.getRequestDispatcher(returnPage).include(request, response);

ProcessResponseServlet.java 구현 종합

/*
* ProcessResponseServlet
*/

public class ProcessResponseServlet extends HttpServlet {

private final String keysDIR = System.getProperty("PGV3_HOME")
+ SystemUtils.FILE_SEPARATOR + "SSO"
+ SystemUtils.FILE_SEPARATOR + "keys" + SystemUtils.FILE_SEPARATOR;

private final String samlResponseTemplateFile = "SamlResponseTemplate.xml";
private static final String domainName = "paygate.net";

public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String SAMLRequest = request.getParameter("SAMLRequest");
String returnPage = request.getParameter("returnPage");
String username = request.getParameter("username");
String password = request.getParameter("password");
String RelayState = request.getParameter("RelayState");

boolean continueLogin = true;

if (SAMLRequest == null || SAMLRequest.equals("null")) {
continueLogin = false;
request.setAttribute("error","ERROR: Unspecified SAML parameters.");
request.setAttribute("authstatus","FAIL");

} else if (returnPage != null) {
try {

String requestXmlString = decodeAuthnRequestXML(SAMLRequest);
String[] samlRequestAttributes = getRequestAttributes(requestXmlString);
String issueInstant = samlRequestAttributes[0];
String providerName = samlRequestAttributes[1];
String acsURL = samlRequestAttributes[2];

boolean isValiduser = login(username, password); // 유저인증

if (!isValiduser) {
request.setAttribute("error", "Login Failed: Invalid user.");
request.setAttribute("authstatus","FAIL");
} else {
request.setAttribute("issueInstant", issueInstant);
request.setAttribute("providerName", providerName);
request.setAttribute("acsURL", acsURL);
request.setAttribute("domainName", domainName);
request.setAttribute("username", username);
request.setAttribute("RelayState", RelayState);

String publicKeyFilePath = keysDIR + "paygate_public.der";
String privateKeyFilePath = keysDIR + "paygate_private.der";
RSAPrivateKey privateKey = (RSAPrivateKey) Util.getPrivateKey(privateKeyFilePath, "RSA");
RSAPublicKey publicKey = (RSAPublicKey) Util.getPublicKey(publicKeyFilePath, "RSA");

long now = System.currentTimeMillis();
long nowafter = now + 1000*60*60*24;
long before = now - 1000*60*60*24;

SimpleDateFormat dateFormat1 = new SimpleDateFormat("yyyy-MM-dd'T'hh:mm:ss'Z'");
java.util.Date pTime = new java.util.Date(now);
String notBefore = dateFormat1.format(pTime);

java.util.Date aTime = new java.util.Date(nowafter);
String notOnOrAfter = dateFormat1.format(aTime);

request.setAttribute("notBefore", notBefore);
request.setAttribute("notOnOrAfter", notOnOrAfter);

if (!validSamlDateFormat(issueInstant)) {
continueLogin = false;
request.setAttribute("error", "ERROR: Invalid NotBefore date specified - " + notBefore);
request.setAttribute("authstatus","FAIL");
} else if (!validSamlDateFormat(notOnOrAfter)) {
continueLogin = false;
request.setAttribute("error", "ERROR: Invalid NotOnOrAfter date specified - " + notOnOrAfter);
request.setAttribute("authstatus","FAIL");
}

if (continueLogin) {
// 서명전의 SAMLResponse Message 생성
String responseXmlString = createSamlResponse(username, notBefore, notOnOrAfter);

// SAMLResponse에 대한 전자서명
String signedSamlResponse = SAMLSigner.signXML(responseXmlString, privateKey, publicKey);
request.setAttribute("samlResponse", signedSamlResponse);
request.setAttribute("authstatus","SUCCESS");
} else {
request.setAttribute("authstatus","FAIL");
}
}
} catch (SamlException e) {
request.setAttribute("error", e.getMessage());
request.setAttribute("authstatus","FAIL");
}
}
// Forward SAML response to ACS
response.setContentType("text/html; charset=UTF-8");
request.getRequestDispatcher(returnPage).include(request, response);
}
}

SamlResponseTemplate.xml 참조

<samlp:Response ID="##RESPONSE_ID##" IssueInstant="##ISSUE_INSTANT##" Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<Assertion ID="##ASSERTION_ID##"
IssueInstant="2003-04-17T00:46:02Z" Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>https://www.opensaml.org/IDP
</Issuer>
<Subject>
<NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress">
##USERNAME_STRING##
</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>
</Subject>
<Conditions NotBefore="##NOT_BEFORE##"
NotOnOrAfter="##NOT_ON_OR_AFTER##">
</Conditions>
<AuthnStatement AuthnInstant="##AUTHN_INSTANT##">
<AuthnContext>
<AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
</samlp:Response>

3.5 SAMLResponse Message를 Service Provider의 ACS로 forward

3.5.1 login_proc.jsp : forwarding을 담당

<%@ page contentType="text/html; charset=UTF-8"%>
<%
String acsURL = (String) request.getAttribute("acsURL");
String samlResponse = (String) request.getAttribute("samlResponse");
String RelayState = (String) request.getAttribute("RelayState");
String authstatus = (String) request.getAttribute("authstatus");
if (authstatus == null) authstatus = "FAIL";
if (RelayState == null) RelayState = "";
%>
<html>
<head>
<title>forward to ACS</title>
</head>
<%
if (samlResponse != null && authstatus.equals("SUCCESS")) {
%>
<body onload="javascript:document.acsForm.submit();">
<form name="acsForm" action="<%=acsURL%>" method="post">
<div style="display: none">
<textarea rows=10 cols=80 name="SAMLResponse"><%=samlResponse%></textarea>
<textarea rows=10 cols=80 name="RelayState"><%=RelayState%></textarea>
</div>
</form>
<%
} else {
%><script>alert('Login error'); history.back(-2); </script><%
}
%>
</body>
</html>

3.6 Service Provider이 ACS에서 SAMLResponse를 verify

3.6.1 PublicACSServlet : Service Provider측의 ACS

Parameter를 받고

String SAMLResponse = request.getParameter("SAMLResponse");
String RelayState = request.getParameter("RelayState");

Identity Provider의 public Key를 load

RSAPublicKey publicKey;
publicKey = (RSAPublicKey) Util.getPublicKey(publicKeyFilePath,"RSA");

Identity Provider가 보내온 SAMLResponse를 서명검증(verify)

boolean isVerified = SAMLVerifier.verifyXML(SAMLResponse, publicKey);

검증을 거친이후 실제 서비스 사이트로 forward 요청

request.getRequestDispatcher("./acs_proc.jsp").include(request, response);

PublicACSServlet.java 구현 종합

public class PublicACSServlet extends HttpServlet {
private final String keysDIR = System.getProperty("PGV3_HOME")
+ SystemUtils.FILE_SEPARATOR + "CryptoServer"
+ SystemUtils.FILE_SEPARATOR + "keys" + SystemUtils.FILE_SEPARATOR;

public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
doPost(request, response);
}

public void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String SAMLResponse = request.getParameter("SAMLResponse");
String RelayState = request.getParameter("RelayState");

// acs knows public key only.
String publicKeyFilePath = keysDIR + "paygate_public.der";

RSAPublicKey publicKey;
try {
publicKey = (RSAPublicKey) Util.getPublicKey(publicKeyFilePath,"RSA");

boolean isVerified = SAMLVerifier.verifyXML(SAMLResponse, publicKey);

if (isVerified) {

String loginid = null;
Document doc = Util.createJdomDoc(SAMLResponse);

Iterator itr = doc.getDescendants();

itr = doc.getDescendants(new ElementFilter());
while (itr.hasNext()) {
Content c = (Content) itr.next();
if (c instanceof Element) {
Element e = (Element) c;
System.out.println("Element:" + e.getName());

if ("NameID".equals(e.getName())) {
loginid = e.getText().trim();
break;
}
}
}
request.setAttribute("mid", loginid);
request.setAttribute("RelayState", RelayState);

response.setContentType("text/html; charset=UTF-8");
request.getRequestDispatcher("./acs_proc.jsp").include(request, response);
} else {
System.out.println("SAMLResponse is modified!!");
return;
}

} catch (SamlException e) {
e.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
}
}
}

3.7 완전하게 동작하는 WAR file

화면상의 제약으로 인해 완전하게 동작하는 WAR File을 별도 준비하였다.

파일이 필요한 분은 dev@paygate.net으로 메일요청하십시오.
또한 아래 링크를 통해서 file download 위치를 확인할 수 있다.
http://docs.google.com/Doc?id=dcxqxct2_4dsh8w4dt

4. SAML SSO 적용 실제 사이트

4.1 PayGate Admin Login

PayGate가 Service Provider 역할을 함.

4.1.1 최초 Service Login Page

이 단계는 SAMLRequest를 생성하기전 서비스 제공자가 제시하는 화면이다.

4.1.2 Identity Provider로서 Login Form 제시

이 화면이 보이기까지 서비스 제공자는 SAMLRequest를 생성하고

Identity Provider로 SAMLRequest를 redirect하면

유저인증을 위해서 보여지는 화면이다.
이 화면 이후 로그인 버튼을 누르게 되면 SAMLResponse 메세지를 생성하여 Service Provider의 ACS Site로 forwarding하게 된다.

4.1.3 Service Provider ACS verify를 거친후 마지막 페이지

Service Provider에 위치하는 ACS가 SAMLResponse를 verify한 이후 실제 서비스 제공 사이트로 forwarding한 결과이다.

4.2 Google Apps Service

google은 service provider역할을 하며

paygate는 identity provider역할을 한다.

4.2.1 gmail 서비스 로그인을 위한 인증 화면

google에서 SAMLRequest를 생성하여 identity provider인 페이게이트로 redirect하면

페이게이트에서 유저 인증을 위하여 생성한 화면이다.

4.2.2 identity provider의 인증을 거친후 로그인된 화면

Identity Provider가 SAMLResponse를 생성하여

google acs로 forwarding하면 verify한 이후 실제 서비스 제공 사이트로 연결한다.

5. SAML의 확장

5.1 공인인증기관과 Identity Provider

SAML SSO는 국내에서는 공인인증기관이 Identity Provider역할을 한다면 아주 적당한 business model이 될것 같다.

공인인증기관의 신뢰성을 바탕으로 인증서 발행한 유저에 대한 확인을 직접 수행하고
Service Provider는 공인인증기관의 확인만을 검증하여 그 결과를 신뢰할 수 있다.

더 나아가서는 꼭 공인인증기관이 Identity Provider역할을 하지 않더라도
공인인증서 기반의 Public Identity Provider는 쉽게 예상할 수 있다.

5.2 Payment Gateway와 Identity Provider

결제대행사(Payment Gateway)사가 Identity Provider역할을 하고
쇼핑몰이 Service Provider가 되는 구조를 생각해볼 수 있다.

SAMLRequest는 충분히 확장가능한 구조이므로 Payment 요청에 필요한 필수정보 (상품명, 가격 등)을 포함하여
PG사에 대하여 Identity Provider로서 요청하고
PG사 사이트에서 안전하게 Payment를 처리하고 그 결과를 SAMLResponse format으로 돌려주는 구조이다.

이는 Cross Domain간에 Payment Protocol에 대한 표준이 부재한 현 상황에서
의미있게 시도해봄직한 목표이다.

6. 참고자료

SAML Single Sign On Service for Google Apps

http://code.google.com/apis/apps/sso/saml_reference_implementation.html

OpenSAML

http://www.opensaml.org/

SAML at Wikipedia

http://en.wikipedia.org/wiki/SAML