Include user's Omeka permission level in JWT

[akstuhl]

As a Neatline user, I want the front-end application to be able to reflect the permission level associated with my user account in the containing Omeka S instance. This information should be included in the JWT payload passed down to the front-end app.

[akstuhl]

There's a design decision to made / worked out in between this issue, #27 (permissions mapping) and #5 (site-scoping), since Omeka has both permissions at the instance level and permissions at the site level (e.g. I can have an 'editor' permission level for the instance but an 'admin' level permission for a particular site within that instance, if I'm understanding correctly). See these documentation pages on user roles and on site permissions.

Some Neatline use cases:

• As an admin or editor for a site, I want to be able to create a Neatline exhibit while loading the Neatline app inside that site's container; but I should not be able to create Neatline exhibits if not scoped to that site.
• As an admin or editor for both Site A and Site B, I want to be able to associate a Neatline exhibit created under the scope of Site A with Site B so that it appears when viewing the Neatline app in either side. I should not be able to do this for sites where I am not an admin/editor, but I should be able to do this for any site/exhibit if I'm a global admin for the instance.

So in most cases it seems like what we'll really want to know is the authenticated user's permission level for the site under whose scope we're encountering the app. So it may be useful to include the user's instance permission level, the site ID for the current scope, and the user's permission level for that site, all in the JWT payload.

[jamiefolsom]

@tezcatlipoca this is something for us to discuss with @jeremyboggs and @ZoeLeBlanc and co. Seems to me that we should support the most common use cases within Omeka, but that we don't want to tie Neatline's permissioning too narrowly to the specific authorization scheme of Omeka S.