A client sends a request for the data - this request intercepted by some sort of enforcement mechanism (a Policy Enforcement Point (PEP) in the lingo). A co-located Policy Decision Point (PDP) determines which policy is relevant for the requested data, and interprets that policy to make a decision whether to grant the request or not. If the decision is 'yes', the data is served up back to the client (either as HTML or JSON depending on the nature of the client).
All good, but as soon as you allow the business data, once released by the server, to be stored by the requesting client beyond the original session, then the original access control check is no longer sufficient and must be supplemented. Despite the additional complexity, mobile native applications and enabling offline usage (the 'CEO sitting in seat 3B' use case) push the enterprise towards supporting this sort of client storage.
The Mobile Information Management (MIM) proposition is that the business data delivered down to the clients (the native applications) carries with it (implicitly or explicitly) the policies governing its access & usage - reminiscent of DRM. Before the data is delivered down to the mobile client, appropriate policy is bound to the data - the policy will stipulate what users and/or applications can access the data, what they can do with it, and restrictions on subsequent sharing. Once on the device, only if the policy stipulations are met will the data be made accessible to particular applications, and what they subsequently do with that data will also be accordingly constrained.
But merely attaching some rules to a document or powerpoint (PRISM anyone?) doesn't actually restrict access to that data. It would be a polite hacker that, seeing a rule forbidding her access, respected that rule. There needs to be a mechanism on the device comparable to the PEP in the diagram above to enforce the policy, ie prevent all data access unless the policy is met.
You also need something comparable to the PDP to read & interpret the policy associated with a given piece of data. But whereas in the above model, the policy decision was whether or not to release the data itself, in this case the data has already been released, it's already on the client after all. So what is the decision?
In MIM, the policy enforcement mechanism (the PEP that prevents unauthorized access) is appropriate encryption of the data, and the policy decision (made by the PDP determining what is authorized access) is whether or not to release a key that can be used to decrypt the data.
An abstract model is shown below
On the right is some piece of business data, encrypted to prevent just anybody who has access to the device on which it sits from being able to access the data. On the left is a decryption key that will decrypt the encrypted data and so make it accessible to application usage. For an application to be able to 'get at' the data, it will need to gain access to the decryption key.
Sitting between the two (the encrypted data and the corresponding decryption key) is the policy enforcement & decision infrastructure that ensures the two will 'meet' if and only if the policy is satisfied. Policy associated with the encrypted business data stipulates under which contexts the decryption key can be released, as well as additional constraints should that happen. Taken as input to the 'key release' decision are all the various current contexts, ie what app is trying to access the data, one behalf of which user, when, where etc.
If the policy decision is 'yes', then the PEP releases the decryption key to the application, along with additional constraints (read but no right, no sharing etc). Now armed with the decryption key, the application uses it to decrypt the data and does whatever it does.
The above is abstract, how to make it concrete? Specifically
- how is the policy bound to data?
- how & where is the data encrypted?
- with which key?
- how & from where is the decryption key obtained?
- how are PEP & PDP roles distributed?
Next time I'll propose an architecture for the above that leverages
- REST APIs
- OAuth & OpenID Connect as mechanisms for authenticating & authorizing clients to such APIs
