The way we allow developers to model this sort of thing out at Stormpath (<a href="https:&#x2F;&#x2F;stormpath.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;stormpath.com&#x2F;</a>) is via Applications, Organizations, Directories, Groups, Accounts, and CustomData.<p>Those are the top-level resources we make available for &#x27;modeling&#x27; authorization stuff.<p>Here&#x27;s how it works (you can replicate this sort of setup in your own systems if you want):<p>A Directory is a &#x27;bucket&#x27; of Accounts, that is unique by email &#x2F; 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.<p>An Application is a collection of mapped Resources. So, let&#x27;s say you have an Application for each website you run. You could choose to:<p>* 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.<p>* 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.<p>* Map other resources Directly (Groups &#x2F; Organizations).<p>You&#x27;ve also got the Organization Resource, which is basically a &#x27;Tenant&#x27; -- used for designing multi-tenant systems. Each Organization can have multiple Directories &#x2F; Groups mapped to it directly, and Authentication &#x2F; Authorization checks can be done against the Organization endpoint directly to control behaviors.<p>Then, you&#x27;ve got the Group Resource. This basically is a label that you can use to form Many-to-Many relationships between Accounts and Directories.<p>So, let&#x27;s say you have a Directory with all your website users inside of it. You could create the Groups:<p>* Admins<p>* Super-Admins<p>* Developers<p>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.<p>Finally -- you&#x27;ve got this big blob of JSON we call &#x27;CustomData&#x27;. This is a Resource that is attached to <i>every other Resource in Stormpath</i>.<p>In CustomData, you can store things like claims &#x2F; permissions. For instance, if you have an Account object, you might store some permissions like so in your Account&#x27;s CustomData store:<p>{
  &quot;can_read&quot;: true,
  &quot;can_write&quot;: false,
  &quot;can_delete&quot;: false
}<p>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.<p>If you&#x27;d like to chat about this at all, or would like to just email me some suggestions or whatever, I&#x27;m totally open to feedback! randall@stormapth.com