Client certificates and two factor authentication with client certificates in MembershipReboot
I just released v3.0.0 of MembershipReboot. It was a significant enough change to warrant going to 3.0. From my chicken scratch release notes:
Features added:
- separate EF code from the main library. there’s now a new library that contains the EF-specific persistence code.
- reworked the separation of the membership reboot configuration from the repository. this was necessary due to the EF library refactoring, plus it’s now cleaner.
- removed all the deprecated code and classes (mainly to eliminate confusion)
- added support for client certificates. client certificates can be used to either login or can be used as part of two factor authentication (in lieu of mobile sms two factor auth).
- added concept of groups (or group definitions). this doesn’t affect how roles (or groups) are associated with user accounts. rather it’s just a new entity/table where an application can define what groups the application uses. this was mainly added for scim support (http://www.simplecloud.info/).
- added account-level validation extensibility point. previously there were just username, email and password validators. now an application can register validators that are invoked for specific user account events. this is much like the existing notification events, except the validation events are called prior to the database being updated and are able to cancel the persistence. these validators are keyed off of the same user account event classes as notification.
- enhanced/improved diagnostic tracing in user account and user account service classes
- more user account events (#89) and some more built-in email notifications for these events
So some main points:
Previously there was only a single MembershipReboot library. It housed the core logic plus classes to persist the user account information via EntityFramework. Since MembershipReboot was designed to decouple the account management and security logic from the persistence, it made sense to also decouple the implementation this way. There are people using MembershipReboot with NoSql databases, so it now makes it a little easier on them now that the core library no longer has a dependency on EntityFramework.
Related to the prior point, I had to make some breaking changes in the MembershipRebootConfiguration. I wasn’t happy with the relationship between the configuration and the repository, and so I also decoupled those. This too is a breaking change, but I feel like it’s a cleaner design.
I apologize for these breaking changes, but they’re fairly simple to remedy. If you were previously using EF, then all you need to do is get the new MembershipReboot.Ef package from NuGet. If you were previously using the MembershipRebootConfiguration, you can remove the ctor argument that deals with instantiation of the repository. The repository is now a ctor parameter to the UserAccountService — in short this just means you need to include the repository in your DI framework (which you probably had anyway). See the updated samples too see how it’s done.
So in addition to those structural changes, I added support for client certificates. Client certificates can be associated with a user account and used for either full authentication (in lieu of username/password) or they can be used for two factor authentication (username/password in addition to client certificate). So now this means the two factor authentication support in MembershipReboot can be either mobile SMS code (like google does) or client certificates. BTW, this is an account-by-account setting. Again, see the updated samples too see how it’s done.
Beyond these major additions, there were several other smaller tweaks here and there. All in all, I’m really happy how this library is progressing.
As always, questions, feedback, and enhancement requests are all welcome.
Reblogged this on Three Alves and commented:
Brock Allen has released a great MembershipReboot version. Go read what was added.
Hi Brock,
Congrats on the new release! One question – upon adding the new Nuget packages for MR and updating the config etc, I get an error saying that it needs Entity Framework migrations enabled as there have been database changes. Should I be seeing this, and if so, is it enough that I enable migrations and scaffold a migration for the MR changes for it to start working?
Thanks,
Phil
P.s. I never did quite manage to get the claims working with Thinktecture.IdentityModel and MR (for web api), so for now have resorted to retrieving the user’s account in my api methods in order to ensure the claims are correct…
Well, the DB schema changed so you’ll either need to re-create the database from scratch or build some migrations: http://msdn.microsoft.com/en-us/data/jj591621.aspx
Reblogged this on http://www.leastprivilege.com.