블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

서버와 APNS(애플푸쉬서버)와의 보안 메커니즘 


애플 iOS 디바이스로 서버가 푸쉬를 보내고자 할때는, APNS 서비스를 거쳐야 한다.

푸쉬 메시지를 보내고자 하는 Provider 서버가 APNS로 푸쉬 요청을 보내면, APNS 서버가 디바이스로 푸쉬를 보내는 구조이다.

이때 APNS 서버와 Provider 서버를 어떻게 신뢰하는 지를 알아보자.

APNS 서버 입장에서는 Provider 서버가 해커가 아냐? 진짜 Provider 맞아? 하는 의문을 가질 수 있고, Provider 서버도 APNS 서버가 진짜 APNS 서버가 맞는지를 확인할 수 있어야 한다.

이를 양방향 SSL(TLS:Transport Level Security)를 이용해서 해결 한다.

먼저 SSL 메커니즘에 대해서 알아보자 SSL 을 비대칭 (PKI) 키 구조의 암호화를 이용하는데, Public Key Private Key 두개를 가지고 있다. Public Key로 암호화를 할 수 있지만, 반대로 암호를 푸는 복호화는 Private Key를 통해서만 가능하다.

그래서 서버가 SSL 연결을 보낼 때, Public Key를 클라이언트에 내려 보내면, 클라이언트는 그 Public Key를 사용해서 메시지를 암호화 해서 서버에 전송하고, Private Key를 가지고 있는 서버만이 그 메시지를 해석할 수 있는 구조이다.


Main In The Middle attack

그런데 이 과정에서 취약점이 발생하는데, 서버가 Public Key를 내려보낼 때 중간에 해커가 서버서부터 온 Public Key를 낚아채고, 자신이 새로운 Public Key A1 Private Key A2 페어를 만든 후, 새롭게 만든 Public Key A1을 클라이언트로 내려보낸다. 그러면 클라이언트는 이 Public Key A1을 가지고 암호화를 해서 중간에 해커에게 보내고, 해커는 이 메시지를 자신의 Private Key A2로 열어서 본후에, 다시 원래 서버가 준 Public Key로 메시지를 암호화 해서 서버에 보낸다.

이 때 클라이언트와 서버는 Public Key Private Key로 안전하게 통신하는 것 처럼 보이지만, 사실은 사실은 중간에 해커에 의해서 메시지가 도청되고 있는 상황이 된다. 이런 Attack 방식을 Man In The Middle attack (MITM)


Signing

이러한 Public Key가로채기를 막을려면 Public Key를 받는 클라이언트 쪽에서 이 Public Key APNS에서 온 것이 맞는지를 확인하면 되는데, 보통 이 Public Key는 인증서(Certificate)안에 넣어서 클라이언트에게로 배달된다. 이 때 메시지 변조를 막기 위해서 Certificate는 안에 들어 있는 메시지로 생성된 일종의 해쉬값과 같은 signature 값을 가지고 있어서, 만약에 내부 메시지가 변경이 되면 원래 signature와 비교하여 메시지가 변경되었는지를 확인할 수 있다.이를 생성하는 것을 싸이닝(Signing) 이라고 하는데, Signing Private 키로 생성되고, 이에 대한 비교는 Public Key를 통해서 할 수 있다. (Sign을 확인하기 위해서는 Sign에 사용된 Private Key에 대한 페어 Public Key를 가진 인증서를 가지고 있어야 한다. Public Key를 통해서 싸이닝을 확인할 수 있다.)




Channing

signature를 통해서 전달되는 메시지가 변조되는 것을 막을 수 는 있지만 위의 MITM attack 처럼 인증서 자체를 통째로 바꿔칠 수 있기 때문에, 이 인증서가 믿을만한 인증서인지를 확인해야 한다. 인증서에는 인증서를 발급한 기관 (CA : Certificate Authority)정보가 들어 있는데, “XXX에서 인증서를 발급함이라는 정보가 들어 있다.

그런데 문제는 이 인증서를 발급한 기관을 믿을 수 있냐는 거다. 구멍가게가 될 수 도 있고

은행과 같은 인증된 기관이 될 수 도 있다. 그래서 사용하는 기법에 인증서 Channing 기법인데, 인증서를 발급한 사람이 이 인증서를 신뢰된 기관에 가서 인증을 받은 후, 그 인증 정보를 인증서에 추가하는 방식이다.

아래 그림을 보자, 맨 아래의 Engineering CA는 자체 적으로 인증서를 발급하였다. 이 인증서를 USA CA certificate에 보내서 추가 인증을 받는다. 그런데, USA CA certificate 인증서는 이미 신뢰된 기관으로부터 인증을 받은 인증서이기 때문에, 이 신뢰된 기관의 인증 정보가 추가되게 된다. (신뢰된 인증 기관으로부터 인증서에 서명을 받으려면 회사 정보,신상 정보 등을 받은 후에 신원 확인 절차를 거쳐야만이 서명을 받을 수 있다.)



(출처 : https://developer.mozilla.org/en-US/docs/Introduction_to_Public-Key_Cryptography)

그래서 최종 인증서 모양은



이러한 형태가 되고, 클라이언트는 이 인증서 chain을 통해서 Root CA가 신뢰된 인증서인지를 확인하면 이 전체 인증서가 신뢰된 인증서임을 확인할 수 있다. (네트워크를 통해서 Root CA가 맞는지를 확인하게 되고, 만약에 Root CA라도 외부로 노출이 되었을 경우에 Revoked List라는 유출된 인증서 목록을 유지함으로써 인증서가 문제가 없는 인증서인지를 확인할 수 있다.)

이러한 절차를 거치면 MITM Attack을 통한 감청을 막을 수 있다.

다음 문제는 클라이언트 입장에서는 서버가 신뢰할 수 있는 서버인지를 알 수 있다. (Provider는 이 Root CA를 통해서 서버가 APNS 서버임을 알 수 있다.)


Mutual SSL

그러나 서버 입장에서는 클라이언트가 Provider서버가 맞는지? 를 확인할 필요가 있다. 이것이 인증 (authentication) 과정인데, TLS(SSL) 연결이 안전하게 설정된 후에, 사용자 ID,PASSWD를 넣어서 클라이언트(Provider)를 확인하는 방법도 있지만, 조금 더 확실한 방법으로, 클라이언트가 발급한 인증서를 사용하는 방식을 사용한다.

이 방식이 양방향 SSL 방식 (Mutual SSL) 인데, SSL 연결이 될 때 서버가 클라이언트에게 Public Key 를 내려 보내는 방식과 마찬가지로 클라이언트가 서버에게 Public Key를 전송하고 메시지를 클라이언트의 Private Key를 이용해서 암호화 해서 보내는 방법이다.

이 때 클라이언트에서 서버로 전송하는 Public Key는 인증서를 통해서 전달이 되게 되고, 인증서에는 인증서 발급 기관등의 정보가 들어가 있기 때문에, 이를 통해서 클라이언트를 인증을 할 수 있다.


APNS CSR

그래서 APNS의 경우에는 Service Provider Private/Public Key pair 를 생성한 후에, Public Key만을 담은 인증서를 생성하여, 웹사이트를 통해서 Service Provider 업체에 대한 정보와 함께, 싸인을 요청한다.

싸인을 진행할 때 애플은 인증서에 대한 고유 ID등을 통해서 이 인증서를 통한 호출이 어느 기관(업체)에서 들어오는지를 맵핑 해놓고, 향후 양방향 SSL 연결시에 이 정보를 가지고 클라이언트를 판독할 수 있다.

이를 기반으로 전체 서버간의 플로우를 보면

1.  ProviderPrivate Key를 생성한다

2.  Private Key를 기반으로 *.csr 파일(인증서 싸인 요청 파일)을 만든다. 이 파일에는 Public key가 들어 있는 인증서와 싸이닝을 요청하는 Provider의 업체 정보들이 들어가 있다.

3.  Provider는 애플 포탈에 들어가서 이 csr 파일을 업로드 한다.

4.  애플 포탈은 csr 파일을 기반으로 인증서(certificate)를 생성한후에, 애플의 인증서를 이용해서 싸인을 추가해서 Provider에게 돌려준다.

5.  Provider 4에서 받은 인증서(public key가 들어 있는)1에서 생성된 Private KeyProvider 서버내에 설치 한다.

6.  이때 1에서 생성한 Private Key,그리고 애플이 싸이닝하여 추가된 Public Key 가 들어 있는 인증서, 인증서 체인에 사용된 모든 인증서를 추가해서 한 파일(*.p12)에 넣는다.(*.p12 파일 포맷은 X.509를 지원하는 파일 포맷중에 유일하게 Private Key를 같이 넣을 수 있는 포맷이다.)




APNS Provider간의 Trust

다음 통신이 이루어지게 되면, 아래 그림과 같이

1.  Provider ServerTLS 연결을 요청한다.

2.  APNS 서버는 certificate(인증서) public key를 넣어서 내려 보낸다.

3.  Provider는 이 인증서의 Root CA를 확인하여, 이 인증서가 애플에서 온 정상적인 인증서임을 확인한다. (Provider가 상대편이 APNS임을 확인함)

4.  Provider는 앞의 CSR에 의해 생성된 인증서를 APNS에 보낸다.

5.  APNS 4에서 온 인증서에 애플의 인증서로 Sign 이 되어 있는 것을 확인하고, 클라이언트가 (Provider) 합법적인 클라이언트임을 확인하고,어떤 사용자인지를 판독한다. (APNS Provider가 누구인지를 확인하였다.)

6.  마지막으로 양 서버간의 신뢰돈 TLS(SSL)연결이 성립되었다.



 

저작자 표시 비영리
신고

'아키텍쳐  > Security & IDM' 카테고리의 다른 글

서버와 APNS(애플푸쉬서버)와의 보안 메커니즘  (3) 2014.10.07
OAuth 2.0 노트  (0) 2014.08.11
OAuth 2.0 based API 인증 메모  (0) 2014.06.05
Digital Signing의 개념  (0) 2014.05.21
Java keystore file  (0) 2013.09.27
SSL/TLS 관련 개념 링크  (1) 2013.09.24

OAuth 2.0 노트

아키텍쳐 /Security & IDM | 2014.08.11 17:05 | Posted by 조대협

OAuth 용어 정리

Resource Owner (사용자)

Authorization Server (인증서버

Resource Server (REST API)



 

OAuth 2.0 grant flow

Authorization code grant flow

주로 Web Application에서 사용됨

Implicit grant flow

자바스크립트 애플리케이션에서 많이 사용됨. 스크립트 단에서는 credential 등이 노출 될 수 있으니, 주로 Read only 용도로 많이 사용함. accessToken이 노출될것을 전제로 함.

모바일 애플리케이션도 많이 사용하는걸로 나오네??

Ÿ   Used in public clients

Ÿ   It's is a redirection-based flow (similar to the one in the authorization code grant)

Ÿ   The access token is received as a parameter of the redirection endpoint upon successful completion of the request, similar to the authorization code parameter in the authorization request response in the authorization code grant



Flow

     The first step is initiation of the flow. The client redirects the User agent to the Authorization server by using the authorization endpoint, the client identifier, and the redirection endpoint that will be used for the response.

     The Authorization server authenticates the Resource owner and requests his decision whether to authorize or deny the request.

     If the Resource owner authorizes the request (which is assumed), he is redirected back with response information, using the supplied redirection endpoint that was provided with the initial request. The response information is contained in the URL fragment that contains the access token and other parameters (we'll see the difference between a regular URL parameter and one found in a URL fragment in the detailed overview).

     Now that the User agent (the browser) is redirected back, the access token included in the response is passed to the Client application.

Client Server Application Case

Mobile App Case

(웹이 아니기 때문에, Redirect 처리를 어떻게 해야 할지 고민해야 함.

Samsung Account와 같이 전용 APK를 넣는 방식이나, 웹 페이지 Scrapping 방식등이 있음)

 

Resource owner password credential grant flow

직접 ID,PASSWORD를 보내는 방식으로, 1st level 파트너나 자사 시스템에 많이 사용.

기존의 HTTP BASIC이나 HTTP Digest 인증 방식을 migration하기가 용이함



     The resource owner (for example, the user) supplies the Client application with his username and password.

     The client application makes a request to the Authorization server, including the user's credentials and also his own identifier and secret.

     The Authorization server authenticates the client based on his identifier and secret, checks whether it is authorized for making this request, and checks the resource owner credentials and other parameters supplied. If all checks pass successfully, the Authorization server returns an access token in response.

Client credential grant flow

Userless 상태에서 많이 사용됨. (API 키와 유사한 방식)

 

 

저작자 표시
신고

'아키텍쳐  > Security & IDM' 카테고리의 다른 글

서버와 APNS(애플푸쉬서버)와의 보안 메커니즘  (3) 2014.10.07
OAuth 2.0 노트  (0) 2014.08.11
OAuth 2.0 based API 인증 메모  (0) 2014.06.05
Digital Signing의 개념  (0) 2014.05.21
Java keystore file  (0) 2013.09.27
SSL/TLS 관련 개념 링크  (1) 2013.09.24

OAuth 2.0 based API 인증 메모

아키텍쳐 /Security & IDM | 2014.06.05 17:02 | Posted by 조대협


* Authroization Code

- Redirect base / 서버 백엔드가 있는 경우 사용 - 파트너사가 API를 사용하는 시나리오에 유리

* Implicit 

- Rediect base / 특히 Java script 처럼 서버 백엔드가 없는 경우 유용. Read Only 등에 사용

* Resource Owner Password Credential 

- Client Id, Secret을 앱에 넣은 후, Client Id/Password로 인증하여, access token을 발급 받는 방식으로, Authorization Server와 Resource Owner가 같은 서비스인 경우 유용함 (자사 API 제공에 유용)

* Client Crendetial


유용한 Link

  • 서버 구현체 : http://oauth.net/2/
  • http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified
  • node.js 모듈 - https://github.com/jaredhanson/oauth2orize
  • http://vinebrancho.wordpress.com/2014/05/19/oauth2-restapi-server-%EB%AA%A8%EB%B0%94%EC%9D%BC-%EC%95%B1%EC%9D%84-oauth2-0%EC%9C%BC%EB%A1%9C-%EC%A2%80-%EB%8D%94-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C/


저작자 표시
신고

'아키텍쳐  > Security & IDM' 카테고리의 다른 글

서버와 APNS(애플푸쉬서버)와의 보안 메커니즘  (3) 2014.10.07
OAuth 2.0 노트  (0) 2014.08.11
OAuth 2.0 based API 인증 메모  (0) 2014.06.05
Digital Signing의 개념  (0) 2014.05.21
Java keystore file  (0) 2013.09.27
SSL/TLS 관련 개념 링크  (1) 2013.09.24

Digital Signing의 개념

아키텍쳐 /Security & IDM | 2014.05.21 17:04 | Posted by 조대협


source : http://www.slideshare.net/simmikamra/digital-certificates?qid=2dec4a02-6d14-4694-9b6d-090a3da163b5&v=qf1&b=&from_search=1

저작자 표시
신고

'아키텍쳐  > Security & IDM' 카테고리의 다른 글

OAuth 2.0 노트  (0) 2014.08.11
OAuth 2.0 based API 인증 메모  (0) 2014.06.05
Digital Signing의 개념  (0) 2014.05.21
Java keystore file  (0) 2013.09.27
SSL/TLS 관련 개념 링크  (1) 2013.09.24
Security-애플리케이션 보안 1. 인증 방식 및 비밀번호 암호화  (0) 2013.06.09

Java keystore file

아키텍쳐 /Security & IDM | 2013.09.27 00:43 | Posted by 조대협

Java KeyStore file에 저장되는 것들


http://docstore.mik.ua/orelly/java-ent/security/ch11_02.htm


Now that we understand the pieces that make up a key management system, we can look at the topic of key management itself. From an administrative perspective, the primary tool that provides key management for Java 1.2 is the keytool utility. Keytool operates upon a file (or other storage system) containing a set of private keys and certificates for those keys. The keytool file contains a set of entries; each entry may have the following attributes:

  • An alias. This is a name you can use to reference the entity in the database. For example, an alias for my entry might be sdo, or ScottOaks.

  • One or more certificates that vouch for the identity of the entry. These certificates also provide the public key for the entry.

  • Optionally, a private key. If present, the private key can be protected by a password.


저작자 표시
신고

SSL/TLS 관련 개념 링크

아키텍쳐 /Security & IDM | 2013.09.24 00:36 | Posted by 조대협

http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-howto.html

http://www.javaworld.com/jw-02-2001/jw-0216-howto.html

http://juntheater.tistory.com/entry/keytool%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-%ED%82%A4-%EC%83%9D%EC%84%B1

http://juntheater.tistory.com/entry/Java-SSL-%EA%B5%AC%ED%98%84


weblogic SSL Client sample

http://docs.oracle.com/cd/E11035_01/wls100/security/SSL_client.html

http://blog.palominolabs.com/2011/10/18/java-2-way-tlsssl-client-certificates-and-pkcs12-vs-jks-keystores/


PKI 관련 파일 명에 대한 개념 링크

http://serverfault.com/questions/9708/what-is-a-pem-file-and-how-does-it-differ-from-other-openssl-generated-key-file



Tomcat 2 way SSL (mutual SSL)

http://blog1.vorburger.ch/2006/08/setting-up-two-way-mutual-ssl-with.html



Self study memo

Public Key 기반의 암호화

암호화와 복호화키를 다른 키를 사용.

Private Key로 암호화 하고 Public Key 로 복호화를 함. Public Key는 공개되어도 상관 없음.

가장 널리 사용되는 Public Key 기반의 암호화 알고리즘으로는 RSA가 있음

 

인증서의 필요성

그러나 문제는 PKI 를 사용할 경우, 해커가 main in middle attack으로 pubic key를 가로챌 수 있다. 이를 방지하기 위해서, 3자의 공인된 인증 기관 (CA) public key를 등록하고, public key가 들어 있는 인증서(certification)을 발급 받아서 사용한다.

 

인증서 표준중, 많이 사용되는 인증서가 X.509 인증서 임


 

그외에 PGP(Pretty Good Privacy) Ceriticates SDSI (Simple Distributed Security Infrastructure)등이 있음.

 

인증서 Chain

상위 인증서가 하위 인증서에 대한 Public Key를 가지고 있음.

상위 인증서가

 

 

인증서 파일 포맷

PKCS

- X.509와 같은 인증서를 저장하기 위한 포맷 (PKCS12 is a password-protected format that can contain multiple certificates and keys)

CF. JKS

http://blog.palominolabs.com/2011/10/18/java-2-way-tlsssl-client-certificates-and-pkcs12-vs-jks-keystores/

 

 

인증서 파일 포맷은 크게

·         PEM Governed by RFCs, it's used preferentially by open-source software. It can have a variety of extensions (.pem, .key, .cer, .cert, more)

·         PKCS12 A private standard that provides enhanced security versus the plain-text PEM format. It's used preferentially by Windows systems, and can be freely converted to PEM format through use of openssl.

·         DER The parent format of PEM. It's useful to think of it as a binary version of the base64-encoded PEM file. Not routinely used by anything in common usage. --> 확장자가 *.CER 경우, DER 인코딩된 X.509 바이너리이거나, Base 64 인코딩된 X.509 인증서임

 

3가지가 주류로 나뉘어짐

세부적으로 보면

·         .csr This is a Certificate Signing Request. Some applications can generate these for submission to certificate-authorities. It includes some/all of the key details of the requested certificate such as subject, organization, state, whatnot, as well as the public key of the certificate to get signed. These get signed by the CA and a certificate is returned. The returned certificate is the public certificate, which itself can be in a couple of formats.

·         .pem Defined in RFC's 1421 through 1424, this is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates. The name is from Privacy Enhanced Email, a failed method for secure email but the container format it used lives on.

·         .key This is a PEM formatted file containing just the private-key of a specific certificate. In Apache installs, this frequently resides in /etc/ssl/private. The rights on this directory and the certificates is very important, and some programs will refuse to load these certificates if they are set wrong.

·         .pkcs12 .pfx .p12 Originally defined by RSA in the Public-Key Cryptography Standards, the "12" variant was enhanced by Microsoft. This is a passworded container format that contains both public and private certificate pairs. Unlike .pem files, this container is fully encrypted. Every time I get one I have to google to remember the openssl-fu required to break it into .key and .pem files.

A few other formats that show up from time to time:

·         .der A way to encode ASN.1 syntax, a .pem file is just a Base64 encoded .der file. OpenSSL can convert these to .pem. Windows sees these as Certificate files. I've only ever run into them in the wild with Novell's eDirectory certificate authority.

·         .cert .cer A .pem formatted file with a different extension, one that is recognized by Windows Explorer as a certificate, which .pem is not.

·         .crl A certificate revocation list. Certificate Authorities produce these as a way to de-authorize certificates before expiration.

 

 

주의!! - 전자 서명과 인증서는 개념이 다름

전자 서명 (Digital Signature) Private signature를 생성한 후에, public key를 이용하여 descrypt 하여, 문서의 유효성을 판단.

이때, public key에 대한 변조를 막기 위해서 인증서(Certification) 를 통해서 public key를 전달함

 

http://blog.naver.com/jasonalive?Redirect=Log&logNo=80008939065


양방향 SSL 을 E2E로 구현하는 것에 목표를 두자.


저작자 표시
신고

Authentication (인증 방식)

일반적인 id,passwd 기반의 인증 방식

사용자 정보와 사용자 credential (id/passwd)를 데이타베이스에 저장해놓고, 사용자로 부터 id/passwd를 입력받아, 이를 비교하여 인증하는 방식.

일반적은 중소 규모 사이트 개발에는 RDBMS를 사용하는 것이 일반적이며,조직 구조, 여러가지 Role, 권한등을 저장할때는 LDAP등을 사용한다. 근래에는 대규모 사용자를 저장하기 위해서 Cassandra와 같은 NoSQL을 저장하는 경우도 많다.

이러한 저장소에 비밀 번호를 저장할때 평문으로 저장하는것 보다, 암호화된 형태로 저장하는 것이 좋다. 그래서 MD5 SHA1같은 Hash로 변경해서 저장한다. 이렇게 하면, Hacker에 의해서 데이타 베이스가 탈취되더라도 데이타 베이스내의 passwd Hash 값만 저장되어 있기 때문에, 원본 passwd는 알아낼 수 가 없다.

hash = sha1-256(passwd)

그렇다면 원본 passwd를 알아낼 수 없다면, 인증은 어떻게 할까? 답은 쉽다. 사용자가 입력한 passwd를 같은 알고리즘으로 Hash값을 계산한 후에, 데이타 베이스에 저장된 Hash 값과 일치하는지를 체크하면 된다.

이런 Hash 알고리즘도 요즘은 어느정도는 복호화가 가능하다. asdf1234MD5 hash 값은 1adbb3178591fd5bb0c248518f39bf6d http://www.md5decrypt.org/를 통해서 테스트 해보면, MD5 Hash를 쉽게 디코딩 할 수 있다 비밀번호나 스트링등을 MD5로 변환한 dictionary를 가지고 있다가, dictionary를 기반으로 하여 search를 하면, Hash 전의 값을 찾아내는 방법이다.

이를 보안상의 헛점을 극복하는 방법이 SALT라는 기법인데, passwordhash로 변경하기 전에 password 끝에 random string을 붙여서 Hash로 변경하면, dictionary 기반의 attack에서는 random string이 끝에 붙어 있기 때문에, dictionary에 저장되어 있을 가능성이 상대적으로 낮게 되고, 이로 인해서 이러한 dictionary attack을 회피할 수 있다.

hash = sha1-256( strcat(passwd,salt) )

이때 salt도 데이타 베이스에 hash 값과 함께 저장한다.

Salt의 길이를 늘리고, random화 하면, 보안 수준도 같이 올라간다.

여기에 조금 더, 복잡도를 높이는 방식은, salt에 의해서 계산된 hash값을 다시 같은 salt를 더해서 N번 재 hash하는 방식이 있다.(보통 1000번 이상의 루프를 추천합니다.)

hash = sha1-256( strcat(passwd,salt) )

hash = sha1-256( strcat(hash,salt) )

:

:

X.509 기반 인증

X.509 PKI 기반의 인증서를 이용하여 서버가 클라이언트를 인증하는 방식으로, 쉽게 이야기 해서, 클라이언트를 인증할때, id,passwd를 이용하는 방식이 아닌 인증서를 사용하는 방식이다. 인터넷 뱅킹의 공인 인증서등을 생각하면 되며, 양방향 SSL을 사용하면, 이 방식의 인증을 구현할 수 있다.

특히 서버간의 통신에 대해서, 강한 인증이 필요한 경우, 양방향 SSL을 사용하게 되면, 서버간의 인증을 쉽게 구현할 수 있다.

저작자 표시
신고


Federation 기술로는 크게 


1. WS-Security가 있으며,

 상세 스펙으로는 

WS-Trust 는 STS 기반의 초기 인증과 토큰 발행

WS-Federation은 다른 리소스의 액세스에 대한 토큰 사용을 정의

을 정의


2. 반대 진영으로는 SAML 기반의 SSO가 있음


3. 그리고 B2C 진영에는 OAuth도 사용됨


주로 현재 대세는

SSO는 SAML을 사용하고,

API를 통한 특정 resource에 대한 접근은 OAuth를 사용한다.


구글을 사례

SSO 구현 : http://support.google.com/a/bin/answer.py?hl=ko&answer=60224

API 접근 : https://support.google.com/a/bin/answer.py?hl=ko&answer=61017&topic=2759255&rd=1



저작자 표시
신고

Claim based Authentication (CBA)

아키텍쳐 /Security & IDM | 2013.06.07 22:58 | Posted by 조대협


CBA Claim based authentication


ADFS 2.0 등 MS 진영에서 주로 사용함

- Claim : Subject를 identitify 할 수 있는 name, group 등 (쉽게 말해서 attribute)

- Token : Claim을 transpport하기 위한 packet ( 1개 이사으이 claim이 packaging되며, digitial signature로 packaging됨) ex) SAML packaging도 하나의 Token의 예

- Issuer: Token을 만드는 대상 (Idp가 주로 Issuer가 되는 경우가 많음)

- Secure Token Server (STS) : The central issuing authority. (In most case STS works as Idp) - 인증하고 Token 만들어주는 서버. (ADFS 2.0 )

- Replying party - Claim based authentication 을 사용하는 Sp (Service Provider)


Process

전체적인 흐름 자체는 SAML과 유사함.

사용자가 resource를 요청하면 STS (Idp)서버로 redirect해서 login 한후,  token 발급 받아서, 그 token으로, resource에 가서 인증하고 log in 하는 시나리오


1. User attempts to access an application.

2. User is redirected to the STS.

3. User authenticates to the STS.

4. The STS pulls claim information from the appropriate store and uses the information to create a token.

5. The token is sent back to the user.

6. Token is submitted to application.


3.7.2.1.1. Passive Client Flow


1. User attempts to access resource.

2. Resource redirects browser to STS URL.

3. Browser redirects to STS URL.

4. User authenticates to STS.

5. STS issues token to client.

6. Token is passed to resource.

7. User is granted access to resource.



3.7.2.2.1. Active Client Flow


1. Username used to request CBA token.

2. STS authenticates user.

3. CBA token issues to application.

4. Call made to web service using token.

5. WIF validates security token.

6. Response returned.



3.7.3. Cross-Realm Federation with CBA

As we’ve seen, each application must be configured with an issuer. This issuer is the one that creates the tokens that will be trusted by the application. So what happens when an application trusts one issuer but a user logs into a different issuer? How can the user still use the application? The answer is cross-realm federation.

Cross-realm federation allows you to log into one STS and access applications that are configured for another STS. There are many situations where this might be the case. You might have a situation where you have an application that is accessed by customers or partners, but you don’t want to manage user accounts for those users. You can have the users log into a separate IdP but still allow them access to your application. You may also have a situation where your organization has acquired a new company. This company already had their own IdP. If you need to provide these users access to your company’s applications, you don’t have to wait until you port all the users over to your IdP. They can still log into their own IdP and have access to your company’s applications.

You can set up a federation trust between two issuers. In addition to configuring the trust, you have to configure a token translation. With a token translation, you configure the incoming claim and what the outbound claim should be changed to.

1. User attempts to access application.

2. User is redirected to issuer1 configured on application.

3. User selects issuer2 for authentication.

4. User authenticates to issuer2 and receives token.

5. User presents token to issuer1.

6. Issuer1 converts token to one that can be used by applications and send that token to user.

7. User presents new token to application.


MS 문서 https://www.google.co.kr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&sqi=2&ved=0CDQQFjAA&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F7%2Fd%2F0%2F7d0b5166-6a8a-418a-addd-95ee9b046994%2FGeneva_Beta1_DataSheet.pdf&ei=XuSxUYuUAYWbigeJiYGIAg&usg=AFQjCNGbmhiqxvwNx-T4OKxVL5gVApVAZA&sig2=QPNpHxknVD6NHYHVVHCeBw&bvm=bv.47534661,d.aGc 
에 설명 엄청 잘되어 있음


MS에서는 WIF (Windows Identity Foundation) - .NET Framework과 ADFS 2.0(서버)를 이용해서 구현


저작자 표시
신고

SAML 기반의 web sso 원리 정리

아키텍쳐 /Security & IDM | 2013.06.04 23:08 | Posted by 조대협

Single Sign On을 지원하기 위한 프로토콜이나 방법은 여러가지가 있다.

그중 대표적인 방법으로 CAS,SAML,OAuth등이 있는데, CAS는 쿠기를 기반으로 하기 때문에 같은 도메인명 (xxx.domain.com yyy.domain.com) 사이에서만 SSO가 가능하다. (그만큼 구현도 쉽다.) OAuth는 현재 B2C쪽에 많이 사용되는 프로토콜이고, 그리고 마지막으로 SAML 있다. cross domain간 SSO 구현이 가능하며, OAuth 만큼이나 많이 사용되고 있다. 


SAML은 어떤 구현체가 아니라 SSO등(꼭 SSO만은 아님)을 구현하기 위한 XML 스펙이다.

HTTP GET, POST 또는 SOAP 웹서비스 등 여러가지 방법으로 구현될 수 있으며, 여기서는 HTTP Post를 이용한 SSO 원리와 솔루션 설계시 유의 사항을 설명한다.


1. Site Sp A로 초기 로그인





    1. Browser에서 사이트 SpA로 접속한다.
    2. 사이트 SpA에는 로그인이 되어 있지 않기 때문에 (세션이 없어서). SpA에서는 SAML request를 만들어서, Browser에게로 redirect URL을 보낸다.
    3. Browser는 redirect URL에 따라 IdP에 접속하고, Idp에서 login form을 넣고 log in을 한다. 이때, IdP와 Brower 사이에 HttpSession 또는 Cookie로 Login에 대한 정보를 기록한다. 그리고 다시 사이트 SpA로의 SAML response를 포함한 redirect URL을 browser로 전송한다.
    4. Browser는 SAML reponse를 가지고 SpA로 접속하면, SpA에는 인증된 정보를 가지고 로그인 처리를 한다. ※ 이 과정에서는 바로 사이트 SpA의 사용자 페이지(예를 들어 /home)등으로 가는 것이 아니라, SAML에 의해서 미리 정의한 SpA의 SAML response 처리 URL로 갔다가 SAML response를 처리가 끝나면 인증 처리를 한후, 사용자 페이지(/home)으로 다시 redirect한다.

2. Site Sp A로 로그인된 상태에서 Site Sp B로 로그인




  1. 사이트 SpA에서 로그인된 상태에서 SpB에 접속한다.
  2. 사이트 SpB는 로그인이 되어 있지 않기 때문에, SAML 메시지를 만들어서 IdP의 login from으로 redirect URL을 보낸다.
  3. 브라우져는 redirect URL을 따라서 IdP에 접속을 한다. IdP에 접속을 하면 앞의 과정에서 이미 Session 또는 Cookie가 만들어져 있기 때문에 별도의 로그인 폼을 띄위지 않고, SAML response message와 함께, SpB로의 redirect URL을 전송한다. 
  4. Browser는 Sp B에 인증된 정보를 가지고 로그인한다.

 

솔루션과 설계시 유의 사항


여기서 두 가지 기술적인 이슈가 발생하는데 

첫번째는 IdP에는 대규모 사용자를 지원할 경우, Session 정보를 어떻게 분산 저장할것인가이다.

WSO2 Identity server의 경우에는 각 instance의 memory에 이 session 정보를 저장하고, 자체 clustering feature를 이용하여 이 session을 상호 복제한다. Oracle WebLogic이나 Apache Tomcat cluster의 Http session clustering과 같은 원리이다.

이 경우에 각 instance의 메모리 size에 따라 저장할 수 있는 session의 수의 한계를 가지게 되고, instance간 session 복제로 인하여, 장애 전파 등의 가능성을 가지게 된다.

그래서 Shibboleth의 경우에는 이 Session 정보를 별도의 terracotta와 같은 data grid에 저장하도록 하여, 확장성을 보장할 수 있다.

두번째는 로그 아웃에 대한 문제인다.

Sp A나 Sp B에 SAML을 이용한 초기 인증이 성공한 경우, 제 로그인(인증)을 막기 위해서 자체적으로 HttpSession등을 사용하여, 별도의 log in session을 유지해야 하는데, 이경우 Sp A,Sp B의 Session Time out 시간이 다를 수 있기 때문에, 한 사이트에서 log out이 된 경우 전체 사이트에 걸쳐서 log out이 안될 수 있는 incosistency 문제가 발생한다.

그래서 WSO2 identity server의 경우에는 별도의 logout URL을 정의하여, IdP에서 log out을 한경우에 전체 사이트에서 log out을 시키는 global log out 기능을 제공한다.


SAML 기반의 SSO 솔루션은 대표적으로

simplePHPSAML - 가장 널리 쓰이고, 사용이 쉽다.

Shibboleth - java stack으로 구현이 되어 있으며, terracotta를 이용하여 session을 저장하기 때문에 상대적으로 확장성이 높다.

WSO2 identity server - 앞에서도 언급하였듯이, 확장성에 문제가 있는 것으로 보이며, 자체 OSGi 컨테이너인 carbon 엔진 위에서 동작한다. SAML 뿐만 아니라 OAuth,STS 서비스를 추가 지원하며, Provisioning protocol인 SCIM도 함께 지원한다. 오픈 소스이지만, 제품 완성도가 매우 높고, 사용이 매우 쉽다. (모니터링,관리 기능등이 강점)

Open AM - Sun IDM을 모태로 하여, 현재 오픈소스화 되었다. 아무래도 enterprise 제품을 기반으로 하다 보니 복잡도가 상대적으로 높다.

CAS - TBD


저작자 표시
신고