Identity: Group Based Permission Assignment

[mmgafri]

in projects with complex roles & claims assignment between multiple departments it is difficult
to assign roles and claims to individual users and ineffective when the user counts increase over time.

therefore, major enterprise apps rely on security groups by creating a group for a set of users
and assign roles and claims to group. Then start enrolling users to group

this approach makes administration more efficient

in case of role conflict between groups assigned to a single user, a policy of either highest or lowest
privilege is assessed to resolve conflict

http://typecastexception.com/post/2014/02/19/ASPNET-MVC-5-Identity-Implementing-Group-Based-Permissions-Management-Part-I.aspx

this implementation is demonstrating the benefit of group based security

if this feature is implemented within identity 3, enterprise developers won't roll out custom implementation for their apps and avoid fragmenting security handling for unresolved vulnerabilities.

this concept is the same as windows domain security groups which make domain administrators life easier than ever.

[xivSolutions]

Hi -

Author of that post here. I should note for the record that that implementation is a bit of a hack. I needed it to solve a specific problem, but my understanding is the Identity team has determined that in-built group management is outside the scope of the basic Identity implementation. The way I did it was useful in my own context, and perhaps others, but can still become a permissions management PITA (and should have used claims, anyway).

Glad you found the post useful, but don't be surprised if this issue gets closed out. See this issue among others. :-)

[mmgafri]

I admire the effort you put to implement groups back in identity 2 . The problem you solved was
a decision factor for systems architectures in business environment. Therefore, we can say it is
more generic than specific due to scalability nature of user authorization in business environment
where user turn over is common to happen .
while my argument here is lacking this implementation in identity 3 will make important
segment of enterprise developers move away from adopting identity 3 and seek custom approaches.

this create a security vulnerable gap in applications developed using ASP.NET 5.

identity 3 is versatile product that addresses and solved many draw backs of legacy membership and simplemembership and universal providers

the addition of claims to identity was a response to demand from cloud services auth that is based mainly on claims instead of roles. therefore identity was adopted by cloud-focused developers.

this is the same case. enterprise developers are moving away for lacking of groups in my opinion.

Implementation can be injected in small portion of current code and will take identity3 to a new level
of functionality

[rustd]

Closing as duplicate of https://github.com/aspnet/Identity/issues/545