이 책의 구성

1장: ASP.NET Web API에 온 것을 환영합니다
RESTful Web API의 기본 지침에 대해 알아보기 전에 일반적인 웹 API가 무엇인지 먼저 이해하고 이어서 Microsoft의 ASP.NET Web API프레임워크가 웹 API를 개발하는 데 어떤 도움을 줄 수 있는지에 대해 검토해본다. 많은 사람이 보안이라는 단어의 의미를 생각할 때 떠올리는 사용자 이름과 비밀번호를 받는 로그인 화면 외에도, 보안의 다양한 측면에 대해 살펴보는 보안 지침과 함께 이 장을 마무리한다.

2장: RESTful 서비스 구축
XML이나 JSON 형식으로 요청과 응답을 처리하고 GET, POST, PUT, DELETE와 같은 HTTP메소드를 사용하는 HTTP서비스라고 해서 반드시 RESTful서비스라고 볼 수는 없다. 이 장에서는 RESTful방식으로 호출할 수 있는 HTTP서비스와 간단한 Hello-World류의 API인 우리의 첫 번째 웹 API를 만들어보고, 이때 반드시 충족시켜야 하는 Roy T. Fielding의 제약조건을 소개한다.

3장: 확장 지점
ASP.NET Web API프레임워크는 처리 파이프라인을 확장하기 위해 웹 API파이프라인에 추가할 수 있는 여러 확장 가능한 지점들을 제공한다. 이 장에서는 가능한 한 빨리 위험을 처리하기 위해, ASP.NET Web API보안을 활용하는 관점에서 필터나 메시지 처리기와 같은 웹 API확장 지점에 대해 중점적으로 알아본다. 인증 및 권한을 위해, ASP.NET확장 지점인 HTTP모듈보다는 웹 API확장 지점인 메시지 처리기를 선택해야 하는 이유와 이에 관련된 상호 보완적인 부분에 대해 알아본다.

4장: HTTP 구조 및 보안
이 장은 World Wide Web의 기반 프로토콜인 Hypertext Transfer Protocol(HTTP)에 대해 소개한다. HTTP를 이해하는 것이 ASP.NET Web API의 보안 측면을 이해하기 위한 선행 작업이다. 웹 API는 HTTP를 포용한다. 이런 이유로, HTTP를 이해하는 것이 무엇보다 가장 중요하다. 집은 무엇보다 기초가 튼튼해야 한다. 이 장은 웹 캐싱, ETags, Cross-Origin ResourceSharing(CORS), 쿠키, 프록시 서버, HTTPS, 훌륭한 HTTP디버거인 Fiddler처럼 제품 수준의 품질, 성능, 보안 웹 API를 위해 반드시 필요 HTTP의 몇 가지 고급 개념에 대해서도 다룬다.

5장: 신원 관리
신원 관리는 응용프로그램 보안에서 아주 중요한 부분이다. 이 장에서 우리는 주체(subject)나 엔티티가 어떻게 인증되며 엔티티가 수행하려고 하는 작업이 .NET 프레임워크 컨텍스트에서 동작하는 응용프로그램에서 어떻게 권한을 부여를 받는지에 대해 알아본다. 이 장은 역할 기반 접근 제어(role-based access control, RBAC)의 바탕이 되는 IIdentity와 IPrincipal인터페이스를 소개하며 더욱 유연하고 세분화된 클레임을 바탕으로 만들어진 클레임 기반 접근 제어(claims-based access control, CBAC)와 RBAC를 비교해본다. 먼저 보안 토큰과 세 가지 주요 형식(SAML, SWT, JWT)을 훑어보게 된다.

6장: 암호화 및 서명
Windows Identity Foundation(WIF)은 내부적으로 토큰의 기본사항을 모두 처리하므로 개발자들이 암호화에 대한 고민 없이 클레임 집합을 통해 작업을 수행할 수 있게 해준다. 우리가 WCF/WIF의 영역에서 벗어나 어려운 암호화 작업을 위해 WIF 클래스에 의존하지 않고 RESTful ASP.NET Web API에 보안을 적용하게 되면 암호화 및 서명의 기본적인 부분들을 이해할 수 있게 된다. 이 장은 대칭 키와 비대칭 키를 통한 암호화/복호화 및 서명/유효성 검사에 대해 다룬다. 또한 Makecert 도구를 통해 생성한 자체 서명된 인증서뿐만 아니라 RSACryptoServiceProvider를 통해 생성한 공개 키와 개인 키에 대해서도 알아본다.

7장: WIF를 통한 사용자 정의 STS
WS-Trust스키마의 핵심 구성요소 중 하나는 Security Token Service(STS)이다. STS를 직접 개발하는 것보다는 구매하는 것을 추천하지만, WIF는 여러분 스스로 사용자 정의 STS를 만들 수 있게 해준다. 짧게 구성된 이 장은 여러분에게 WS-* 프로토콜, 특히 WS-Trust에 대해 소개하며 STS에 대한 이해를 향상시키고 STS가 어떻게 토큰을 만들고 발행하는지 보여주기 위해 사용자 정의 STS를 만드는 단계를 살펴본다.

8장: 지식 요소
지식 요소는 비밀번호나 PIN처럼 사용자가 알고 있는 것이다. 이 장은 ASP.NET Web API보안에 사용할 수 있는 지식 요소 인증 메커니즘에 대해 살펴본다. 사용자 ID와 비밀번호가 결합된 로그인 자격증명은 아마도 가장 널리 사용되는 지식 요소일 것이다. 또한 이 장에서는 지식 요소를 활용하는 메커니즘에 초점을 맞추고 있다. 지식 요소를 활용하는 메커니즘에는 HTTP사양에 따라 정의되는 두 개의 인증 스키마(기본 인증, 다이제스트 인증)와 Windows 인증으로 알려진 Windows 운영체제에서 사용하는 통합된 Windows 인증(Integrated WindowsAuthentication, IWA)이 있다.

9장: 소유권 요소
소유권 요소는 키, 인증서, 토큰처럼 사용자가 소유하거나 소지하고 있는 것을 의미한다. 이 장은 일반적으로 API키라고 불리는 사전 공유 키(Preshared key, PSK), X.509인증서, SAML토큰과 같은 ASP.NET Web API보안을 위한 소유권 요소 인증 메커니즘에 대해 설명한다.

10장: 웹 토큰
이 장은 SAML토큰처럼 소유권 요소인 웹 토큰을 위해 소유권 요소 보안에 대해 다루는 이전 장과 이어진다. 웹 토큰은 RESTful서비스에 훨씬 적합하므로 웹 토큰만을 다루는 장이 있어야 한다. 그러므로 이 장은 웹 토큰만을 다루며 가장 많이 사용되는 두 가지 웹 토큰 형식인 SimpleWeb Token(SWT)과 JSON Web Token(JWT)의 구조를 깊이 있게 알아보고 서명(JWS)되고 암호화(JWE)된 형식도 알아본다.

11장: Live Connect API를 사용한 OAuth 2.0
OAuth 2.0은 인증을 위한 공개 표준이다. 간단히 REST세계의 WS-*로 볼 수 있다. OAuth 2.0
이 구현된 웹 API를 소비하는 클라이언트의 관점에서 OAuth 2.0에 대해 알아본다. 네 가지 형식
의 인증에 대해 검토하고 Microsoft Live Connect API를 사용하는 암시적 허용과 인증 코드 허용
에 대해 자세히 살펴본다.

12장: 처음부터 시작해보는 OAuth 2.0
이 장에서는 다른 측면을 살펴본다. API를 사용하는 클라이언트에 초점을 맞추는 대신 OAuth 2.0을 구현하는, 특히 인증 코드 허용을 구현하는 웹 API를 개발해본다. 두 개의 ASP.NET MVC웹 응용프로그램을 사용하여 처음부터 구현해보기 때문에 기본적인 내용에 대해 이해할 수 있다.

13장: DotNetOpenAuth를 사용한 OAuth 2.0
이전 장을 통해 제품 수준의 OAuth 2.0을 개발할 수도 있지만, 시간을 허비하지 않는다는 원칙에 따라 이 장에서는 공개 소스로 제공되는 안정적인 .NET 라이브러리인 DotNetOpenAuth(DNOA)를 사용하여 동일한 인증 코드 허용을 구현해보며 이 라이브러리는 웹 API에 제품 수준의 OAuth 2.0기반 인증을 적용할 수 있게 도와준다.

14장: 이중 인증
지식 요소, 소유권 요소, 내재적 요소 중 두 가지를 결합하여 활용하는 인증 메커니즘을 이중 인증(TFA또는 2FA)이라고 부른다. 이 장은 지식 요소인 비밀번호와 소유권 요소인 X.509 클라이언트 인증서를 활용하는 TFA를 다루며 Google Authenticator가 제공하는 TOTP코드를 통해 구현되는 TFA에 대해 다룬다.

15장: 보안 취약성
이 장은 중요하고 잠재적인 보안 위험 및 취약성, ASP.NET Web API에 관련된 흥미로운 부분, 보안을 구축하는 동안 조심해야 할 것들, 제품 수준의 ASP.NET Web API에 대해 다룬다. 로그인 및 유효성 검사와 같은 모범 사례뿐만 아니라 10개의 OWASP 2013보안 위험마다 가장 위험한 것들에 대해 알아본다.

부록: ASP.NET Web API 보안 핵심 요약
부록은 이 책의 최종 요약이며 이 책에서 다루는 다양한 보안 메커니즘을 요약하고 있다. 절대적으로 좋거나 나쁜 메커니즘이 있는 것은 아니므로 이 책은 모든 메커니즘을 보여주고 필요에 따라 결정하게 한다. 이 부록은 각 방식의 개요를 제공한다.

몇 안 되는 조직만이 응용프로그램 보안 전담자를 보유할 수 있다. 대개 팀의 개발자나 선임 개발자가 응용프로그램이나 서비스에 보안을 적용하는 책임을 진다. 프로젝트 일정이 빡빡하고 보안을 별로 중요하게 생각하지 않는다거나 보안의 비기능적인 측면만이 가치가 있다고 생각하기 때문에 일반적으로 검색을 통해 어떤 정보를 검색하거나 포럼에서 질문과 답변을 살펴본 다음, 기반 지식에 대한 확실한 이해 없이 보안을 구현하는 방식을 따른다.<br/><br/>라이브러리나 프레임워크처럼 재사용 가능한 컴포넌트는 효과적이고 올바른 방식으로 작업을 처리할 수 있게 해주므로, 쓸데없이 시간을 낭비하지 않기 위해서는 응용프로그램 개발팀을 위해 훌륭한 정책을 만들어야 한다. 또한 재사용 가능한 컴포넌트가 여러 방식을 제공한다면, 개발자는 보안 요구사항에 적용할 방식을 정확하게 결정하기 위해 선택한 방식의 장단점뿐만 아니라 다른 방식에 대해서도 반드시 알고 있어야 한다.<br/><br/>WS-Trust, WS-Security와 같은 성숙한 보안 사양을 지원하는 SOAP 기반의 Windows Communication Foundation(WCF)과 비교했을 때, REST 기반의 ASP.NET Web API는 현재 많은 지원이 이루어지고 있지 않다. WS-Trust, WS-Security와 대등한 REST세계의 OAuth 2.0은 아직 초기 단계다. OAuth 2.0프레임워크 및 전달자(bearer) 토큰 사양은 2012년 10월에 발표되었다.<br/><br/>클라이언트가 ASP.NET Web API에 비밀번호를 전달하는 직접(direct) 인증 패턴처럼, 인증을 위해 간단한 보안 요구사항만 있으면 충분한데도, 인트라넷 ASP.NET응용프로그램에 적합한 Windows인증을 구현한다거나 인터넷 ASP.NET응용프로그램에 적합한 폼 인증을 구현한다거나 널리 지원되는 HTTP기반의 기본 인증이나 다이제스트 인증을 구현할 것인가? 방식마다 장단점이 있으며 웹 API보안에 두루 사용할 수 있는 솔루션은 존재하지 않는다.<br/><br/>이런 내용이 이 책에 들어있으며 이런 방식들의 장단점과 ASP.NET Web API에 보안을 적용하는 다양한 방식들에 대해 설명한다. 직접 보안 메커니즘을 만들든지 라이브러리나 프레임워크 형태로 된 재사용 가능한 컴포넌트를 사용하든지 간에 메커니즘의 기초와 함께 여러분이 선택한 방식을 배우게 된다면 정보에 근거한 결정을 내릴 수 있을 것이다.<br/><br/>이 책을 활용하려면<br/>이 책에서 보여주는 코드와 예제가 .NET Framework 4.5를 대상으로 하는 Visual Studio 2012에서 개발되긴 했지만 최소한 Microsoft Visual Studio 2010은 필요하다. 여러분이 Visual Studio 2010을 사용하고 있다면 독립적으로 설치할 수 있는 WIF SDK뿐만 아니라 WIF런타임도 필요할 것이다.<br/><br/>한 가지 알아두어야 할 중요한 부분은 .NET Framework 4.5에서는 WIF가 클래스뿐만 아니라 도구들까지 .NET Framework로 완전히 통합되었다는 것이다. 이 과정의 일환으로, .NET Framework 4.5와 비교했을 때 .NET Framework 4.0의 클래스와 네임스페이스에 차이가 있다.<br/><br/>여러분이 Visual Studio 2010과 .NET Framework 4.0을 사용한다면, .NET Framework 4.0에 적용할 수 있는 소스 코드와 구성 설정은 이 책의 외부 소스 코드를 통해 살펴봐야 한다.<br/><br/>이 책의 모든 코드는 C#으로 작성되었다. Visual Basic.NET을 사용하는 사람들이 있긴 하지만, 책을 두껍게 만들어 제대로 보여줄 수 없을 것으로 판단하여 C# 코드만 사용했다. C# 문법을 이해하기란 전혀 어렵지 않다.<br/>