Offline Access Management for IRM Encrypted Documents
By Martin Abrahams on Jan 13, 2010
Perhaps the most frequent of frequently-asked-questions about IRM was put to me recently by one of my Irish colleagues:
If you have to get IRM decryption keys and access rights from an IRM server, how does that impact offline access to documents and offline creation of new documents? How do I ensure that business users can keep working when they are on customer premises, or sitting on a plane, or simply disconnected from the net for whatever reason?
All IRM solutions have, on the face of it, a similar answer: keys and rights may be cached for offline use for a defined period. Your cached rights enable you to keep working, but not indefinitely.
Offline access issues resolved? Well the devil is in the detail - and we believe that Oracle IRM offers the best available balance of security, usability, and manageability.
How so? First, let's consider how most solutions handle offline periods.
How Most Solutions Manage Offline Periods
With most solutions, every document is evaluated separately. So, when you first open Document-A, you contact the server and obtain the keys and rights for Document-A, and typically you are permitted to cache them for the offline period defined for Document-A. The clock starts ticking immediately for Document-A.
You then want to open Document-B, and you need to contact the server again because opening Document-A has no bearing on whether you can open Document-B - even if the two documents are supposedly subject to the same policy. Having been authorised to open Document-B, the clock starts ticking for Document-B. And likewise for Document-C and so on for each document you access. So, you have contacted the server several times, and now have cached rights and keys for several documents, and independent timers running for each.
The repeated communication with the server highlights a key shortcoming of most solutions. Users need to be online to gain access to each document on first use - and again when revisiting documents after the expiry of their offline periods. This constant per-document evaluation generates a lot of network traffic, and takes place even if exactly the same policy is defined for each document. Each document needs to be evaluated individually.
The fact that each document has its own timer makes it difficult for users to be confident that they will be able to work offline, and causes frustration when some documents turn out to be inaccessible even though the user knows that they are authorised.
Of course, user frustration leads to users bypassing a solution if they can - for example, by choosing not to protect documents due to the inconvenience this entails, or copying information out of documents so that they have an unprotected copy to work with.
But it doesn't end there. The natural user response to the inconvenience of the offline rights expiry is to specify a long offline period for documents that they protect. Long offline periods means less frequent inconvenience.
This pragmatic user behaviour reduces security for two reasons:
- Users may continue to use cached rights for a considerable period after rights are revoked on the server
- Routine policy changes take a considerable time to propagate out to all affected users because they may only refer back to the server once their cached rights have expired, which might be weeks after a policy change is configured
Most customers want to know that policy changes will be effective in a short space of time, but the user pressure for a long offline period conflicts with this requirement. Indeed, the fact that many solutions invite users to specify offline periods to suit themselves is a security and management shortcoming for many customers.
Another consequence of unpredictable, per-document timers is that users may have to make manual preparation to go offline. Rather than simply go offline, you might be expected to do a manual synchronisation step first, or required to explicitly notify the server that you are about to go offline and want to be able to work on certain documents. In practice, users won't remember to do this, and those who do remember will not appreciate the added chore.
Other attempts to address this issue involve nominating particular folders in which you will keep the documents that you want to be able to use offline, and have the IRM client software pro-actively manage rights caching for those documents. Sadly, again, users tend not to cope well with mechanisms that require them to keep things in particular locations, and there is a scalability issue if large numbers of users keep large numbers of documents in such folders.
Further, with most solutions you can only apply one offline period to each document, and some solutions require you designate documents as usable offline or only online. There is often no mechanism to differentiate between users according to role. So, if you want to offer a lengthy offline period to your most trusted users, you may have no choice but to give the same period to less trusted users.
As a related issue, with some solutions, a user will find they also need to be online when they want to apply protection to a new document. Setting up the policy and keys for the new document requires communication with the server. This leads to more frustration and, inevitably, leads to documents remaining unprotected.
So, How Does Oracle IRM Differ?
Firstly, Oracle IRM allows a single timer to run for all of the documents in a given classification. This immediately improves the predictability of the user experience. When you open Document-A, you start a timer for all documents in the same classification.
This massively reduces network traffic, and means that you do not need to be online every time you try to access a new document. Worst case, you need to be online when you encounter a new classification of document - there are far fewer of those, and we address even that potential frustration as described below.
Next, the offline period is defined as part of a user's role in each classification - different users get different offline periods for the same documents. So, your most trusted users can be given a role with a lengthy period, while less trusted users can be given a role with a short period.
Crucially, our policy model makes the entire policy set small enough for the IRM Desktop to support regular rights synchronisation for ALL of a user's rights IN ADVANCE of the user actually trying to open any documents, and to synchronise any policy changes pro-actively rather than when the offline period expires for various pieces of content.
In practice, this typically means that policy changes are propagated within 24 hours rather than several days or weeks. And this synchronisation is for ALL documents - not just the ones that the user has remembered to keep in a particular folder, or has nominated in some other way. Synchronisation a transparent process, making the solution significantly more user friendly. Users don't need to do any preparation to use content offline - they just pull the cable and go.
Automated synchronisation also means that whatever your offline period might be for a particular classification, it is regularly "refreshed" so that you don't have to worry about your rights expiring at an inconvenient time. So there is no conflict between users wanting a long offline period and security officers wanting a short offline period.
Finally, our solution does not routinely invite users to choose the offline periods to suit themselves. Offline periods are defined as part of a policy framework. This reduces variability, and removes a potential conflict between users and security officers.
For many solutions, particularly when used at scale, offline access creates significant frustrations and challenges for both business users and security officers. Oracle IRM's unique approach makes it significantly easier to balance usability, security, and manageability even for large scale deployments.
By the way, anyone using the IRM evaluation service is subject to a 3 day offline period, with daily synchronisation during office hours. The majority of those users will be blissfully unaware of this - which is precisely the point.
I hope this article has helped you understand Oracle's position on one of the most frequently asked questions. If you have any questions, feel free to drop us a line.