Skip to content

timothyleerussell/Snoffleware.LLBLGen.Identity

Repository files navigation

Snoffleware.LLBLGen.Identity

.NET 7 Identity custom UserStore/RoleStore implementation using LLBLGen (https://llblgen.com) as the persistence provider.

Author: Timothy Lee Russell / Snoffleware Studios LLC / https://snoffleware.com

License: MIT


What is it and who is it for?

If you use LLBLGen and .NET 7 and want to add the Microsoft identity tables to a new or existing database to provide authentication and authorization leveraging the built-in .NET 7 security machinations while also having a unified interface to your data including the Identity tables using LLBLGen, this is the project for you.

The project is currently on LLBLGen Pro v.5.9.0.

Tests

I could not find much information about testing a custom UserStore but I felt that tests were important for something so crucial as a security-related piece. A best effort attempt has been made to write effective tests and to make it relatively easy to write new tests against the stores, allowing code coverage to expand as needed.

Nothing is mocked, we are testing the plumbing so we are reading and writing directly to a test database.

Tests should pack out all their trash.

Security implications

We're not overriding any of the Identity functionality other than the User/Role stores. We simply want to change the persistence provider. As long as we're storing and retrieving the values correctly, which the tests attempt to validate, we're safely leveraging the default .NET security infrastructure but with LLBLGen as the ORM.

That should mean access to all of the built-in authorization attributes, such as Authorize, Authorize(Roles) and Authorize(Policies).

This lets us add Identity authentication and authorization to a legacy database easily and move it to Azure. Your use case may vary.

WebTest site details

The WebTest project currently uses the 3.0 version of the scaffolded mvc identity area.

There are a couple changes in this project from the default scaffolding:

  • Removed IdentityHostingStartup EF code
  • Modified ~/Areas/Identity/Pages/Account/Manage/EnableAuthenticator.cshtml to include a QR code using qrcodejs per the example in Microsoft docs
  • HomeController Privacy method set to [Authorize]

The goal is to take a database we want to move to Azure and easily add authentication and authorization by simply running a sql script to add the identity membership tables and create a unified model, with all of the tables accessible using the LLBLGen framework of your choice but with user vetting performed by the Identity system.

More tests will be added as issues are found and further examples of authorization will be added to the WebTest project in a future release. If anyone from the LLBLGen community finds this useful and wants to help make this project better, that would be great. If you just want to use it, that's ok too!

Thanks

Special thanks to Frans Bouma (https://twitter.com/FransBouma) for reviewing the code.

Any mistakes are my own but the code benefited greatly from his solid advice.

Code reviews by domain experts are so valuable. Don't be afraid to ask for help!

Steps to setup the project

  1. Create a blank database

  2. Run sql in the file: Microsoft-Identity-Tables-From-Scaffolding-net-core-2.2.txt

    [ TODO: diff v2.2 against a more recent version of the db schema ]

  3. Set secret connection string for the Test AND WebTest projects with your data source and initial catalog values. Repeat the command in each directory.

    To set the secret, open a Powershell prompt inside each project directory and run the dotnet user-secrets set command. Following the security practice of keeping secrets outside of your code can help to prevent credential leaks.
    PS> dotnet user-secrets set "ConnectionString.SQL Server (SqlClient)" "data source=YOURCOMPUTER\SQLINSTANCE;initial catalog=Snoffleware-LLBLGen-Identity-Dev;integrated security=SSPI;persist security info=False"

  4. Change the UserSecrets guid in the Test project -> ConfigurationUtility class. This guid needs to match up with your user secrets store. You can find this guid after you setup user secrets by editing the Test project's .csproj file. Recompile to solidify this change.

  5. The web project seems to know about the user secrets automatically. Only the Test project requires a special treatment because all of the code has to be manually constructed.

  6. OR you can swap in hard-coded connection string values in those two projects The user secrets method is strongly suggested as this prevents you from checking in secrets, in a fork of the project, for example.

  7. At this point, you should be able to run the Test and WebTest projects. You can register a user, login and view the protected Privacy page. You can also click on the profile link and edit the user using the default Microsoft UI. App-based 2FA (TOTP) is hooked up with QR codes provided by qrcodejs.

  8. Email is only stubbed. Currently the email output writes to the debug console. If you want to test email confirmation / forgot password functionality with an actual email service, you can implement that in WebTest->Services->EmailSender.cs

About

.NET 7 Identity custom UserStore/RoleStore implementation using LLBLGen (https://llblgen.com) as the persistence provider.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published