The way we allow developers to model this sort of thing out at Stormpath (https://stormpath.com/ https://stormpath.com/) is via Applications, Organizations, Dir

The way we allow developers to model this sort of thing out at Stormpath (https://stormpath.com/ https://stormpath.com/) is via Applications, Organizations, Directories, Groups, Accounts, and CustomData. Those are the top-level resources we make available for 'modeling' authorization stuff. Here's how it works (you can replicate this sort of setup in your own systems if you want): A Directory is a 'bucket' of Accounts, that is unique by email / username. This way, you can segment users into Directories however you wish. If you were running 3 sites with entirely separate user bases, for instance, you might have 3 separate Directories, one for each underlying website. This way each site has its own unique group of users. An Application is a collection of mapped Resources. So, let's say you have an Application for each website you run. You could choose to: * Map a single Directory to each Application. This way, when a user authenticates against your Application, their credentials will be checked against a single Directory of Accounts. * Map multiple Directories to each Application. This way, when a user authenticates against your Application, their credentials will be checked against multiple Directories of Accounts. * Map other resources Directly (Groups / Organizations). You've also got the Organization Resource, which is basically a 'Tenant' -- used for designing multi-tenant systems. Each Organization can have multiple Directories / Groups mapped to it directly, and Authentication / Authorization checks can be done against the Organization endpoint directly to control behaviors. Then, you've got the Group Resource. This basically is a label that you can use to form Many-to-Many relationships between Accounts and Directories. So, let's say you have a Directory with all your website users inside of it. You could create the Groups: * Admins * Super-Admins * Developers And assign Accounts to those Groups as needed. When a user is retrieved, you can then pull from their Groups, or vice-versa, to control Group-level information. Finally -- you've got this big blob of JSON we call 'CustomData'. This is a Resource that is attached to every other Resource in Stormpath. In CustomData, you can store things like claims / permissions. For instance, if you have an Account object, you might store some permissions like so in your Account's CustomData store: { "can_read": true, "can_write": false, "can_delete": false } By doing a union of CustomData, Groups, Accounts, Directories, and Organizations (each of which have their own CustomData), you can essentially model out very complicated User Authorization patterns across your code base in a pretty dynamic way. If you'd like to chat about this at all, or would like to just email me some suggestions or whatever, I'm totally open to feedback! randall@stormapth.com