Since the OAuth server I’ve detailed previously is using OWIN, I’ve been looking at what it will take to move it to .NET Core. The OWIN OAuth Server provides all of the Secure Token creation. This functionality is not provided with .NET Core’s native middleware.
My first thought is to integrate with IdentityServer4 or Openiddict which provide Secure Token generation and are .NET Core compatible. After some cursory information gathering, I’m putting a few research links here for later use.
Long, long ago, I wrote about StartSSL. It was actually one of my first blog posts. After using the StartSSL (StartCom) service without issue for over two years, it appears that their root authority has been revoked making their free service virtually useless. I had to find an alternative.
Over the weekend, I had an interesting experience updating an old, legacy website that uses ASP. ASP is interesting, but the more interesting thing is that many of these old applications rely on specific browser modes or default to “quirks” mode.
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.
My relationship with Microsoft, and especially Windows, is a love hate relationship. For some inane reason, Microsoft continues to differentiate their server/desktop products. Yet, the code bases for those products are, in effect identical.
Microsoft’s separation of product lines ultimately hurts consumers. We wind up with identical products that are artificially limited.
As a developer, I often overlook what infrastructure changes are involved in a setting up a production website. As a user of free services like FreeDNS / DynDNS, I had never even registered a domain.
Over the past few days, that changed. In deciding to create this blog, I settled on WordPress. Getting WordPress set-up and running through Microsoft’s Web Platform installer was actually pretty easy. However, I soon discovered that it was lacking.