Question

I am working on an ASP.NET MVC5 web app that has the following relevant properties:

  • Uses MVC5.1, Identity 2.0, not restricted to any legacy stuff - can use newest everything.
  • A user belongs to at least one organization.
  • Each organization has at least one user that is an organization admin.
  • The organization admin can allow users specific rights, such as becoming another organization admin.
  • From what I have understood, a good way to handle this would be to use claims.

In addition to the default claims, a user could then typically have the following claims:

Organization: {some guid} Organization-Admin: {same guid as above} Organization-Publisher: {same guid again}

There could potentially be super-admins, or even super-users, with claims giving them access to different roles in multiple organizations.

Now, lets imagine I am user admin logged on to my administration panel, and I want to grant user user the Organization-Publisher claim for an organization that I have the Organization-Admin claim for.

For simplicity, I have a model object that would look something like this:

public class GrantRightModel
{
   public string OrganizationId { get; set; }
   public string UserId { get; set; }
   public string Right { get; set; }
}

and for the purposes of this example, we get the following values from our admin user:

  • OrganizationId: The GUID of an organization that admin has an Organization-Admin claim for.
  • UserId: user
  • Right: Organization-Publisher

There are a number of things that have evaded me about this way of doing things. Lets say we have an OrgAdmin controller with a GrantRight action;

  • Will the controller action need to check that the currently logged in user (found using for instance ClaimsPrincipal.Current) has the Organizaton-Admin claim for GrantRightModel.OrganizationId "manually", or are there clever auth attributes for this kind of thing?

  • What is the correct way in code to add the Organization-Publisher: {guid} claim to user? My controller will get a UserManager as necessary by dependency injection.

  • If user is signed in to the application when this happens, is there a way to have him automatically have the correct claim starting with his next request? I've seen mentioned ways to do this that would cause the user to be logged out, so that he would log in again and start a fresh session with his new claims. I see why that is the way it is, but given that the user could be working on something that takes a lot of time, it might not be popular to just have him logged out when he tries to submit his work.

There is a bit of information on this on the web, but my google-fu has failed me in finding the one that shows me how to beat these three points.

Anyone?

Thanks!

Était-ce utile?

La solution

Regardins your questions.

Will the controller action need to check that the currently logged in user (found using for instance ClaimsPrincipal.Current) has the Organizaton-Admin claim for GrantRightModel.OrganizationId "manually", or are there clever auth attributes for this kind of thing?

No. The Authorize attribute takes an optional list of roles that are checked upon authorization. If one of role claims points to that role, used is authorized with no custom code involved.

What is the correct way in code to add the Organization-Publisher: {guid} claim to user? My controller will get a UserManager as necessary by dependency injection.

You create the ClaimsIdentity with proper claims and then ask the authorization manager to sign in used with the identity. The identity is typically then persisted in a cookie together with claims.

If user is signed in to the application when this happens, is there a way to have him automatically have the correct claim starting with his next request? I've seen mentioned ways to do this that would cause the user to be logged out, so that he would log in again and start a fresh session with his new claims. I see why that is the way it is, but given that the user could be working on something that takes a lot of time, it might not be popular to just have him logged out when he tries to submit his work.

I've read it twice and don't quite get it. When you issue a cookie, the cookie is responsible for retaining the authenticated session. Claims are then rebuilt early in each request pipeline based on the cookie. Numerous requests can be then issued by the user and he is still "logged in" as long as the cookie is not invalidated or the auth token stored in the cookie expires.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top