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.
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.
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?
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.
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.
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.
Ok, when you title a blog post as Part 1, you better follow up with a Part 2. I hadn’t forgotten, but it’s taken a little to come back around to my adventures with ASP.NET Identity.
Where was I? Oh yeah, last time I discussed how to, mostly, get ASP.NET Identity working with a pre-existing security model. This was working fine for me with the v2.1 Microsoft.AspNet.Identity.EntityFramework packages, but when I updated to the v2.2 packages, things broke.
For whatever reason, the Microsoft.AspNet.Identity.EntityFramework v2.2 packages changed the flow. The v2.1 packages, with my modest code modifications, didn’t seem to go back to the local (EF) database to update/create the current user. But, it may have been performing a check for user existence and then doing a upsert. The v2.2 packages, though, broke this paradigm.
As anyone familiar with .NET web development is aware, Microsoft has tried to get security right many times. We’ve gone from its ubiquitous Membership model to its “simple” providers. Now, the latest, albeit it’s been around for a while, is its Identity framework.