스프링 시큐리티와 OAuth

2010.12.4고종봉

발표 개요

발표의 목적 스프링 시큐리티 학습 내용 공유 최근 OAuth 관심 증대 / 학습 내용 공유 KSUG 세미나 스프링 시큐리티 발표내용 보충

발표의 목표 스프링 시큐리티 이해 스프링 시큐리티 구현 & 분석 OAuth 이해 스프링 시큐리티 OAuth 구현 & 분석

발표 순서

스프링 시큐리티

스프링 시큐리티 구현 & 분석

OAuth 소개 & 시나리오 & 데모

스프링 시큐리티 OAuth 구현 & 분석

스프링 시큐리티

시큐리티 핵심 개념

• 인증 (Authentication)▪ 자신이 누구라고 주장하는 사람의 주체 (principal, " 주

체 " 는 보통 사용자를 의미하며 , 애플리케이션을 사용하는 장비나 시스템이 될 수도 있다 ) 를 확증하는 절차

• 인가 (Authorization)▪ 주체가 해당 애플리케이션 기능을 사용할 수 있도록

허용되었는지를 결정하는 프로세스▪ 주체의 신원이 인증을 거쳐 이미 확증되어 있어야 한다

< 군사제한구역 >

진입

누구냐 !

진입

통과 !

< 군사통제구역 >

진입

통과 !

인증(Authentication) 진입

권한없음 !

인가(Authorization)

Ex) 군사보안

스프링 시큐리티

스프링 시큐리티▪ J2EE- 기반 엔터프라이즈 소프트웨어 애플리케이션을 위한 종합적인

보안 서비스를 제공

http://static.springsource.org/spring-security/site/index.html

스프링 시큐리티 주요 구성요소

• Security Interceptor ( 보안검사자 )▪ 권한 확인이 필요한 지점에서 요청에 대한 인증 및 인가를

검사한다

• Authentication Manager ( 인증담당자 )▪ 사용자 정보 (UserDetails) 의 목록에서 주체 (Principal)

의 신원증명 (Credentials) 이 일치하는지 검사한다

• Authorization Manager ( 인가담당자 )▪ 주체가 해당 요청에 대하여 부여된 권한 (Granted Author-

ity) 을 가지고 있는지 검사한다

< 군사제한구역 >

진입

누구냐 !

진입

통과 !

< 군사통제구역 >

< 보안본부 >

진입

통과 !

진입

권한없음 !

보안검사자

인증담당자

보안검사자

인가담당자

인증요청 인가요청

인증 인가

Ex) 군사보안

SecurityContextPersistenceFilter

LogoutFilter

UsernamePasswor-dAuthenticationFilter

DefaultLoginPageGeneratingFilter

BasicAuthenticationFilter

RequestCacheAwareFilter

SecurityContextHolderAwareRequestFilter

AnonymousAuthenticationFilter

SessionManagementFilter

ExceptionTranslationFilter

FilterSecurityInterceptor

AffirmativeBased

AccessDecisionManager

SecurityContextImpl

HttpSessionSecurity-ContextRepository

SecurityContext

SecurityContextRepository

UsernamePasswordAuthenticationToken

Authentication

ProviderManager

AuthenticationManager

AuthenticationProvider

InMemoryDaoImpl

UserDetailsService

DaoAuthenticationProvider

GrantedAuthorityImpl

User

UserDetails

GrantedAuthority

스프링 시큐리티 아키텍처

request

Servlet/JSP

DelegatingFilterProxy

FilterChainProxy

web.xml

스프링 시큐리티 구현 & 분석

OAuth 소개

Case

고급 외제차를 타고 와서 발렛 서비스를 맡긴다 . 발렛 직원에게 별도의 키를 전해주는데 , 이 키로는 잠시 동안의 차량 운행만 가능하며 ,

트렁크나 차량용 휴대폰을 조작할 수는 없다 . 이 키는 용도가 제한적이지만 , 발렛에는 안성맞춤이다 .

Transport Layer

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

OAuth ?

웹이 발달함에 따라 , 수 많은 사이트에서 분산 서비스와 클라우드 컴퓨팅을 활용하고 있다 . 서드파티 애플리케이션으로 , Flickr 에서 사진을 가져와 출력하거나 , Google 주소록에서 친구들을 찾기 위해 다양한 서비스 API 를 활용할 수 있다 .

OAuth 는 , 이러한 API 들을 사용하기 위해 , 사용자 비밀번호를 공유하지 않고도 서드파티에게 사용자의 제한된 자원에 접근할 수 있도록 허가해주는 보안 프로토콜이다 .

Transport Layer

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

OAuth History

2006 년 OpenID 구현을 위해 처음 개발되었으며 , API 접근 허용 방식에 대한 오픈 표준이 필요함에 따라 , 2007 년 OAuth Core 1.0 초안이 완성 .

2010 년 4 월 OAuth 1.0 프로토콜이 RFC 5849 로 정식 발행 (publish) 되었으며 , 트위터 애플리케이션이 OAuth 1.0 을 사용하도록 지원함 .

OAuth 2.0 은 클라이언트 개발자가 좀더 단순하게 권한을 얻을 수 있도록 하는데 초점을 맞추어 개발되고 있으며 , 규격서 작성이 현재 진행 중임 .

Transport Layer

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

OAuth 시나리오

시나리오제인 (Jane)은 휴가 여행으로 스코틀랜드에 다녀왔다 . 2주간의 여행 기간 동안 스코틀랜드의 풍경을 촬영했다 . 집으로 돌아온 제인은 사진 중 일부를 친구들과 공유하기 위해 이미지 공유 사이트인 Faji에

로그인하여 개인 계정으로 사진 이미지를 업로드 하였다 .

Transport Layer

http://oauth.net http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-ii-protocol-workflow/

시나리오친구들과 온라인으로 사진을 공유한 제인은 , 그 사진들을 그녀의 할머니에게도

보여주고 싶어졌다 . 제인의 할머니는 인터넷을 사용할 줄 모르기 때문에 , 제인은 그 사진들을 인화해서 우편으로 보내드려야겠다고 생각했다 . 그래서 평소 즐겨 애용하던 사진 인화 사이트인 Beppa 에 접속을 한다 .

Beppa 는 여러 이미지 공유 사이트와 연동이 되므로 , 제인은 beppa.com 에 접속해서 인화 주문을 하고 , Faji 로부터 이미지를 가져오도록 선택한다 .

Transport Layer

시나리오제인이 Faji 로부터 이미지를 가져오도록 선택하자 , Beppa 는 Faji 에 제인의 이미지를

가져가길 원한다는 요청을 한다 . 그리고 인증을 위해 제인의 브라우저 화면을 Faji의 인증 페이지로 redirect 한다 .

Transport Layer

시나리오제인이 사용자 인증 정보를 입력하고 확인을 누르자 , Faji 가 “ Beppa 가 제인의 개인

계정 데이터를 사용하고자 하는데 승낙할 것인지”를 물어보게 된다 . 제인이 개인 계정의 데이터를 사용할 수 있도록 승낙하면 , 다시 Beppa 사이트로 re-

direct 되어 “사진 전송이 진행 중”이라는 화면이 나타난다 .

Transport Layer

시나리오Beppa 는 제인이 Faji 에 인증한 결과로 , Faji 로부터 제인의 개인 데이터에 접근 할

수 있는 권한을 받아 제인의 사진 이미지를 얻어온 후 , 출력을 계속 진행한다 .

Transport Layer

용어 정의

서비스 제공자 (Provider) – OAuth 의 서버 역할을 하며 , Request Token, Access Token 을 발급하고 , 사용자의 인증 / 인가를 수행한다 .

서비스 소비자 (Consumer) – OAuth 의 클라이언트 역할을 하며 , 사용자 인증을 중개하여 Request Token 과 Access Token 을 발급받아 사용한다 .

사용자 (User) – 서비스에 가입되어 서비스를 사용하는 주체이다 . 브라우저를 통해 서비스 소비자 및 제공자 사이트에 접속하여 인증 정보를 입력하고 , 원하는 서비스를 사용한다 .

보호 자원 (Protected Resources) – 해당 사용자의 개인 데이터로 , 인가 받지 않은 외부 사용자가 접근할 수 없도록 보호해야 할 자원이다 .

토큰 (Token) – 사용자의 신원 (credential) 을 대신하여 , 보호 자원에 접근 하는 데 사용된다 . Request Token 과 Access To-ken 이 있다 .

Process Flow

Transport Layer

인화 요청 get REQUEST_TOKEN (consumer-key, -secret, callback url)

return REQUEST_TOKENredirect: authorize (request_token)

authenticate(security)

authorize (request_token)

redirect: CALLBACK URL(request_token, verifier)CALLBACK URL

(request_token, verifier)get ACCESS_TOKEN (request_token, verifier)

return ACCESS_TOKEN, SECRET

get PROTECTED_RESOURCES(access_token, secret)

return PROTECTED_RESOURCES

결과 화면

OAuth References

• OAuth Community Site http://oauth.net/

Beginner’s Guide to OAuth http://hueniverse.com/oauth/

IETF Specification RFC 5849: The OAuth 1.0 Protocol

▪ http://tools.ietf.org/html/rfc5849 RFC 5849: The OAuth 2.0 Protocol (draft)

▪ http://tools.ietf.org/html/draft-ietf-oauth-v2-10

데모 시연

Tonr & Sparklr

Tonr – Service Consumer (=beppa)Sparklr – Service Provider (=faji)

Transport Layer

Tonr Sparklr

스프링 시큐리티 OAuth

Spring-Security-OAuth

http://spring-security-oauth.codehaus.org/

http://static.springsource.org/spring-security/oauth/index.html

Consumer & Provider 구현

Transport Layer

Spring SecurityOAuth (Provider)

Spring SecurityOAuth (Consumer)

Consumer

Provider

스프링 시큐리티 OAuth 구현 &분석

OAuth 2.0

OAuth 1.0 은 Flickr API 나 Google 의 AuthSub 등에 주로 사용되었으며 , 인증 및 서명 절차의 복잡성 , 토큰 발행에 대한 사용자 경험 불일치 , 처리 성능 등으로 개선의 필요성이 요구되었다 .

Access token 을 발급 받는 주체는 크게 웹 기반 애플리케이션 , 데스크탑 애플리케이션 , 모바일 또는 소형기기 등으로 구분할 수 있다 . 최초의 OAuth 는 이 기반들을 모두 수용하도록 설계되었으나 , 표준 규격서로 작성되면서 웹 기반의 애플리케이션에서만 사용 가능한 것처럼 보여지게 되었다 .

OAuth 2.0 은 OAuth 1.0 보다 절차를 간소화시킨 것이며 , OAuth 1.0 프로토콜과 호환되지는 않지만 , 동작방식에 있어서는 크게 다르지 않다 .

OAuth 2.0 은 현재 IETF OAuth 워킹 그룹에 의해 개발이 진행중이며 , 최종 단계의 초안이 안정화 버전으로 여겨지기는 하지만 여전히 많은 특징들이 수정되고 추가되고 있다 . OAuth 2.0 의 일부 기능들은 이미 페이스북이나 트위터에 적용되고 있으며 , 최종 규격서는 올해 연말쯤 발표될 예정이다 .

감사합니다 !!!