Implementing ASP.Net Identity

[awesomegithubusername]

Hi everyone!

Is it possible to implement ASP.Net Identity? And would I still be able to use Serene tree-like permissions (and roles) management? What about the database schema? Any major modifications to be aware of? If you've already integrated Identity please share the best practices to follow.

[jsbUSMC]

It's something I've tried and have had some issues with. The problem I've seen is how to implement Serenity interfaces which expect return types like Boolean when all of the ASP.NET Identity classes and interfaces return Tasks, as everything is async/await. I would love to help out more with this.

[awesomegithubusername]

Thanks for your reply @jsbUSMC. Implementing ASP.Net Identity would be a nice feature to have, especially for a public facing web site where security is a serious concern.

[jsbUSMC]

I agree. But I think that some of the interfaces will have to be rewritten. I wouldn't have a problem with this, except if I update Serenity code myself it will get overwritten by an update. I think perhaps we could integrate Serenity interfaces ourselves as separate namespaces and users can change how they auth depending on which solution they would like.

[jsbUSMC]

Another thing is that the storage provider will have to be rewritten to use Dapper instead of Entity Framework. The default implementation of Identity uses EF as the db provider. We should probably rewrite that since we use Dapper/Serenity and that might be a little bit above my head.

[awesomegithubusername]

Regarding the Dapper thing, I think that the two providers can co-exist in the same application. He're the answer of Mark Graver, a Stackoverflow developer and the primary author and maintainer of Dapper, to a similar question.

[jsbUSMC]

Well that's awesome. In this case, we really only would have to have Serenity interfaces be able to work with Identity. For example, the IAuthorizationService.cs interface:

public interface IAuthorizationService
{
    bool IsLoggedIn { get; }
    string Username { get; }
}

expects us to imlement an IsLoggedIn() method that returns a bool. However, the classes written for Identity that check for a user being logged in is:

public async Task<string> GetVerifiedUserIdAsync()
{
    var result = await AuthenticationManager.AuthenticateAsync(
        DefaultAuthenticationTypes.TwoFactorCookie);

    if (result != null && result.Identity != null
        && !String.IsNullOrEmpty(result.Identity.GetUserId()))
    {
        return result.Identity.GetUserId();
    }
    return null;
}

We are getting the user id of the UserIdClaimType as return, which is a string Guid.

[volkanceylan]

You can run an async method synchronously, with Task.Run

[awesomegithubusername]

It seems that @BolatovAlau has already integrated ASP.Net Identity in Serenity. Here's the corresponding thread.

[jsbUSMC]

I saw that awhile back. I did what he did and it worked, though you log in using the default ASP.NET login screen, and not Serenity's. Also, the permissions system in Serenity is separated because the interfaces aren't implemented. If we can implement the interfaces and the static class for authorization, then Identity could basically be a drop in replacement for the default Serenity scheme.

[volkanceylan]

Integrating any authentication system is possible. But why ASP.NET identity? What it brings to table, i wonder. ASP.NET membership was their prior solution and it was not well designed and slow. I don't know much about ASP.NET Identity, but some Microsoft teams has a tendency to make things more complex and bloated then they should actually be. For example, Node being forced to async because of Javascript, doesn't mean .NET has to be async by default. Why force people to use async, if %99.9 doesn't need it at all.

[awesomegithubusername]

Well it's just that with ASP.Net identity, you get the feeling that you're using a solution that's supported by a tech giant and designed by people who are supposed to know what they are doing security wise. My understanding is, unless you're 100% confident the implementation is robust (in terms of cryptography, choice of the password hashing function, salt length, sessions management, email verification, password reinitialization, ....), you shouldn't be using you're own authentication system. You'd be a little be more covered when things go south ("We're using the standard Microsoft implementation. It's not our fault the system got hacked" ;) )

[volkanceylan]

Serenity uses standard ASP.NET authentication mechanism, e.g. forms authentication. Has no custom security system baked in. Having your own user tables doesn't change this fact.

[awesomegithubusername]

Thanks for clearing that out, volkan. I was too paranoid, I guess :).

[jsbUSMC]

@awesomegithubusername I understand where you're coming from about rolling your own auth framework. But as @volkanceylan pointed out, Serenity uses forms auth, which I found out awhile ago digging through the source. I think the best part of using the ASP.NET Identity 2.0 is the ease of plugging in your own claims and extending the mechanism. For example, adding OAuth 2.0, SMS/Email verification, two-factor authentication, or altering the behavior of the authentication like lockouts and such. @awesomegithubusername you're not being too paranoid, caution rewards itself when investigating the mechanisms behind the authentication/authorization framework you're using, and understanding its methods and possible shortcomings. @volkanceylan Identity 2.0 has superseded Forms Auth, ASP.NET Membership, and provides one authentication system that can be used across MVC, Web API, and SignalR. I think it's a solid implementation, though I also totally agree that Identity forcing us to use async is a pain.

[volkanceylan]

Ok, oAuth and two factor seems fair enough

[jsbUSMC]

Hi @awesomegithubusername and @volkanceylan

I created this gist of sample interfaces that could be implemented within a possible Serenity.Abstractions.Identity namespace. Let me know if you guys think this is a good start, and I will continue to work on an implementation of ASP.NET Identity and associated wiki article.

[buddhatripp]

Does anyone have an example of this yet? It's tagged with add sample then closed... A year ago.

[ShayneJud]

I am also interested in an implementation. When possible, we always try to control Application Permissions via AD Users/Groups, if for no other reason than ease of administration and integration into the daily work flow of our IT Staff. We are a global Automotive Supplier, with limited IT Staff. Our Admins know AD and not only that, we have other systems and processes such as our Help Desk Ticketing system that already has integration (shortcuts/links/categories/solutions/help files/videos) based on AD. So, adding any sort of Security/Membership/Authentication other than AD, just adds a (mild) headache that I like to avoid when possible. (There's also the "Single Sign On factor". Avoiding any additional passwords that the user has to remember is a plus. Along with systems/places/interfaces the IT Staff has to know about and be trained on, even for simple things like "unlocking" accounts.)

Anyway, I'm just now going through all the threads related to this topic and this is one of the older ones, perhaps there is a newer one with samples/best practices/etc (maybe even a "full implementation", one can only hope). LOL But so far, this one contains the most/best discussion on this topic that I have encountered. That's why I am adding my comment here, even though it's closed. (We also have a "Commercial License" of Serenity (StartSharp) and if I don't find a solution in the forums in the next few days, this may be worth burning one of my 10 "support incidents" that we get with that license.) :)