ASP.NET Identity自动注册声明用户

Question

We're attempting to build an intranet web application, and we'd like users to be able to just use their domain credentials to sign into our web site and be automatically registered. All the sample code I've seen with Identity shows users going through a registration page on an AccountController, and the UserManager is used to create the user there.

Since we're requiring authentication on all pages, the user is currently just redirected to the domain sign-in (we're currently using an Azure Active Domain), and then returned to our page. It looks like the default behavior of Identity is to not create a User in the application database when this happens, so we wind up with an authenticated Identity and no corresponding User object in our database. Is there a good place to hook into to create this user? What's the best way to create the user? And how does the UserLogin table play into this, I assume it's used somehow to match a ClaimsPrincipal with the application database User?

We're using MVC 5, Entity Framework 6, and WIF 2

Answer 1

When you use Azure Active Directory (Organizational Accounts), the active directory is your user database. Unless you add it specifically, there won't be an AspNetUserLogins table like you get when you configure your application for authentication using Individual Accounts.

I'm making an assumption that you want to create some kind of user table so that you can store user profile data and/or some authorization claims for each user. You can still do this. For example, you may create a table in a SQL Database (or whatever database you want) to store user profile records in. A good extensibility point in your code for this kind of thing is to derive a class from the ClaimsAuthenticationManager and override the Authenticate method. In here, you can inspect the claims for the incoming authenticated user, look up additional profile claims you've stored for the user in your database table, and then add those claims to the claim set for the ClaimsPrincipal. One of the claims you will get from Azure AD in the incoming principal object is an objectidentifier. This would be a good key for your user profile table so you can correctly identify a user on subsequent logins.

An alternative to the user profile table approach I just described that you may want to look into is the ability to extend the Azure AD schema using Graph API. I've not personally tried this technique yet. It's also still in preview. But, the general idea is you can register an extension for your intranet application that would include the additional properties for each user.