스프링 시큐리티와 OAuth

1. 2010.12.4 고종봉 스프링 시큐리티와OAuth

2. 발표 개요 • 발표의 목적 • 스프링 시큐리티 학습 내용 공유 • 최근 OAuth관심 증대 / 학습 내용 공유 • KSUG 세미나 스프링 시큐리티발표내용 보충 • 발표의 목표 • 스프링 시큐리티 이해 • 스프링 시큐리티 구현&분석 • OAuth이해 • 스프링 시큐리티OAuth구현&분석

3. 발표 순서 • 스프링 시큐리티 • 스프링 시큐리티구현&분석 • OAuth소개&시나리오&데모 • 스프링 시큐리티OAuth구현&분석

4. 스프링 시큐리티

5. 시큐리티핵심 개념 • 인증(Authentication) • 자신이 누구라고 주장하는 사람의 주체(principal, "주체"는 보통 사용자를 의미하며, 애플리케이션을 사용하는 장비나 시스템이 될 수도 있다)를 확증하는 절차 • 인가(Authorization) • 주체가 해당 애플리케이션 기능을 사용할 수 있도록 허용되었는지를 결정하는 프로세스 • 주체의 신원이 인증을 거쳐 이미 확증되어 있어야 한다

6. Ex) 군사보안 < 군사제한구역 > 진입 진입 진입 진입 통과! 통과! 권한없음! 누구냐! < 군사통제구역 > 인가 (Authorization) 인증 (Authentication)

7. 스프링 시큐리티 • 스프링 시큐리티 • J2EE-기반 엔터프라이즈 소프트웨어 애플리케이션을 위한 종합적인 보안 서비스를 제공 • http://static.springsource.org/spring-security/site/index.html

8. 스프링 시큐리티 주요 구성요소 • Security Interceptor (보안검사자) • 권한 확인이 필요한 지점에서 요청에 대한 인증 및 인가를 검사한다 • Authentication Manager (인증담당자) • 사용자 정보(UserDetails)의 목록에서 주체(Principal)의 신원증명(Credentials)이 일치하는지 검사한다 • Authorization Manager (인가담당자) • 주체가 해당 요청에 대하여 부여된 권한(Granted Authority)을 가지고 있는지 검사한다

9. Ex) 군사보안 < 군사제한구역 > 진입 진입 진입 진입 통과! 통과! 권한없음! 누구냐! < 군사통제구역 > 인증 인가 보안검사자 보안검사자 인증요청 < 보안본부 > 인가요청 인증담당자 인가담당자

10. 스프링 시큐리티 아키텍처 request SecurityContext SecurityContextImpl SecurityContextRepository web.xml SecurityContextPersistenceFilter HttpSessionSecurityContextRepository Delegating FilterProxy FilterChain Proxy Authentication LogoutFilter UsernamePasswordAuthenticationToken UsernamePasswordAuthenticationFilter DefaultLoginPageGeneratingFilter Servlet/JSP AuthenticationProvider DaoAuthenticationProvider BasicAuthenticationFilter Authentication Manager ProviderManager RequestCacheAwareFilter UserDetailsService SecurityContextHolderAwareRequestFilter InMemoryDaoImpl Anonymous AuthenticationFilter UserDetails AccessDecision Manager SessionManagementFilter User AffirmativeBased Exception TranslationFilter GrantedAuthority FilterSecurity Interceptor Granted AuthorityImpl

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

12. OAuth소개

13. Case 고급 외제차를 타고 와서 발렛 서비스를 맡긴다. 발렛 직원에게 별도의 키를 전해주는데, 이 키로는 잠시 동안의 차량 운행만 가능하며, 트렁크나 차량용 휴대폰을 조작할 수는 없다. 이 키는 용도가 제한적이지만, 발렛에는 안성맞춤이다. http://en.wikipedia.org/wiki/OAuth Transport Layer

14. OAuth ? 웹이 발달함에 따라, 수 많은 사이트에서 분산 서비스와 클라우드 컴퓨팅을 활용하고 있다. 서드파티 애플리케이션으로, Flickr에서 사진을 가져와 출력하거나, Google 주소록에서 친구들을 찾기 위해 다양한 서비스 API를 활용할 수 있다. OAuth는, 이러한 API들을 사용하기 위해, 사용자 비밀번호를 공유하지 않고도 서드파티에게 사용자의 제한된 자원에 접근할 수 있도록 허가해주는 보안 프로토콜이다. http://en.wikipedia.org/wiki/OAuth Transport Layer

15. OAuth History 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

16. OAuth시나리오

17. 시나리오 제인(Jane)은 휴가 여행으로 스코틀랜드에 다녀왔다. 2주간의 여행 기간 동안 스코틀랜드의 풍경을 촬영했다. 집으로 돌아온 제인은 사진 중 일부를 친구들과 공유하기 위해 이미지 공유 사이트인 Faji에 로그인하여 개인 계정으로 사진 이미지를 업로드 하였다. • http://oauth.net • http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-ii-protocol-workflow/ Transport Layer

18. 시나리오 친구들과 온라인으로 사진을 공유한 제인은, 그 사진들을 그녀의 할머니에게도 보여주고 싶어졌다. 제인의할머니는 인터넷을 사용할 줄 모르기 때문에, 제인은 그 사진들을 인화해서 우편으로 보내드려야겠다고 생각했다. 그래서 평소 즐겨 애용하던 사진 인화 사이트인 Beppa에 접속을 한다. Beppa는 여러 이미지 공유 사이트와 연동이 되므로, 제인은beppa.com에 접속해서 인화 주문을 하고, Faji로부터 이미지를 가져오도록 선택한다. Transport Layer

19. 시나리오 제인이Faji로부터 이미지를 가져오도록 선택하자, Beppa는 Faji에 제인의 이미지를 가져가길 원한다는 요청을 한다. 그리고 인증을 위해 제인의 브라우저 화면을 Faji의 인증 페이지로 redirect 한다. Transport Layer

20. 시나리오 제인이 사용자 인증 정보를 입력하고 확인을 누르자, Faji가 “Beppa가 제인의 개인 계정 데이터를 사용하고자 하는데 승낙할 것인지”를 물어보게 된다. 제인이개인 계정의 데이터를 사용할 수 있도록 승낙하면, 다시 Beppa사이트로 redirect 되어 “사진 전송이 진행 중”이라는 화면이 나타난다. Transport Layer

21. 시나리오 Beppa는 제인이 Faji에 인증한 결과로, Faji로부터 제인의 개인 데이터에 접근 할 수 있는 권한을 받아 제인의 사진 이미지를 얻어온 후, 출력을 계속 진행한다. Transport Layer

22. 용어 정의 • 서비스 제공자(Provider) – OAuth의 서버 역할을 하며, Request Token, Access Token을 발급하고, 사용자의 인증/인가를 수행한다. • 서비스 소비자(Consumer) – OAuth의 클라이언트 역할을 하며, 사용자 인증을 중개하여 Request Token과 Access Token을 발급받아 사용한다. • 사용자(User) – 서비스에 가입되어 서비스를 사용하는 주체이다. 브라우저를 통해 서비스 소비자 및 제공자 사이트에 접속하여 인증 정보를 입력하고, 원하는 서비스를 사용한다. 보호 자원(Protected Resources) – 해당 사용자의 개인 데이터로, 인가 받지 않은 외부 사용자가 접근할 수 없도록 보호해야 할 자원이다. • 토큰(Token) – 사용자의 신원(credential)을 대신하여, 보호 자원에 접근 하는 데 사용된다. Request Token과 Access Token이 있다.

23. Process Flow get REQUEST_TOKEN (consumer-key, -secret, callback url) get PROTECTED_RESOURCES (access_token, secret) get ACCESS_TOKEN (request_token, verifier) CALLBACK URL (request_token, verifier) authorize(request_token) authenticate(security) 인화 요청 return PROTECTED_RESOURCES return ACCESS_TOKEN, SECRET return REQUEST_TOKEN redirect: CALLBACK URL (request_token, verifier) redirect: authorize(request_token) 결과 화면 Transport Layer

24. 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

25. 데모 시연

26. Tonr & Sparklr Tonr – Service Consumer (=beppa) Sparklr – Service Provider (=faji) Tonr Sparklr Transport Layer

27. 스프링 시큐리티OAuth

28. Spring-Security-OAuth • http://spring-security-oauth.codehaus.org/ • http://static.springsource.org/spring-security/oauth/index.html

29. Consumer & Provider 구현 Spring Security OAuth (Provider) Spring Security OAuth (Consumer) Provider Consumer Transport Layer

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

31. 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의 일부 기능들은 이미 페이스북이나 트위터에 적용되고 있으며, 최종 규격서는 올해 연말쯤 발표될 예정이다.

32. 감사합니다!!!