Handling claims transformation in an OWIN middleware in .NET MVC part 4

Introduction

In the previous post we turned our claims transformation code into OWIN middleware. We went through the process of creating a component – the ClaimsTransformationComponent – and registering it with OWIN in Startup.cs. We set the current claims principal in our component which is then available within the controllers.

In this post which finishes this series we’ll diverge a little from our main topic and take a look at how we can add dependencies to an OWIN component.

Read more of this post

Handling claims transformation in an OWIN middleware in .NET MVC part 3

Introduction

In the previous post we built upon our MVC claims transformation demo. Specifically we saw how to take the incoming claims and add a couple of custom ones by pretending that we query some data store. We wired up all the demo code in the HomeController.

The goal of this closing post is to reorganise the claims-related code into OWIN middleware.

Read more of this post

Handling claims transformation in an OWIN middleware in .NET MVC part 2

Introduction

In the previous post we laid the foundations for this short series. We went through a refresher of claims and OWIN and started building a simple ASP.NET MVC web project to investigate what’s available about the user of the current thread in a controller. We saw that by default the only claim available about a user might be their name, unless they are anonymous of course.

In this post we’ll continue to explore claims of authenticated users.

Read more of this post

Handling claims transformation in an OWIN middleware in .NET MVC part 1

Introduction

Claims have become widespread in software projects to tighten the security aspects of an application. We looked at claims before on this blog – see the link in the next paragraph – but time goes by and new features have been added to this technology lately. This is especially true as far as OWIN is concerned. In this mini-series we’ll concentrate on a very narrow aspect of claims in .NET MVC: claims transformation in OWIN middleware.

Read more of this post

How to enable SSL for a .NET project in Visual Studio

Say you have a .NET MVC or Web API project and you’d like to run it on SSL. In other words you’d like to start up the project on a URL similar to https://localhost:xxxx.

The first step is easy. You just select the MVC/Web API project name in the solution and locate the property called “SSL Enabled” in properties window:

Read more of this post

Web API 2 security extensibility points part 5: OWIN

Introduction

In the previous post we discussed how to add a custom authorisation filter to your .NET web application. We saw how you could derive from the AuthorizeAttribute class and implement your own logic for the IsAuthorized and HandleUnauthorizedRequest methods. The methods in the custom authorisation filter are called after any authentication filter is applied and before the appropriate controller action is executed.

In this post we’ll look at another entry point where you can apply your custom security logic in a .NET web application: OWIN

Read more of this post

Web API 2 security extensibility points part 4: custom authorisation filters

Introduction

In the previous post we built a custom HTTP message handler for our demo Web API 2 application. We saw how a registered message handler intercepts all calls to your API before authentication filters are executed. We also wrote a couple of examples where we checked for the presence of a custom header and of an authorisation header. We finally showed how to set the principal for the current HTTP call.

In this post we’ll see another way you can intercept the calls to your API. Authorisation filters are executed after authentication filters and before your controller action methods. That is the last stage where you can add your custom auth-related logic.

Read more of this post

Web API 2 security extensibility points part 3: custom message handlers

Introduction

In the previous post we looked at how to implement your own custom authentication filter. Authentication filters – and filters of type IFilter in general – are executed just before your controller action methods are run. We saw how to implement the IAuthenticationFilter interface and how to apply the custom filter both as an attribute and as a global filter.

In this post we’ll look at HTTP message handlers and specifically how to add your own message handler. Message handlers are executed even before any custom filter so they provide an early entry point into the life cycle of a web application. There’s nothing stopping us from adding an initial security check or a full-blown login mechanism already at that stage. We can check e.g. if a mandatory custom header has been provided and reject all incoming HTTP calls that don’t fulfil this requirement up front.

Read more of this post

Web API 2 security extensibility points part 2: custom authentication filter

Introduction

In the previous post we introduced the topic and main goals of this series. We also set up a demo Web API 2 project which we’ll use throughout. We also briefly investigated the HTTP request context and how we could extract information about the current user of the HTTP request from it.

In this post we’ll see how to write your own custom authentication filter attribute. We’ll only look at a simple example to show how to access the request context from an authentication filter. Further down you’ll find a reference to a post on http://www.asp.net which takes up a much more detailed example.

Read more of this post

Web API 2 security extensibility points part 1: starting point and HTTP request context

Introduction

Web API 2 comes with a number of new security features. In this new series we’ll concentrate on the HTTP request context and its Principal property. In particular we’ll see how to hook into the different extensibility points in the Web API. These extensibility points offer you to plug in your security-related checks at different points in the application lifetime when a request hits your API. You can carry out a number of checks and modify the request Principal according to your business rules and needs.

I’m building the demo in Visual Studio 2013. I’m not sure at this point how much the Web API template will change in Visual Studio 2015.

Read more of this post

Elliot Balynn's Blog

A directory of wonderful thoughts

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

WEB APPLICATION DEVELOPMENT TUTORIALS WITH OPEN-SOURCE PROJECTS

Once Upon a Camayoc

ARCHIVED: Bite-size insight on Cyber Security for the not too technical.