랄라라

Taking remote shell, for carrying out different tasks is a norm, if you have multiple server machine's in your infrastructure. Different protocols and tools were made to accomplish this task of taking a remote shell. Although the tools made during the initial days were capable enough to carry out necessary shell related tasks, there were different design concerns, that resulted in advancements and new tools to accomplish this task.

In this tutorial guide, we will be discussing one such tool, that was designed to eliminate the flaws in previous remote shell programs. Our topic of interest for this tutorial is none other than the Secure Sell, better known as SSH.

The key characteristics that makes a remote login program an efficient one is pointed out in the below list.

• The first and the foremost is the privacy of the communication. This means the connection, which provides a remote shell login, must be encrypted to prevent eavesdropping.
• There must be a mechanism to check whether the data send by either party is not altered, or tampered with. In short, integrity check is a must.
• Identity of both the server and the client must be provided to each other, to establish a proper authentication.

A wonderful thing about the Secure Shell (SSH), is the fact that, it incorporates all the above mentioned characteristics, in addition to some unique features of its own.

Encryption and authentication mechanisms provided by SSH enhances security to a greater extent, because mostly the communication occurs through a medium, which is unsecured(The Internet). This is majorly due to the fact that, ssh was made to replace some insecure remote login programs like rlogin,telnet etc.

SSH provides multiple mechanisms for authenticating the server and the client. Two of the commonly used authentication mechanism are password based, and key based authentication. Although password based authentication is also secure, its advisable to use key based authentication instead. As i mentioned before, there are some added features apart from the secure authentication and data encryption provided by ssh. Some of the well known features of SSH are mentioned below.

• SSH Tunneling
• TCP port forwarding

We will not be discussing the above mentioned features of SSH in this tutorial, instead will be discussing how an SSH connection from a server to a client work. We will be discussing the complete workflow of an SSH connection in detail. Iterations in protocols to improve the overall working, is a norm. SSH protocol also has different iterations and among them the most widely used versions are SSH version 1 and SSH version 2.

The current default and recommended version of SSH is SSH protocol Version 2. We will be beginning by discussing both these versions separately and will be ending with a comparison of both these two versions of SSH, along with its workflow.

When we discuss encryption and data security, there are two types of primarily used cryptographic systems. One is Public Key cryptography(or sometimes called as asymmetric cryptography) & the other is Secret key cryptography (or sometimes called as symmetric cryptography).  Most of the modern day security system's use these two types, in multiple ways to ensure security in communication. I have two article's that discuss tools related to symmetric and asymmetric encryption.

• How does SSL Encryption Work
• Using GNU Privacy Guard to encrypt communication

The above tutorial's does not discuss cryptography, but it does describe its application in real life. We will be including a few articles related to cryptography in the coming days (I know its quite difficult to discuss cryptography details, but will surely give it an attempt.

)

Workflow of Secure Shell(SSH) Protocol Version 1

The major confusion, that's widely found among industry people, is that "SSH works on Public key encryption and not on Secret Key encryption". I would like to take this opportunity to clear this confusion here. Asymmetric encryption has a lot of overhead involved, and is a little bit time consuming to decrypt data using it.

Due to which most of the protocol employs Public key cryptography(asymmetric encryption), only to share the secret key used for symmetric encryption, which will be used as a primary encryption mechanism for the entire data communication in that session. To make things clear "Asymmetric encryption is only used to share the secret key, which will be used for symmetric encryption"

So if you think logically, the first step, that needs to be taken while establishing an SSH connection, is to make a secure channel between the server and the client.

First the client authenticates the server, because client is the one that initiates the connection. After the server is authenticated, and the client is sure about the identity of the server, a secure symmetric channel is formed between them.

This secure channel will be used for authenticating the client,sharing keys,passwords,and other things. For understanding how this works, let's go through a step by step process.

Step 1

A connection is always initiated by the client to the server. So the first step is to establish a TCP connection to port 22 on the server. Let's see what we get when we connect to port 22 on the server.

[root@slashroot1 ~]# telnet 192.168.0.105 22
<div id="edfs"><a href="http://graciatelevisio.cat/payday-loans-direct-lenders-instant-approval">graciatelevisio.cat/payday-loans-direct-lenders-instant-approval</a></div>
Trying 192.168.0.105...
Connected to 192.168.0.105 (192.168.0.105).
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3

The client gets two valuable information from the above connection. One is the Protocol version supported by the server. Second is the ssh server package version(which is not necessary. In fact you should not reveal this message to the client)

At this point, the client will continue if it supports version 2 protocol, otherwise will break the connection.

Step 2

As soon as the client decides whether it should continue, based on the protocol version shown by the server, server and client will now switch to a "Binary Packet Protocol"

This protocol contains a packet length of 32 bits(This length is excluding the length field, and message authentication field), padding 

Step 3:

The server will now send some of the critical information to the client. This information will be playing a major role in the current session of the login.

The information send by the server are as follows.

1. The server will disclose its identity to the client. This identity is a rsa public key of the server. This key is mostly stored in the below location on a server(for this example, i will be working on a centos 5 machine). It is created during the openssh server installation.

[root@slashroot1 ssh]# pwd
/etc/ssh
[root@slashroot1 ssh]# cat ssh_host_rsa_key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAxlwxaB4wKrFHGsqUYEzYtTIJWjgul8ML+bnnJIg0HER1wnW2QitRqDzw6f9cr3WKvwqAQh/Sf4bM0LqUAXZre+J6oiLY7X8V6NtEA8nHO1qryueNe44rI6HYunZ3yo4UAXUZqxhjer+tA8OCD6DLRfXOWIMsBUBXJuB+yl1/qGH2J0Kjrnpj17N0mPMqGmMb8+9EjV1Rs1aSDriIWjDsJIDd8fz4gRoelB5mFsEQ7rD+m/RNWxbAhkBoNcFadRg30LqhCtGYQsWADv0p4THCDVZxB3u9VSWK9qZRgF7LbGRdgiVgJjGDPqCO3cWlnQzxcZ9VdvKy+em1RB9BJ++kuw==

If the client is communicating with the server for the first time. The client will get a warning on his screen which will be something like the below.

[root@slashroot1 ~]# ssh 192.168.0.105
The authenticity of host '192.168.0.105 (192.168.0.105)' can't be established.
RSA key fingerprint is c7:14:f4:85:5f:52:cb:f9:53:56:9d:b3:0c:1e:a3:1f.
Are you sure you want to continue connecting (yes/no)?

The client will get the above warning only when he connects for the first time. After the first connection, this host identity key will be saved in a known_hosts file so that, in future you will not get a warning while connecting to this server.

The thing to understand here is that, the above key is a host identity, and not a user identity. Any client connecting to that server will get that same host-key as a server identity, so that if you connect to another machine, instead of this you will be warned(because the client does not have the identity in its known_host file)

2. The second information provided by the server to the client is the server key. This server key is akey exchanged from server to the client. This method is not used in ssh version 2, which will be discussed later.

This key is also regenerated each and every hour according to the default configuration. Its default size is 768 bits. You can see this in the ssh server configuration file (/etc/ssh/sshd_conf)

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768

3.

8 random bytes which are also called checkbytes. It is necessary for the client to send these bytes in its reply to the server, during its next reply.

4. Finally the server provides all supported encryption, as well as authentication methods.

Step 4:

According to the list of encryption algorithms supported by the server, the client simply creates a random symmetric key and sends that symmetric key to the server.

This symmetric key will be used to encrypt as well as decrypt the whole communication during this session.

The client takes an additional care while sending this session key(symmetric key for this session) to the server, by doing a double encryption. The first encryption is done by the server host key(which was shared by the server during step 3), and the second encryption is done by the server key(which will keep on changing every one hour.)

This double encryption increases the security, because even if somebody has the host private key of the server (/etc/ssh/ssh_host_rsa_key), he will not be able to decrypt the message, because its still encrypted by the server key, which keeps on changing on an hourly basis.

Along with this double encrypted session key, the client will also send the selected algorithm from the list of supported algorithm given by the server during step 3.

Step 4:

According to the list of encryption algorithms supported by the server, the client simply creates a random symmetric key and sends that symmetric key to the server.

This symmetric key will be used to encrypt as well as decrypt the whole communication during this session.

The client takes an additional care while sending this session key(symmetric key for this session) to the server, by doing a double encryption. The first encryption is done by the server host key(which was shared by the server during step 3), and the second encryption is done by the server key(which will keep on changing every one hour.)

This double encryption increases the security, because even if somebody has the host private key of the server (/etc/ssh/ssh_host_rsa_key), he will not be able to decrypt the message, because its still encrypted by the server key, which keeps on changing on an hourly basis.

Along with this double encrypted session key, the client will also send the selected algorithm from the list of supported algorithm given by the server during step 3.

Step 5:

If you notice, the client has still not authenticated the server. It only has the identity of the server, which was given by the server in the form of server host key.

In order to authenticate the server, the client needs to be sure, that the server was able to decrypt the session key send during step 4. So after sending the session key(which is double encrypted with server key and server host key), the client waits for a confirmation message from the server.

The confirmation from the server must be encrypted with the symmetric session key, which the client send. This step of waiting for a confirmation message is very important for the client, because the client has no other way to verify whether the server host key send, was from the intended server.

Once the client receives a confirmation from the server, both of them can now start the communication with this symmetric encryption key.

But till now only the server is authenticated. The client is yet to be authenticated by the server.

Client Authentication methods supported by SSH

Now the complete communication will be in a symmetric encrypted form, with the help of the session key.

The client authentication happens over this encrypted channel. There are multiple methods that can be used to authenticate the client. Some of them are mentioned below.

• Public Key

• Rhosts

• Password

• Kerberos

Related : Kerberos and its Working

We will only be discussing the two most commonly used methods here. Passwords & public key method of authentication.

Password authentication

Password based authentication is simple, and is the most commonly used authentication methods in ssh. It is exactly the same as you log in to a local user using the correct password. The remote server on getting the passwords, logs in the user, based on the server's native password authentication mechanism.

Note the fact that the password transmitted by the client to the server is encrypted through the session symmetric key(which only the server and the client knows)

Public Key Authentication

The second authentication method is public key authentication method. Public key authentication in secure shell is the strongest authentication methods, that can be used to authenticate the client.

For this authentication to work, the client first needs to create an RSA public and private key. Which can be done by a command called ssh-keygen. Always keep in mind, that this key generation is only used for authenticating the client, and not used for encrypting the complete session. Encryption of the complete ssh session is already established by a symmetric session key which was previously shared by the client and the server.

Let's see what happens in this public key authentication. We will first need to create two keys(One private and one public). This public key will be given to all those server's where your require authentication. So a client that needs log-in to multiple servers using public key, needs to distribute his key to those multiple servers first. Any data encrypted with that public key, can only be decrypted with the corresponding private key(which is only with the original client.)

[root@slashroot1 ~]# cd .ssh/
[root@slashroot1 .ssh]# ll -a
total 16
drwx------ 2 root root 4096 Feb 25 14:19 .
drwxr-x--- 9 root root 4096 Feb 25 09:58 ..
-rw-r--r-- 1 root root    0 Feb 25 14:08 known_hosts
[root@slashroot1 .ssh]#

The above shown directory of .ssh (which is a directory that contains the user specific ssh details. Its inside the home directory of the user.).

As of now the directory only has one file called known_hosts. This is the file which will contain the complete list of server host keys line by line. We have previously seen that when a user connects to an ssh server for the first time, the user will get a warning of the server host key(because the client does not have the entry of the server host key in the file, which proves the server identity).

After the first connection the server host key is saved in the file known_hosts, so that when you connect again you will not get a warning(this warning is very much helpful, because it will let you know if you are logging into an attacker's machine instead of the original server).

This will be the location(~/.ssh), where the keys for public key authentication will be saved. Lets create our keys for this authentication.

[root@slashroot1 ~]# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
47:b0:9a:e5:7f:ca:df:ca:aa:20:4e:68:2d:ed:dc:a5 root@slashroot1.slashroot.in
[root@slashroot1 ~]#

Keep in mind that anything that is encrypted with the public key(id_rsa.pub), can only be decrypted with the corresponding private key (which in our case is id_rsa)If you see clearly the above command, has created two files in the .ssh directory. One is the private key (id_rsa) which will by default have a permission of 600, and the other is the public key, which will be shared to the server(id_rsa.pub)

Now let's share this id_rsa.pub, with the server. The server will keep this public key inside its list of authorized hosts. Sharing this public key does not mean sharing the file id_rsa.pub. Sharing means the content of the file id_rsa.pub, must be there in the file authorized_keys on the server. This authorized hosts file is also located in the directory .ssh inside the home directory of the target user.

Let's get back to the point where we stopped at step 5.

From the list of authentication method's supported by the server, the client will select a public key authentication and will also send the the details about the cryptography used for this public key authentication.

The server on receiving the public key authentication request, will first generate a random 256 bit string as a challenge for the client, and encrypt it with the client public key, which is inside theauthorized_keys file. 

The client on receiving the challenge, will decrypt it with the private key(id_rsa). The client will not send the challenge string as it is. But will combine that string with the session key(which was previously negotiated and is being used for symmetric encryption.) And will generate a md5 hash value. This hash value is send to the server. The server on receiving the hash, will regenerate it(because the server also has both the random string as well as the session key), and if it matches the hash send by the client, the client authentication succeeds.

Now let's get inside SSH protocol version 2.

SSH Protocol Version 2

SSH protocol version 2 is the default protocol used these days. This is due to some major advancements in version 2 compared to version 1. The workflow of the ssh login is almost same as that of version 1, however there are some major changes done in the protocol level. Some of these changes include improved encryption standards, Public key certification, much better message authentication codes, reassignment of session key etc.

If you are using centos/rhel 5 like me, most of you might be using openssh version 4.3 or higher. These ssh client's, by default selects ssh protocol version 2 for login, and it will fallback to version 1 if the server does not support version 2.

Multiple functions like key exchange, authentication, encryption were all part of a single protocol in version 1, due to which it is sometimes called as monolithic. SSH version 2 implements these different functions in different protocol(which combines together to make protocol version 2). Let's see these different internal protocol's inside ssh version 2.

• Transport Layer Protocol
• Connection protocol
• Authentication Protocol

​The above three protocol's inside ssh version 2 is defined in seperate RFC's. 

SSH version 1 is very much limited in its support for wide range of algorithms that can be used for session key exchange, message authentication codes, compression algorithms etc. SSH 2 gives pretty good number of choices for the client to select from. SSH version 2 even has a space for adding your own custom algorithm. 

During our discussion regarding session key (which is the symmetric key used for encrypting the complete session ), we saw that the client after selecting one algorithm from the list of supported by the server, generates a symmetric key and sends it to the server with double encryption(first encryption with the server host key and then with the server key, which keeps on changing every hour). In ssh version 2, there is no concept of server key. Instead it the server provides with the list of supported key exchange methods, from which the client selects one. As of now ssh version 2 works on diffie-hellmangroup1-sha1 for exchanging keys. I will recommend reading the below article of Wikipedia, to get an idea about diffie-hellmangroup1-sha1.

Read: diffie-hellman key exchange method

The basic idea behind this change is that no single party(client or the server), should decide the session key. All the supported key exchange algorithm that will be added in the future, will consist this property(nieigther server nor the client can dictate the session key)

So there is no concept of server key (which is altered every hour) in ssh version 2.  

The second major change in SSH version 2 is the inclusion of a concept called as certificate authority(CA), who will sign the public key's used in the communication. This is exactly the same method used in SSL. However this is never implemented in real world as of now. But the protocol has already a room made for this. 

Message authentication code's are used in any secure communication to verify the integrity of the message. Even SSH version 1 uses a message authentication code called as CRC-32(Cyclic Redundancy Check). CRC although does check alteration in data, but is not considered best when security is a major concern. SSH 2 uses advanced encryption standard based MAC. Some of the supported ssh 2 message authentication codes are as below.

1. hmac-md5
2. hmac-sha1
3. ​hmac-ripemd160

Rekeying of session key

SSH includes an added functionality called as rekying of the session key. What happens is, previously in ssh version 1, only one session key was used for the entire session. These days, almost all activities are carried out by ssh session. I myself login to a remote server, and leave that session as it is for weeks together, to continue from where i left.

In such login ssh session's its better to change the session key without breaking the session. That's a feature in ssh version 2. 

let's now have a summary of the differences between ssh version 1 and ssh version 2

• Diffie-Hellman key is used instead of the server key for sharing the session key in version 2 protocol
• No Rhosts support in ssh 2
• SSH protocol version 1 only allows negotiation of the symmetric encryption algorithm, all other things are hard corded(mac, compression etc)
• SSH 2 supports certificates for public keys used
• SSH 2 server can dictate the client to use multiple authentication methods in a single session to succeed. However ssh version 1 only supports one method per session
• SSH version 2 allows the change of session key periodically.

Hope the above article was helpful in understanding the workflow of ssh. And the differences between two version's of SSH.

출처 - https://www.slashroot.in/secure-shell-how-does-ssh-work

1. SSO(Single Sign-On)의 정의

: 하나의 아이디로 여러 정보시스템에 접근할 수 있는 통합 로그인 솔루션(ex. 패밀리 사이트의 회원가입)

2. SSO의 등장배경

- 기술적 측면 : 기업 내 다양한 정보시스템의 구축에 따른 복잡성 증가

                     PKI, 생체인식 등 다양한 인증 기술의 활성화

- 관리적 측면 : 중앙 관리를 통한 업무 단순화 및 표준화 실현

                     중앙 집중적인 사용자 관리를 통한 보안 기능 강화

3. SSO의 구성요소

- 사용자 통합 로그인

- 인증 서버

- 통합 에이전트 : 각 정보시스템에 대한 인증 정보 관리

- LDAP : 네트워크 상의 자원을 식별하고, 인가된 사용자만  접근할 수 있도록 하는

             네트워크 디렉토리 서비스(Lightweight Directory Access Protocol)

4. SSO의 기술요소

- 인증 : PKI(Public Key Infrastructure), 생체인식, OTP(One Time Password)

- 관리 : LDAP(Lightweight Directory Access Protocol), 쿠키(Cookie)

- 암호화 통신 : SSL(Secure Socket Layer), IPSec(IP Security Protocol)

 * 각 기술요소를 클릭하시면 보다 자세한 정보를 보실 수 있습니다.

5. SSO 구축 유형

① 인증 대행 모델(Delegation)

- 인증 방식을 변경하기 어려울 경우, 많이 사용

- 시스템 접근 시, 통합 Agent가 인증 작업을 대행

② 인증 정보 전달 모델(Propagation)

- 웹 기반의 시스템에서 주로 사용

- 미리 인증된 토큰(Cookie 기능 이용)을 받아서 각 시스템 접근 시, 자동으로 전달

6. Cookie를 이용한 SSO구현 시, Cookie 보안 방법

- Data Confidentiality : 토큰은 주요 암호 알고리즘(AES, SEED)과 128bit 이상의 키로 암호화 되어야 함

- Data Integrity : 토큰은 MAC 등을 포함해 데이터의 무결성을 보장해야 함

- Replay Attack Protection : 사용자 주소 제한이나 유효시간 제한 같은 보안 기술을 사용하여, 토큰을

  네트워크에 노출시키지 않아야 함

http://blog.naver.com/xcripts?Redirect=Log&logNo=70121445000

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

** SSO와 세션 클러스터링 의미비교

Single Sign On(통합인증)을 "하나의 아이디/패스워드로 여러 어플리케이션에 접근할 수 있도록 관리하는 
통합시스템"을 의미하는 개념적인 층위의 용어라고 할 때, 자바에서의 세션 클러스터링은 이를 구체화한 실제 방법론중의 하나, 즉 SSO의 하위개념으로 해석할 수 있을 듯 합니다.

또한, 자바 세션 클러스터링은 일반적 SSO의 기능인 사용자의 로그인 여부 판별과 고유 아이디 인증을 넘어서,단일 어플리케이션 상황에서와 마찬가지의 세션 스코프 유지를, 별개의 어플리케이션 또은 물리서버 사이에서도가능하도록 하는 데에 초점이 맞춰져 있는 논제같습니다. 
즉, 다수의 어플리케이션간에 세션 스코프를 연결하고, 스코프에 저장되는 자바 오브젝트들의 상태를 유지할 수 있도록 보장하는 것입니다.

** A,B,C,D 서버가 있다고 할 때의 일반적인 SSO 구현방식

** 1. 
사용자가 로그인을 성공할 경우 로그인 처리 페이지가 A,B,C,D 서버에 있는 각각의 loginok.jsp 페이지를 
IFRAME을 통해 동시에 호출합니다. 
이때, A,B,C,D 서버의 loginok.jsp 페이지는 해당 브라우저 사용자에 대해 로그인 처리를 하고, Requset에 담겨온 loginid를 이용해서 세션에 사용자정보를 담습니다. 로그아웃도 마찬가지로 처리합니다. 
4개의 세션이 별개로 생기는 셈이지만, 이는 모두 공통된 하나의 브라우저에 대응하므로, 브라우저가 
종료되면 동시에 소멸됩니다. 
세션간의 연동(객체 전달같은)은 불가능하지만, 하나의 브라우저에 대해서 각각의 어플리케이션이 
동일한 인증상태를 유지하고 있고, 각각의 세션에 저장된 사용자 정보가 동일한 것이라는 무결성을 
획득할 수 있습니다. 
  
** 2. 
쿠키를 이용하는 방법 (가장 대중적, 메인 도메인이 같을 때) 
로그인하면, 고유의 키를 만들어 쿠키에 저장합니다. 각각의 사이트에서는 쿠키에 담긴 이 키값의 여부로, 로그인 여부를 판단하고 세션을 생성하며 키값에 따른 고유한 사용자 정보를 뽑아와 세션에 저장합니다. 
로그아웃시에는 쿠키를 지워줍니다.

** 3. 
하나의 서버에서 인증처리를 전담하는 방법 
로그인과 세션을 관리하는 A서버의 a페이지를, 통합인증이 필요한 모든 페이지에서 프레임으로 포함하고, 
처리에 필요한 사용자정보를 여기에 요청, 응답받습니다. a페이지는 XMLHttpRequest를 이용 페이지 갱신없이 A서버의 다른 프로그램을 호출하고 응답을 얻어옵니다.

- 시나리오 
1. 메인프레임에서 로그인프레임에 로그인여부 질의 top.loginFrame.getIsLogin(); 
2. 로그인 프레임의 a페이지는 응답받을 메인프레임의 함수를 이벤트로 등록후 서버측에 요청을 보냅니다.
   sendRequest("./isLogin.jsp","data","top.mainFrame.isLogin"); 
3. 요청받은 서버는 세션을 참조하여 로그인 여부 판단, XMLHttpRequest에 응답합니다. 
4. 서버에서의 응답값을 매개변수로 top.mainFrame.isLogin(isLogin); 이 실행됩니다.

일반적인 방법은 아닙니다.

** 4. 
세션 클러스터링을 이용한 방법 
고유한 키값을 쿠키나 기타 장소에 보관하고, 별개의 서버 프로그램과 소켓으로 통신하여 키값에 대해 배당된 컬렉션에서, 직렬화된 자바객체를 꺼내오거나 혹은 저장하며 그 상태를 유지시키는 방법입니다. 키값(연결)이 유지되는 한, 저장소내의 동일한 객체에 접근할 수 있다는 보장을 만들어줍니다. 즉, 통합 인증보다는, 인증 후의 데이터 공유에 촛점이 맞춰져 있는 것 같습니다.

** 5. 
통합인증 솔루션 사용  

출처 - http://devsik.tistory.com/53

능력이 있으면 가지고 있는 능력만큼 할 수 있는 일이 많기도 하지만 그 만큼 할 수 있는 일에 대한 책임과 제약이 따르기도 한다. 호텔에서 ‘마스터 키’를 가지고 있는 사람은 어느 방이든지 열어볼 수는 있지만 아무 방이나 들어가 볼 수는 없다. 설사 발을 들여 놓는다고 해도 위험부담이 너무 클 것이다.

인터넷 세상에서도 ‘개인정보보호’라는 다소 막중한 책임을 가진 마스터 키가 나왔다. 한 번의 로그인으로 여러 사이트를 넘나들 수 있는 싱글 사인 온(single-sign-on)이 그것이다.

호텔에서의 ‘마스터 키’가 호텔 내의 모든 방(실제 투숙자가 누구이든 간에)을 열 수 있는 열쇠라면, 싱글 사인 온은 전세계 호텔들에 산재해 있는 내 방들을 모두 열 수 있는 열쇠라고나 할까?

지난 해 한국전자통신연구원(ETRI)이 자체적으로 개발한 싱글 사인 온(single-sign-on)기술이 ‘SAML(보안주장표현언어) 버전 2.0 상호운용성 국제 표준 테스트’를 통과했다. ‘SAML 버전 2.0’은 싱글 사인 온(SSO) 및 ID 연동 기능을 지원하는 국제 표준 규격이며 이전 버전에 비해 익명성, 식별자 관리, 모바일 장비 지원, 프라이버시 보호 기능 등이 추가됐다. 

이로써 인터넷 사용자는 매번 ID를 입력하는 불편을 해소할 수 있고, 기업 역시 중앙집중적인 관리가 가능해 ID관리 비용을 줄일 수 있게 됐다. 싱글 사인 온의 장점이 부각되면서 다음커뮤니케이션과 CJ인터넷의 넷마블의 검색 및 게임 플랫폼 공유라는 것을 시작으로 전국적인 지사를 갖춘 행정기관, 금융기관도 잇따라 싱글 사인 온을 도입하고 있다. 

싱글 사인 온이 통용화된다면 손가락들은 수고를 좀 덜지 모르겠다. 하지만 개인정보 유출이다 도난이다 하는 뉴스가 이어지고 있는 요즘, 100% 웹사이트를 신뢰하면서 내 개인정보를 한 군데 저장해 두고 인터넷 바다를 헤엄치기에는 미심쩍은 부분이 많다. ‘프라이버시 보호’는 싱글 사인 온이 가져야 할 가장 막중한 임무가 아닌가 싶다. 싱글 사인 온이 인터넷 사용자들의 편의를 위하여 고안된 것이니만큼 진정으로 개개인의 사생활을 보호하는 책임 있는 마스터 키로써의 역할을 충실히 해줬으면 하는 바람이다.

- 출처 " 영삼성 "

관련기사 " 소프트포럼, ID관리 솔루션 대전시청 공급 " - 스탁데일리

관련기사 " 로그인 한번에 모든 사이트 이용 " - 서울경제

출처 - http://devsik.tistory.com/51