We have moved to GitHub Issues
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:
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:
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?
For two-factor authentication, any chance of supporting FIDO U2F?
Have update this as a 'breaking change' only because there are database updates (which of course get processed automatically by the upgrader)
@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:
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.
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.
Type: Feature (request)
Assignee: Shannon Deminick
Backwards Compatible: False
Affected versions: 7.1.1
Due in version: 7.3.0