Trouble migrating to Asp.Net Identity/OWIN

Question

We have our own db already, with users , roles , userrole tables already in place, and just have discovered the Identity system in .net. I would like to integrate the application cookie authentication but having trouble understanding the different concepts in this Identity model. The OWIN adapter that allows to integrate to third-parties isn't necessarily needed. As we don't need to integrate with third-parties, we just need internal encrypted cookie authentication off our system, that is all we're really looking for.

---

Can someone help me grasp the concept behind these models? I've read about each of them and still am left confused about them.

Currently I see a number of Identity models: Users, Logins, Claims, Roles

• Would my roles table use the Roles or Claims model?
• There are Logins and Users , but we only have one login per user. What would be done in this case?
• Do I need to use OWIN? I don't need third-party integration, and it looks really heavy.
• If a user has certain arbitrary properties (avatar, age, etc.), where would this be stored?
• Any other suggestions on integrating our own table/structure into the Identity model?

The sample tables which the startup app creates are much more complex than needed. Since we don't need many of the features, granted its nice they are already there, but 2-form authentication, sms verification ,etc. all isn't needed. This is an internal system.

I've spent this last week trying to grasp this model and am still having trouble. If someone can point me to the right direction it would be helpful.

Answer 1

Users are pretty straight-foward, so we'll skip that. Logins are external authentication attachments. Based on the way Identity works with third-party authentication providers, you can have logins with no attached users, users with no attached logins, or users with attached logins. It's the difference between be authenticated with your site (login) and being an register member of your site (user).

Claims are just data associated with a user. Generally, these are going to be transient - things which don't make sense to be stored in perpetuity on the user For example, third-party auth tokens that expire would not make sense to be actually saved to the user in a database.

Roles are just permission sets. People go different ways with roles, but technically speaking, a role just defines some ability a user may have, like "CanEdit", "CanView", "CanDelete", etc. You'll often see people use them more as groups: "Admin", "Editor", "Contributor", etc., which abstractly define user permissions.

OWIN is a core component of Identity. It's not really something you can pick or choose. If you don't want to use the third-party auth functionality, then don't, but having it included is not an issue.

Finally, Identity is rather opinionated. It's possible to migrate your user data into Identity-specific constructs, but it would be virtual impossible to have Identity just use your existing user tables in place. I'm not sure if that's what you actually meant, but if it is, forget about it. You can customize the individual Identity models to include more information in the database, but generally, you'll need to find a way to map your data into what Identity provides if you want to use Identity.