linuxism

지난 번에 SSO(싱글사인온)에 대하여 알아보았습니다. 오늘은 SSO(싱글사인온)에 대해 좀 더 구체적으로 SSO의 이슈, SSO의 개념의 배경, SSO 구현 방식을 알아보겠습니다.

지난번에도 얘기했듯이 SSO(싱글 사인 온)는 한번의 로그인으로 다양한 시스템 혹은 인터넷 서비스를 사용할 수 있게 해주는 보안 솔루션입니당~ 이 SSO를 사용할 경우 인증 절차를 거치지 않고도 1개의 계정만으로 다양한 시스템 및 서비스에 접속할 수 있어 사용자 편의성과 관리비용을 절감할 수 있습니다.

★ 그렇다면 SSO(싱글사인온)의 이슈는 무엇일까요?

   SSO의 이슈는 크게 3가지가 있습니다.(물론 이슈의 중심에는 보안이 있어야 함)

   1. 여러 USER의 DB를 어떤 방식으로 통합할 것인가?

   2. 어떤 인증 방식을 통해 USER를 확인할 것인가?

   3. 인증받은 USER는 어떤 접근 권한을 가지며 그 접근 권한에 따른 개인화는 어떻게 구현할 것인

      가?

 ★ 또한 이러한 SSO란 개념이 필요하게 된 이유 및 도입효과

     쉽게 설명하자면 예를들어 A라는 게임 포탈사이트는 게임 흥행의 성공으로 User가 폭발적으로 추

     가 되었고, 그에따라 UserDB(사용자데이터베이스)는 증가 되어야만 했습니다.기타 관리 서버등

     의 증설도 불가피하게 되었지요.거기에 사업 확장에 따른  B포털사이트와의 전략적 제휴까지 맺

     게 되어 A와B라는 포탈은 성격은 다르지만 A,B어느쪽의 유저라도 A와 B의 서비스를 부분적으로

     이용가능 하게 되었습니다.

     이렇게 시스템의 규모가 커질 수록  시스템의 구조는 더욱 복잡해지고 관리하기는 더욱 힘들게 될

     것입니다. 전문가가 아니라면 그 복잡한 구조를 이해하는 데, 더 어려움이 생길뿐만 아니라, 문제

     가 발생했을때 그 문제를 처리하는 과정에서도 더 많은 시간과 노력을 초래하게 만듭니다. 그렇기

     때문에 관리를 쉽게하고 비용을 절감할 수 있는 솔루션의 필요성을 느끼게 되었고 SSO이란 하나

    의 솔루션이 등장한 것입니다.

     또한 SSO(싱글사인온)의 도입효과로

     관리의 투명성과 신뢰성을 높이고 비용을 절감하고 효율성을 높일수 있습니다.

            – 사용자 ID/Password 관리 효율 증가

 ★ SSO 인증 방식엔 무엇이 있을까요?

   중앙 인증 서버과 서비스 제공자간 인증 절차 방식은 사이트 운영 방식에 따라 3가지 인증방식을 지

   원한다. 운영 방식은 통합 인증 저장소의 유무, 통합 로그인 페이지의 유무, 개별 인증 저장소의 유

   무에 따라 나뉘어 집니다.

   1. 기본 인증방식

기본 인증방식의 사용은 주로 신규로 시스템을 구축하는 경우나 사용자 정보를 통합하는 경우에 많

이 사용된다. 따라서 통합 인증 정보 및 통합 로그인 페이지를 중앙 인증 서버에 포함되어 있다.

<기본 인증 방식 사용시 로그인 프로세스>

   2. ID Federation 인증방식

ID Federation 방식은 서비스 제공자별로 인증정보 관리 서버가 존재 하여 기존 사용중인 사용자 정

보를 그대로 이용하기 위해 사용한다. 따라서 통합 인증정보 관리 서버에는 통합 인증정보는 존재

하지 않는다. 다만 로그인 여부를 중앙 관리하기 위해 로그인 여부를 알 수 있는 인증 정보 Map를

가지고 있다.

<ID Federation 방식을 사용할 때의 로그인 프로세스>

   3. Assertion 인증방식

 Assertion 방식은 기존 서비스 제공자에 사용중인 인증정보와 통합 인증정보를 같이 사용할 경우

 에 적합한 방식이다. Assertion 방식은 로그인 페이지를 서비스 제공자에서 가지고 있으며 서비

 스  제공자에서 로그인 처리 후 중앙 인증 서버로 강제 로그인 처리를 한다. 인증 정보가 공존하므

 로 인증정보 동기화 작업도 필요하다.

<Assertion 방식을 사용할 경우 로그인 처리 프로세스>

출처 - http://blog.naver.com/tomatosoft/140139958084

fedora 에서 josso 설치

* 다운로드한 jar 파일 실행

# java -jar josso-ce.2.3.0-unix.jar

* 설치 화면에서 디폴트 값으로 설치

기존 mediaType설정이 deprecated되었다.

단순히 for문으로 처리되던 기존 viewResolver 결정 프로세스가 바뀌기를 고대했었는데 이제사 좀더 디테일하게 변경이 가능해졌다.

ContentNegotiationStrategy가 추가되었는데 이를 통해

확장자 기준, 헤더값 기준 결정이나 고정된 mediaType리턴과 같은 전략적인 설정이 가능하게 되었다.

이에 따라서 기존의 단순한 for문형태의 viewResolver결정 부분을 비슷하게 구현하려면 아래처럼 구현을 해준다.

	ContentNegotiatingViewResolver viewResolver = new ContentNegotiatingViewResolver(); // 확장자 기준 결정 Map<String, MediaType> mediaTypes = new HashMap<String, MediaType>(); mediaTypes.put("html", MediaType.TEXT_HTML); mediaTypes.put("json", MediaType.APPLICATION_JSON); ContentNegotiationStrategy pathExtensionContentNegotiationStrategy = new PathExtensionContentNegotiationStrategy(mediaTypes); // 헤더값 기준 결정 ContentNegotiationStrategy  headerContentNegotiationStrategy = new HeaderContentNegotiationStrategy(); /* order에 따라 우선순위 결정되므로 순서 주의 */ ContentNegotiationManager contentNegotiationManager = new ContentNegotiationManager(pathExtensionContentNegotiationStrategy, headerContentNegotiationStrategy); viewResolver.setContentNegotiationManager(contentNegotiationManager);

참조 http://richardadams606blog.blogspot.kr/2013_01_01_archive.html

출처 - http://blog.naver.com/PostView.nhn?blogId=luversof&logNo=50162197798