Category Archives: Security

Home / Security
22 Posts

Previously, I blogged about writing your own handler to hook into the OWIN middleware pipeline. I’ve been using the handler I described in that post for quite some time now.

However, after a bit of QA, I noticed at least one strange behavior.

More Link

After creating a redistributal package for a custom OWIN AuthenticationHandler that handles logins to an internally hosted Oauth2/SSO provider, I found something a little annoying.

When OWIN detects a 401 response and the AuthenticationMode is “Active,” it doesn’t capture the URL hash from the request.

More Link

Being able to decrypt the OWIN AuthenticationTicket can be very useful. In the cases where the cookie/tickets are shared across applications, this is especially true.

Interestingly, if you’re using OWIN for both cookie-based authentication and access tokens, the Ticket is stored in both mediums.

With that in mind, the easiest method to decrypt a ticket to access claims, etc is to simply stand up a protected Resource server with a single Api endpoint to display the contents of the ticket. Going this route, the decryption is automatically handled by OWIN with very little code. The endpoint can be accessed by a user’s browser (decrypting the cookie) or by a server passing in a Bearer token.

More Link

With my previous endeavors using OWIN Middleware for an SSO Authentication system, I used DotNetOpenAuth as the client to make the OAuth Authorization Code grant flow. However, after a bit of research, I’ve learned that hooking into the OWIN Middleware can completely eliminate the need to use DotNetOpenAuth.

Additionally, eliminating DotNetOpenAuth and its dependencies makes creating a Nuget reusable package for the applications that I intended to use with the SSO/OAuth2 mechanism much simpler.

More Link

Adding custom claims in .NET Identity, through OWIN, or otherwise is pretty straight forward.

But, what if we want to step outside of, or augment, the OAuth flow?

More Link

After, mostly, getting the SSO / OAuth2 server setup with OWIN working over the past week, I ran into a few interesting scenarios and bits of information worth sharing.

The main scenario was in dealing with Authorization Code Grant across different domains and working that scenario into both the SSO paradigm and “protected Resource” server access.

More Link

I’ve really enjoyed running WordPress. However, there are a few features that plugin authors overlook or don’t consider. One such problem that I ran into was with the Social Login plugin that I use.

This is a great plugin (Social Login), but it was not loading profile images over HTTPS. While this may not seem like a big deal, it did make it so that a browser would report an issue with my site. This was a bit of a show stopper for me after the effort I put into getting certs/https/etc set up.

Fortunately, thanks to the flexibility of WordPress, and PHP in general, it wasn’t too terribly hard to fix.

More Link

After my previous post regarding Secure Token Services / SSO, I have been diving deeper into OWIN to understand its capabilities further.

As I mentioned, the STS system I devised is still using FormsAuthentcation. As a consequence, the relying applications are also dependent on FormsAuth. Upon further inspection, I found that this is redundant. It turns out that OWIN was doing more than I initially divined. Additionally, from all that I have read, it appears that Microsoft’s vision is to completely supplant, and retire, FormsAuth. This, obviously, could be a point of contention if one ties their authentication system into FormsAuth.

More Link

For the past week, I’ve been working on creating a Single SignOn (SSO) system with ASP.NET. One joke around the office is that SSO could also stand for Seldom SignOn. Essentially, we want to make securing applications as painless for the user as possible. Along the way, being able to generate secure tokens through a Secure Token Service (STS) seemed advantageous as well.

Interestingly, it still comes back to cookies. Tokenizaiton is only useful for securing API’s. That is to say, attaching an Authorization Header to an API call is straight forward, but it’s not feasible to attach one to a user’s initiated browsing.

More Link

In .NET when I’m dealing with WebAPI controllers, I like to secure them.  Typically, this is done with an [Authorize] attribute on the controller or the controller’s actions.

One problem that arises with .NET, though, is that a user’s auth token/cookie could be expired because they are inactive for a set amount of time.  Imagine that you’ve written a shiny new SPA-type web app and is SOA driven.  When the user resumes accessing your site, all of the API end-points will fail until the user logs back in.

More Link