Develop Reference

On Claims based security the roles can be stored on User or on Object?

In a claim-based authentication can Roles reside on the Object instead of the AspNetUser entity in Identity on .Net Core ?
Imagine I would like to implement the Claims-based authentication and I have the scenario like below:
Each entity has always the One-To-Many relation with the entity on the right. One Institution can have many Courses, each Course can have many Subjects, each Subject can have many Syllabus, etc...
There are 3 Roles: Administrator, Contributor, Viewer
If you have a Role in one of the top entities this role will be propagated to the rest bellow. E.g: If you are an Administrator of Course you are administrator of Subject, Syllabus, etc...
Initially it was implemented in a way where Course has CourseRoles, CourseRoles has records with UserId and RoleId.
Subject has SubjectRoles, and so on...
Is it in accordance with Claims-base authentication?
I just firgured out there is something wrong when I tried to use Policy and this situation happened in here: Adding .Net Core Policy with variable Parameters on Requirements

How do I design the retrieval and processing of all user roles?

I am building an intranet with ASP.NET core 2.0 MVC. All users are part of an active directory. Additionaly I have a MSSQL database with the following tables:
Users (Id, FirstName, UserNameAd (unique), ...)
Roles (Id, RoleName)
UserRoles (User_Id, Role_Id)
In my web application I now want to retrieve the roles of a user and store them in the Authentication/Identity Classes of Microsoft in order to use [Authenticate(Roles="Admin")] stuff. I am not sure where I shall put this role-request and what is the best practice. It is possible that a user gets a new role during the day or that a role is removed during the day and I actually do not want the user to click something specific or need him to restart the browser in order to get the new roles applied - thats why I think that the roles need to be requested with each server-action (POST, GET) from the server.
Any idea or link to a good tutorial would be highly appreciated.
Also if you think my approach is not good practice and you have a better idea I would be happy to know.

After a lot of discussions and researches in the internet i came to the conclusion to chose pure windows authentication.
It works out of the box and you can already use the active directory groups as roles with [Authorize(Roles = "ADGroupName")] which is really straightforward and nice.

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));

How do I link ASP.NET membership/role users to tables in db?

I am going to use forms authentication but I want to be able to link the asp.net users to some tables in the db for example
If I have a class and students (as roles) I'll have a class students table.
I'm planning to put in a Users table containing a simple int userid and ASP.NET username in there and put userid wherever I want to link the users.
Does that sound good? any other options of modeling this? it does sound a bit convoluted?

Basically, the ASP.NET membership service creates a GUID per User, so if you need to have a foreign key of the user in a table, then this is what you should use. As such, you will not need the mapping table of a username to a userid as you already have a unique identifier per user (the aforementioned GUID)
If your looking to extend the amount of information one can store against a user, then this link has all the details regarding that.

If you're going to use ASP.NET membership, you should create the users with the ASP.Net Membership classes and database tables. This will create a user in the dbo.aspnet_Membership with the appropriate roles set for that user, upon successful insertion into this table, you can get the UserId from the dbo.aspnet_Membership table.
In YOUR Users table create a table with an int(auto-incrementing) ID, and also create a membershipID field in your table(rather than username) of type uniqueidentifier called say, membershipID. This is where you would store the value from the aspnet_Membership table to link the two together. You should also put a foreign key relationship on your membershipID field for referential integrity.
EDIT: Just to clarify with the other posts, id is of type GUID in your ASP.NET code, and of type uniqueidentifier in your SQLServer database.

We did this for a system where we retro-fitted forms authentication into a system using another authentication system. We added a column to our existing user account table. We added a GUID column, since this is what the aspnet_xxxx tables use, and filled it with the GUID from the aspnet tables. We then wrapped creation of our entry in our table into a transaction dependant upon the success of account creation using the asp.net membership calls. It's very important to make sure you sync the tables together with a transaction or something to make you don't have entries in one system and not in the other.
I'm not 100% sure, but I think that usernames can change so you shouldn't use that to link your systems. Use the GUID.
Hope this helps

Something really confusing about how roles and membership tables establish a relationship

I know how to create users and assign them to roles etc, but when I tried to dig a bit deeper into how roles and membership tables are able to establish a relationship between each other, I got totally lost ( BTW – I do know how foreign/primary keys work ;) )
BTW - I've created tables in databases using aspnet_sqlreg wizard
Q1 - Both SqlRolesProvider and SqlMemebershipProvider have a property ApplicationName. I thought that in order for the two providers to be able to create association between their users and roles, they would both have to use same value for ApplicationName property. But that doesn’t seem to be the case.
A) Anyways, I assume that SqlRolesProvider.ApplicationName property is only used to distinguish between table entries belonging to different role providers, but they don’t use that property in order to associate their roles only with membership providers with the same ApplicationName value?!
B) But wouldn’t it be most practical if roles providers could only be associated with membership providers with the same ApplicationName value ( thus where SqlRolesProvider.ApplicationName == SqlMemebershipProvider.ApplicationName)?!
Q2 - I was also curios whether roles and users could be associated if roles provider was connected to DB1, while membership provider was connected to DB2. Somehow I was still able to assign users to different roles, even though roles were defined in different database.
A) But why is that? Namely, if SqlRolesProvider.ApplicationName = “rolesP” ( ApplicationID=10 ) and SqlMembershipProvider.ApplicationName = “membership” ( ApplicationID=100 ), then in order for the table in DB1 to have relationship with table in DB2, the two would have to reference each other via ApplicationName entry ( actually via ApplicationID), which would act as foreign/primary key.
But the thing is, none of the foreign key fields in DB1’s tables holds a value equal to SqlMembershipProvider.ApplicationID = 100, which would suggests that there is no relationship established between tables in DB1 and DB2 ( I know that is not the case, since I’m able to assign users to roles ). So what am I missing?
thanx
EDIT:
Uh, don't know if anybody will still be reading this, but I did some more digging and got even more confused:
If both roles (with applicationName=R1 and applicationID=10)and membership provider(with applicationName=M1 and with ApplicationID=100) are in same DB, then creating a new user causes aspnet_Users table two create two entries for same user name– one with ApplicationID=10 and other with ApplicationID=100. As far as I know, when new user is created, only one field ( with ApplicationID=100 )should be added to aspnet_Users. Uh?!

Have you looked at the aspnet_UsersInRoles Table. This is the table that links the user to the role. The RoleProvider is designed to be separate from the MembershipProvider so that you can have them in separate DB's. Additionally it allows for you to set up roles for one application name and re-use those roles in two separate applications that each have a different application name for the membership provider. Don't get stuck in the mentality that you have to have the same application name for both providers or that your application name needs to match the running application. You don't need to have any name at all if you don't want to. I hope that this helps.

I had a hard time following what you were saying...
Anyway... you seem to be looking at the database too much. Have you configured the web.config for your membership providers and were you able to query "Membership" using C# and NOT SQL queries?