Building blocks of the authorization model

In the Integration Service framework the single services themselves knowingly do not postulate that there is any kind of hard wired relationship, say between documents and users (i.e. there is not a simple database table on the persistence layer which maps, let’s say, one document type to specific users). Role definitions will eventually handle authorization in the Integration Service.

Instead of attaching permissions directly to documents (a scenario which may be modeled by means of the Integration Service, but which is not hard coded) the basic idea is to attach permission functions (e.g. read, write or update) to queries and to combine the resulting constructs by role definitions.

Queries may either decide about a permissible result set of documents or they will deny permission for an operation. A great deal of the effort on authorization customization will therefore ascribe to devising appropriate queries in RAQL (introduced in the previous chapter Query language RAQL).

Queries will have to address entities from the ImageMaster document model. For an overview of such addressable entities see Addressable entities and operators in RAQL. Beside data from the persistence layer the query may evaluate information from the transient environment; typically a current user’s role, or an attribute of an incoming document.

The following sections will present the conceptions which stand behind the authorization model in ImageMaster and finally present example role definitions.