Develop Reference

IdentityServer4 + Asp Identity + EF Configure two UsersSet/Providers

Having trouble finding a good lead on this. I have a aspnetcore app with identityserver4 configured to use asp identity with a sql database.
There is a business requirement that all non AD users are stored in this asp identity database.
All AD users are defined on Azure. I can authenticate them with LDAP and receive their data.
The issue comes after authentication. Whenever asp identity tries to call:
var user = await UserManager.FindByNameAsync(userName);
With an AD user, it fails because the user does not exist. This is because it is using EF to query the asp identity database, where those users are not defined.
private DbSet<TUser> UsersSet { get { return Context.Set<TUser>(); } }
I can not store any of the AD information in the asp identity database (business requirement). I am trying to find a way to get the user store to look both at the asp identity tables, as well as Azure (via LDAP).
My current method for getting the AD users when doing initial auth is here:
await GetADUser(queryParams),
It uses LDAP to authenticate and grab the user object.
One additional requirement is that I can not use an external login screen, the login must all be done from the same company facing login UI. AKA no external providers.

As per #mxmissile, abstracting the UserManager out was the correct call. Then you can also abstract out other managers as needed for special functionality. This is in fact the only class in the inheritance layer for this part of the code that is virtual.
There are built in functions that let you register your custom managers:
services.AddIdentity<IdentityUser, IdentityRole>()
.AddUserManager<ApplicationUserManager<IdentityUser>>()
.AddSignInManager<ApplicationSignInManager<IdentityUser>>()
Hopefully this is a little help to any others that have a similar question. I ended up just overriding a couple of the functions from the base user manager and just calling the base method for anything that did not need my new logic. By default it looks like ASP Identity does not try to look up users by email - just fyi.

Web API token authentication with a custom user database

I am developing a Web API 2.1 service that needs to authenticate the connecting clients (HTML5/JS clients that I will create and control). Unfortunately, the user information (username, password hashes, roles and much, much more info) is stored in an existing (SQL Server) database to which I only have read access. The Users database table was created 5-6 years ago without any reference to security frameworks, so it's a completely custom format. I'm not allowed to make any changes to either the data or the database structure.
Inspired by this article, I rolled my own token-based method of authenticating users, but I'm lacking the completeness and (re)assurance of using an established security framework.
Is there a way to integrate an existing framework, e.g. OAuth2, within my current project given the constraints I mentioned above? I don't know if it makes any difference, but I'm self-hosting using OWIN.

This is a good answer to a similar question.
It basically says:
Make a custom user class which implements IUser
Define a custom user store which implements public class UserStoreService
: IUserStore<CustomUser>, IUserPasswordStore<CustomUser>
wire everything up
Since the answer is pretty extensive I just provided the basic steps...
details are here: How to customize authentication to my own set of tables in asp.net web api 2?
This is also a very valuable content which also applies to web api:
Customizing ASP.NET Authentication with Identity by JumpStart
https://channel9.msdn.com/Series/Customizing-ASPNET-Authentication-with-Identity
HTH

Someone else, having the competence, can explain the options. But if authentication as service is an option, then check out Auth0 # https://auth0.com
I have tested the service (as Azure plugin) using both HTML/JS- and native Windows Phone applications, against simple Sql Server table and AD. Works liek charm, near zero headache.

I stumbled upon a my solution while trying to implement json token authentication within web api. It is important to note that my solution handles authentication by sending a json token through the Authentication header of the Http request (not via cookies) and not using Microsoft.Identity framework.
Anyway, I basically implemented in a cookbook fashion the solution helpfully described here by Taiseer Joudeh: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/
The key thing to notice is the following bit of code:
//Dummy check here, you need to do your DB checks against memebrship system http://bit.ly/SPAAuthCode
if (context.UserName != context.Password)
{
context.SetError("invalid_grant", "The user name or password is incorrect");
//return;
return Task.FromResult<object>(null);
}
Naturally you would replace this bit of code above with your own method for checking your (presumably pre-existing) user database(s). Once I implemented this I realized that you don't need to use new code first identity framework that Visual Studio installs for you.
To make this work I did the following:
1) Created an an empty project and selected Change Authentication/Individual User Accounts. This installs most of the required references and files you need out of the box to use token authentication by way of cookies as well as the code-first identity framework files.
2) Edited these files following Taiseer Joudeh's lead. This requires
some new objects such as CustomOAuthProvider.cs among others. And you need to implement your own user/password check by customizing this code block:
if (context.UserName != context.Password)
{
context.SetError("invalid_grant", "The user name or password is incorrect");
//return;
return Task.FromResult<object>(null);
}
Link to Taiseer Joudeh's instructions: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/
3) Pruned my project of extraneous files (AccountBindingModels.cs, AccountViewModels.cs, IdentityModels.cs, ApplicationOAuthProvider.cs, identityConfig.cs, AccountBindingModels.cs, AccountViewModels.cs). Basically, No more microsoft identity references.
I am sure the microsoft.identity thing is excellent, but I was annoyed with the code-first implementation of databases when I was already using some legacy databases of a different structure etc. Hope this helps. I am quite satisfied with the result (after a few days of messing around to get it to work).

I did not want to use any existing classes and finally come out some thing very simple like
var userName = context.UserName;
var password = context.Password;
var userService = new UserService(); // our created one
var user = userService.ValidateUser(userName, password);
if (user != null){
.......
}
See the full details here OAuth Web API token base authentication with custom database
For Role base authentication with custom database
Hope it will help

This might be a completely insane and invalid approach for you but I faced a similar challenge: New web app (MVVM + WebAPI), legacy system used to issue and validate tokens. Inspired by http://tech.pro/tutorial/1216/implementing-custom-authentication-for-aspnet, and because my application would primarily be used by its accompanied GUI (the MVVM webapp), I decided to use a "cookie based" token produced by FormsAuthentication. The FormsAutnentication cookie/ticket is secured by .net internal magic security (which I assume id completely safe and unbreakable).
In my case the cookie simply holds the ticket issued by the legacy system, (but you could store more details there as well, eg by JSONSerializing a custom type). During authorization, my system validates the token against the legacy system. I guess you could use something similar together with a custom AuthorizationFilter.

Asp.net Identity - How to Login Regardless of Discriminator

Im using asp.net identity and I have a number of user classes that inherit from IdentityUser.
Lets say I have an inheritance chain like:
IdentityUser <- AppUser <- ServiceUser <- ServiceEmployee and ServiceCustomer (which both inherit from ServiceUser).
When trying to create a unified login form whats the best strategy?
If you use the OTB account controller and change the UserManager to use ServiceUser but try to login an account that was registered as ServiceEmployee it will fail because FindAsync() apparently only tries to find based on "ServiceEmployee" in the discriminator field, so if the account was registered as a different "type" it cant be used to login. So this happens with any combination when registered vs login types differ.
Should I update the login action to use multiple UserManagers so that there is a check against each user type or is there some better way to do what I am trying to achieve.
Thanks for any info.

Have you considered keeping your identity users and your own application users separate? Meaning User is what holds your identity information and Person is what the rest of your application uses (and other types such as Employee inherit from). This is how I do it myself. I keep all security/identity stuff completely separate (in separate project/context) and only link my User and Person entities which works great for me - much easier to maintain and update my security model without affecting the rest of my application and (as much).

how to get role from id in asp.net sql membership provider?

MembershipProvider has methods
public abstract MembershipUser GetUser(
Object providerUserKey,
bool userIsOnline
)
to look up users by their unique identifier. This is useful if you want to have you own database and associate some objects of yours to certain memberships.
Can you do the same with RoleProvider ? There doesn't seem to be any methods to map roles to their unique identifier or vice versa.
As a side note is it a good idea to just add your own tables to the asp.net sql database or is it better to have a separate database for your own objects and have foreign keys into the asp.net sql membership table.

There is no way within the API to return a role from an ID - you can get all roles via
Roles.GetAllRoles();
Or you can get all roles for a user by
Roles.GetRolesForUser(userName);
But not a single role.
I would guess the reason for this is that roles on there own are probably not that useful (at least as far as Microsoft are concerned).
Of course roles are just a table within the database so you can easily add this functionality yourself with some straight SQL - it will just take a little more work.
In terms of additional data - I normally create my own tables within the same database with foreign keys as you have suggested above. Although if you have not heard of Profile Provider (http://msdn.microsoft.com/en-us/library/0580x1f5.aspx) you may want to look into that as well.

There's no such thing as an "asp.net sql database". There's simply the default database that asp.net creates for you if you haven't specified one. There is no reason to use this default database seperately from your regular database. This is why it has a connection string.
The whole point of membership is that it's flexible, to use as you see fit.

On a login page, the Page.User variable is still set to anonymous. If you'd like to verify roles before login, you can construct your own GenerpicPrincial like:
var principal = new GenericPrincipal(
new GenericIdentity(username),
Roles.GetRolesForUser(username));

Role management with ASP.NET inbuilt controls

I am using the ASP.NET inbuilt login and role management solution (creates table like aspnet_Users etc. and gives access to MembershipUser and the such).
However, at this stage I am a bit stuck with the following:
1) I need to be able to Suspend, Unsuspend and Delete (not necessary remove from table, just disable) users from my app. Is this feature inbuilt?
2) I need to have three different user roles, where one of the roles is always assigned by default. Currently I have built an app with no roles. Is ASP.NET capable of doing this?

ASP.NET Membership has concepts for "Approved" and "Locked out" (after X number of failed log in attempts) for users, you can probably use those features for suspending users. 4guysfromrolla.com had a great article series on Examining ASP.NET's Membership, Roles, and Profile , it's worth a look.

I don't think that's available by default, but should be fairly easy to add in.
Roles are supported in the default implementation. However, you'll have to define and assign the roles yourself.

There is a built-in DeleteUser
method. It calls a stored procedure
named dbo.aspnet_Users_DeleteUser.
You can change that stored procedure
to suspend a user instead of
deleting them.
Similarly, there is a built-in CreateUser method which calls a stored procedure named dbo.aspnet_Membership_CreateUser which you could modify. Or, you could use the Roles.AddUserToRole method to set the default role when the user is created, calling it in your CreateUser method (which would first Membership.CreateUser)