xxiii
Introduction
Risk comes from not knowing what you’re doing.
—Warren Buett
Few organizations can aord to have dedicated people working on application security. More often than not, a
developer or a lead developer from the team is entrusted with the responsibility for retrotting security into the
application or a service. In this quest, the developer looks around, maybe Googles some information, asks a question
or two in forums, and rolls his own security implementation without knowing fully the underlying concepts and the
implications of the choices he made. is path of least resistance is usually taken because of the project schedule
pressures and the lack of emphasis or the focus that the nonfunctional aspect of security generally deserves.
Not reinventing the wheel is a great policy for application development teams because reusable components
like libraries and frameworks help get things done eciently and the right way, incorporating best practices. e
ip side of reusable components, open source or not, is that they result in a “black box” syndrome: ings just work
and continue to work until the time they stop working. Also, if a reusable component provides options, a developer
must know the dierent choices available as well as the advantages and disadvantages of those choices to make a
knowledgeable decision on the methods to be employed for the security requirements at hand.
Compared to the SOAP-based Windows Communication Foundation (WCF) services that enjoy the support of
mature security specications such as WS-Trust, WS-Security, and so on, REST-based ASP.NET Web API currently has
very little support. OAuth 2.0, which is the equivalent for WS-Trust and WS-Security in the REST world, is nascent: e
OAuth 2.0 framework and the bearer token specications were published in October 2012.
Even if you have simple security needs that can be met by the direct authentication pattern of a client presenting
a password to your ASP.NET Web API for authentication, will you implement Windows Authentication, which is a
popular choice for intranet ASP.NET applications, or Forms Authentication, which is a great choice for Internet ASP.
NET applications, or widely supported HTTP-based basic or digest authentication? ere are pros and cons with every
option, and there is no one-size-ts-all solution available for securing a web API.
is is where this book comes in and presents to you the various options available for securing ASP.NET Web
API, along with the merits and demerits of those options. Whether you roll your own security mechanism or use a
reusable component in the form of a library or a framework, you will be able to make informed decisions by learning
the underpinnings of the mechanisms and the implications of the choices you make.
However, this book does not give you any ready-made, penetration-tested code to copy and paste straight into
your production implementation. It does not give you sh, but instead teaches you to catch sh. Using this book, you
can gain a solid understanding of the security techniques relevant to ASP.NET Web API. All the underlying concepts
are introduced from basic principles and developed to the point where you can use them condently, knowing what
you are doing. If you want to get your hands on proven, production-strength code, there are a couple of excellent
open-source resources:
• inktecture.IdentityModel.45 features an extensible authentication framework for ASP.NET Web
API supporting SAML 1.1/2.0, JSON Web Token (JWT), Simple Web Token (SWT), access keys, and
HTTP basic authentication. It also has support for protected cookies and Cross Origin Resource
Sharing (CORS). See https://github.com/thinktecture/Thinktecture.IdentityModel.45.
www.it-ebooks.info
我的内容管理
收起
我的收益 登录查看自己的收益
我的积分
登录查看自己的积分
我的C币
登录后查看C币余额
我的收藏 
我的下载 
下载帮助 
评论0