스프링 시큐리티와 OAuth_1202(제출용)
Download
Report
Transcript 스프링 시큐리티와 OAuth_1202(제출용)
2010.12.4
고종봉
발표의 목적
스프링 시큐리티 학습 내용 공유
최근 OAuth 관심 증대 / 학습 내용 공유
KSUG 세미나 스프링 시큐리티 발표내용 보충
발표의 목표
스프링 시큐리티 이해
스프링 시큐리티 구현&분석
OAuth 이해
스프링 시큐리티 OAuth 구현&분석
스프링 시큐리티
스프링 시큐리티 구현&분석
OAuth 소개&시나리오&데모
스프링 시큐리티 OAuth 구현&분석
• 인증(Authentication)
▪ 자신이 누구라고 주장하는 사람의 주체(principal, "주
체"는 보통 사용자를 의미하며, 애플리케이션을 사용
하는 장비나 시스템이 될 수도 있다)를 확증하는 절차
• 인가(Authorization)
▪ 주체가 해당 애플리케이션 기능을 사용할 수 있도록
허용되었는지를 결정하는 프로세스
▪ 주체의 신원이 인증을 거쳐 이미 확증되어 있어야 한
다
진입
누구냐!
인증
(Authentication)
진입
진입
통과!
인가
(Authorization)
진입
< 군사통제구역 >
통과!
권한없음!
< 군사제한구역 >
스프링 시큐리티
▪ J2EE-기반 엔터프라이즈 소프트웨어 애플리케이션을 위한 종합
적인 보안 서비스를 제공
http://static.springsource.org/spring-security/site/index.html
• Security Interceptor (보안검사자)
▪ 권한 확인이 필요한 지점에서 요청에 대한 인증 및 인
가를 검사한다
• Authentication Manager (인증담당자)
▪ 사용자 정보(UserDetails)의 목록에서 주체(Principal)
의 신원증명(Credentials)이 일치하는지 검사한다
• Authorization Manager (인가담당자)
▪ 주체가 해당 요청에 대하여 부여된 권한(Granted
Authority)을 가지고 있는지 검사한다
진입
누구냐!
진입
통과!
인증
인가
진입
보안검사자
진입
인증요청
보안검사자
권한없음!
인가요청
통과!
인증담당자
< 군사통제구역 >
인가담당자
< 보안본부 >
< 군사제한구역 >
request
web.xml
Delegating
FilterProxy
Servlet/JSP
SecurityContext
PersistenceFilter
SecurityContext
Repository
HttpSessionSecurityC
ontextRepository
LogoutFilter
UsernamePasswordA
uthenticationFilter
FilterChain
DefaultLoginPage
Proxy
GeneratingFilter
BasicAuthentication
Filter
RequestCache
AwareFilter
SecurityContextHolder
AwareRequestFilter
Anonymous
AuthenticationFilter
SessionManagement
Filter
Exception
TranslationFilter
FilterSecurity
Interceptor
SecurityContext
SecurityContext
Impl
Authentication
UsernamePassword
AuthenticationToken
Authentication
Provider
Authentication
Manager
ProviderManager
DaoAuthentication
Provider
UserDetailsService
InMemoryDaoImpl
AccessDecision
Manager
AffirmativeBased
UserDetails
User
Granted
Authority
Granted
AuthorityImpl
고급 외제차를 타고 와서 발렛 서비스를 맡긴다.
발렛 직원에게 별도의 키를 전해주는데, 이 키로는 잠시 동안의 차량 운행만 가능
하며, 트렁크나 차량용 휴대폰을 조작할 수는 없다.
이 키는 용도가 제한적이지만, 발렛에는 안성맞춤이다.
http://en.wikipedia.org/wiki/OAuth
Transport
Layer
웹이 발달함에 따라, 수 많은 사이트에서 분산 서비스와 클라우드 컴퓨팅을 활용
하고 있다. 서드파티 애플리케이션으로, Flickr에서 사진을 가져와 출력하거나,
Google 주소록에서 친구들을 찾기 위해 다양한 서비스 API를 활용할 수 있다.
OAuth는, 이러한 API들을 사용하기 위해, 사용자 비밀번호를 공유하지 않고도 서
드파티에게 사용자의 제한된 자원에 접근할 수 있도록 허가해주는 보안 프로토
콜이다.
http://en.wikipedia.org/wiki/OAuth
Transport
Layer
2006년 OpenID 구현을 위해 처음 개발되었으며, API 접근 허용 방식에 대한 오픈
표준이 필요함에 따라, 2007년 OAuth Core 1.0 초안이 완성.
2010년 4월 OAuth 1.0 프로토콜이 RFC 5849로 정식 발행(publish)되었으며, 트위
터 애플리케이션이 OAuth 1.0을 사용하도록 지원함.
OAuth 2.0은 클라이언트 개발자가 좀더 단순하게 권한을 얻을 수 있도록 하는데
초점을 맞추어 개발되고 있으며, 규격서 작성이 현재 진행 중임.
http://en.wikipedia.org/wiki/OAuth
Transport
Layer
제인(Jane)은 휴가 여행으로 스코틀랜드에 다녀왔다.
2주간의 여행 기간 동안 스코틀랜드의 풍경을 촬영했다.
집으로 돌아온 제인은 사진 중 일부를 친구들과 공유하기 위해 이미지 공유 사이
트인 Faji에 로그인하여 개인 계정으로 사진 이미지를 업로드 하였다.
http://oauth.net
http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-ii-protocol-workflow/
Transport
Layer
친구들과 온라인으로 사진을 공유한 제인은, 그 사진들을 그녀의 할머니에게도 보
여주고 싶어졌다. 제인의 할머니는 인터넷을 사용할 줄 모르기 때문에, 제인은
그 사진들을 인화해서 우편으로 보내드려야겠다고 생각했다. 그래서 평소 즐겨
애용하던 사진 인화 사이트인 Beppa에 접속을 한다.
Beppa는 여러 이미지 공유 사이트와 연동이 되므로, 제인은 beppa.com에 접속해
서 인화 주문을 하고, Faji로부터 이미지를 가져오도록 선택한다.
Transport
Layer
제인이 Faji로부터 이미지를 가져오도록 선택하자, Beppa는 Faji에 제인의 이미지
를 가져가길 원한다는 요청을 한다. 그리고 인증을 위해 제인의 브라우저 화면
을 Faji의 인증 페이지로 redirect 한다.
Transport
Layer
제인이 사용자 인증 정보를 입력하고 확인을 누르자, Faji가 “Beppa가 제인의 개인
계정 데이터를 사용하고자 하는데 승낙할 것인지”를 물어보게 된다.
제인이 개인 계정의 데이터를 사용할 수 있도록 승낙하면, 다시 Beppa 사이트로
redirect 되어 “사진 전송이 진행 중”이라는 화면이 나타난다.
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 Token
이 있다.
인화 요청
get REQUEST_TOKEN
(consumer-key, -secret, callback url)
return REQUEST_TOKEN
redirect: authorize (request_token)
authenticate(security)
authorize (request_token)
CALLBACK URL
(request_token, verifier)
redirect: CALLBACK URL
(request_token, verifier)
get ACCESS_TOKEN
(request_token, verifier)
return ACCESS_TOKEN, SECRET
get PROTECTED_RESOURCES
(access_token, secret)
return PROTECTED_RESOURCES
Transport
Layer
결과 화면
• 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 – Service Consumer (=beppa)
Sparklr – Service Provider (=faji)
Tonr
Sparklr
Transport
Layer
http://spring-security-oauth.codehaus.org/
http://static.springsource.org/spring-security/oauth/index.html
Spring Security
OAuth (Provider)
Spring Security
OAuth (Consumer)
Provider
Consumer
Transport
Layer
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의 일부 기능들은 이
미 페이스북이나 트위터에 적용되고 있으며, 최종 규격서는 올해 연
말쯤 발표될 예정이다.