How to use Group to Authorize

[mwpowellhtx]

I see in a couple of spots where you call out "Admin" for purposes of Role-based Authorization. But I do not see where you incorporate Group in any authorization handshakes. Have I missed something, or is that handshake TBD? Via the AuthorizeAttribute mechanism? Or other Startup request pipeline?

[xivSolutions]

The handshake, in this instance, is still at the Role level. I imagine any of the areas you mention could be used to modify it for this purpose. However, this was only ever a "poor-man's" quick-and-dirty grouping mechanism. In this case, the authorization "permissions" are still based on Roles, but roles can be grouped.

I suspect ultimately better results could be achieved by moving to claims-based auth.

[mwpowellhtx]

I get that. I started approaching it a similar way. In fact, calling Credential my base class for both Users, "implementing" Identity.IUser, and Groups, (loosely) implementing, though imperfectly, Identity.IRole, with connecting objects such as Permission and Membership among them and Feature. Although in hindsight I can see some wisdom treating the controller methods and/or whole controllers themselves, as features, to a degree.

I got only so far with that approach under those assumptions when I bumped into pervasive assumption that System.String is the key, when I want System.Guid. It's simple enough to inject Guid, when I bumped into the Identity.EntityFramework.UserStore monster, which closest version I wanted takes TUser, TRole, TKey, TUserLogin, TUserRole, TUserClaim. Admittedly, I will be using Fluent NHibernate for my data layer, so not as concerned about that version, per se.

It's also interesting to note, the MSDN does make the statement, "Think about claims the same way you think about attributes in a central repository such as Active Directory, over which you have little control. Security tokens can contain claims such as the user's name, email address, manager's email address, groups, roles, and so on", but I am not certain at the moment what they mean by modeling "groups", as it were. Which I suppose is that the application service(s) themselves are the "provider" making the claim? Not sure yet.

The thing I don't like, detest it, is that Authorize is hard coding Roles as comma-delimited string literals. Surely there must be a better way to capture that.

I haven't read more deeply into that, yet.

[mwpowellhtx]

Thoughts on UserStore, in particular on IdentityUserClaim, at least the one described by the EF version of the Identity model? My first impression is, how is an int Id that extensible? If I've got a modest set of groups, features, etc, captured in my claims, that's going to blow up under stress of large number of users, clients, subscribers, after awhile.

    public class UserStore<TUser, TRole, TKey, TUserLogin, TUserRole, TUserClaim> : IUserLoginStore<TUser, TKey>, IUserClaimStore<TUser, TKey>, IUserRoleStore<TUser, TKey>, IUserPasswordStore<TUser, TKey>, IUserSecurityStampStore<TUser, TKey>, IQueryableUserStore<TUser, TKey>, IUserEmailStore<TUser, TKey>, IUserPhoneNumberStore<TUser, TKey>, IUserTwoFactorStore<TUser, TKey>, IUserLockoutStore<TUser, TKey>, IUserStore<TUser, TKey>, IDisposable
        where TUser : Microsoft.AspNet.Identity.EntityFramework.IdentityUser<TKey, TUserLogin, TUserRole, TUserClaim>
        where TRole : Microsoft.AspNet.Identity.EntityFramework.IdentityRole<TKey, TUserRole>
        where TKey : System.IEquatable<TKey>
        where TUserLogin : Microsoft.AspNet.Identity.EntityFramework.IdentityUserLogin<TKey>, new()
        where TUserRole : Microsoft.AspNet.Identity.EntityFramework.IdentityUserRole<TKey>, new()
        where TUserClaim : Microsoft.AspNet.Identity.EntityFramework.IdentityUserClaim<TKey>, new()

I could be wrong.

I'd like to back out of the EF stuff and just roll my own extensible Identity model, including the claims.