U4-4808 - Allow custom backoffice authentication - ASP.Net Identity

Created by Matt Brailsford 01 May 2014, 18:30:44 Updated by Shannon Deminick 18 May 2016, 07:09:21

Relates to: U4-4819

Relates to: U4-7032

Relates to: U4-7190

Implementing ASP.Net identity for authentication in the back office should solve our issues. ASP.Net Identity is fully extensible and should support all requirements.

There is a comment below that references the need to support a multitude of options and I'm pretty sure that these features would be able to be supported (pluggable) into ASP.Net Identity. ASP.Net Identity is not going away and is the foundation for auth in ASP.Net 5 as well.

Identity is really just a bunch of interfaces, all of which can be extended and all authorization points are extensible. MembershipReboot was mentioned below but with the newer Identity libraries i think most of this is obsoleted. Brock Allen has made another one called IdentityReboot: http://brockallen.com/2014/02/11/introducing-identityreboot/ which goes to show that you can configure ASP.Net Identity to do what you want.

This implementation will be compatible with the current (legacy) FormsAuthentication cookies, however we will be able to change the startup options to support the standard Identity cookies as well.

The breaking changes here are:


Development Manager 10 Jul 2014, 00:04:52

OF course .NET Identity 2.0 support is a good start, but is quite flaw. it would be great to have the back office driven by claims based authentication where various Identity Servers like OSS https://github.com/thinktecture/Thinktecture.IdentityServer.v3 can be plugged in. Identity systems like OSS MembershipReboot (https://github.com/brockallen/BrockAllen.MembershipReboot) built on WIF would also be a great base from which to establish:

  • single- or multi-tenant account management
  • flexible account storage design (relational/SQL or object/NoSql)
  • claims-aware user identities
  • support for account registration, email verification, password reset, etc.
  • account lockout for multiple failed login attempts (password guessing)
  • extensible templating for email notifications
  • customizable username, password and email validation
  • notification system for account activity and updates (e.g. for auditing)
  • account linking with external identity providers (enterprise or social)
  • supports certificate based authentication
  • proper password storage (via PBKDF2)
  • two factor authentication support via mobile phone SMS messages or client certificates

Development Manager 13 Jul 2014, 04:57:55

With the issue http://issues.umbraco.org/issue/U4-4309 being released in v8.0, will this now be postponed & bundled with 4309? If not, any idea how this will differ?

Arie 31 Oct 2014, 03:06:13

For two-factor authentication, any chance of supporting FIDO U2F?

Shannon Deminick 24 Mar 2015, 22:45:19

Have update this as a 'breaking change' only because there are database updates (which of course get processed automatically by the upgrader)

Shannon Deminick 24 Mar 2015, 22:53:19

@Arie - 2 factor auth will need to be implemented manually - or you can just utilize 2 factor auth with the external identity provider (i.e. Google auth would handle this for you). Otherwise it's impossible for us to know how people would want that configured and there's probably tons of different ways and providers to use for this. To implement a custom one you'd have to override the current BackOfficeUserStore and implement the required interfaces:

  • IUserPhoneNumberStore<BackOfficeIdentityUser, int>
  • IUserTwoFactorStore<BackOfficeIdentityUser, int>

Then override the BackOfficeUserManager to override the SupportsUserTwoFactor and SupportsUserPhoneNumber and configure your own EmailService and/or SmsService

You'll then need to provide your own persistence mechanism for these values.

ASP.Net identity is extremely flexible/extensible and we've allowed inheriting from our base classes so you can adjust as per needed.

Kevin Giszewski 29 Sep 2015, 14:59:05

This is marked as a breaking change only because of DB updates but this may have broken custom providers altogether: http://issues.umbraco.org/issue/U4-7032

Will try to trace code at some point but the related issue illustrates that anyone using a custom provider cannot upgrade properly nor validate a user as a critical method is not called.

Priority: Normal

Type: Feature (request)

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal

Category: Security

Backwards Compatible: False

Fix Submitted:

Affected versions: 7.1.1

Due in version: 7.3.0


Story Points: