Another question from a colleague - what controls and options does Oracle IRM provide over the use of multiple devices? What happens if a user has a laptop and a PC and wants to use sealed content on both?
The Default Configuration
By default, each user can use one device at a time. The IRM Desktop provides the server with some information to uniquely identify the user's device. If the user connects from a different device, the server informs the user that their rights are already in use and declines to issue rights to the second device. Simple.
This device control helps prevent credential sharing. If the user gives their credentials to another user, or is the victim of key-logging or some other exposure of their credentials, the other user cannot simply contact the IRM Server and gain the benefit of the first user's rights.
This is an important control in many deployments, including publishing deployments where users might try to avoid paying for content individually.
Any attempt to share credentials in this way will show up in the audit trail. Some customers tell me that this constraint and auditability for multi-device usage is a key reason for choosing Oracle IRM.
So, Oracle IRM defaults to the most secure configuration - limiting each user to one device at a time.
The Catch with the Default
In many organisations, it is standard to have a desktop PC and a laptop. Users also need to be able to switch devices when, for example, they buy a new laptop.
The default configuration is good for security, but not always so good in usability terms. As always, our goal is to give you options that let you choose the right balance of security, usability, and manageability for your organisation.
Using Multiple Devices Despite the Default Configuration
Before discussing non-default options, what choices do you have with the default state?
- Wait for the offline period to expire on your first device. The server can issue rights to your second device as soon as the cached rights have expired on the first.
This is not ideal. In most deployments, the first device is constantly refreshing its offline period by synching regularly with the server. Even where this is not true, you might have to wait a couple of days or more for the offline period to expire.
- Manually check in your rights from the first device and then use the second device.
Checking in is easy enough, but it is preferable to avoid users needing to understand such details of the solution.
- Ask the administrator to check in your rights at the server end.
This caters for situations where, for example, you have lost your laptop and therefore cannot check the rights in from the desktop end. However, it adds to the management burden.
In all cases, these options enable you to switch from one device to another in a controlled, audited way, but the user is limited to one device at a time. Depending on your deployment, the default configuration could be undesirable, although it does help defend against password theft or sharing.
The Configurable Option
The Device Count parameter enables you, as a matter of service policy, to define how many devices users can use.
The server will issue rights to the specified number of devices per user, such that the above check-in options are rarely necessary - but there is still a limit.
The Device Count parameter enables a customer to define their own balance of security, usability, and manageability. By setting a limit of two or three, you enable legitimate usage of multiple devices and reduce the management burden. There is a slightly increased risk of account sharing, but it is defined by your policy and backed up by the audit trail. As a simple example, the following image shows that the user "mabrahams" is consistently using a device with an obviously corresponding name.
If you see evidence that "mabrahams" is using several different devices - some apparently belonging to other users - you might want to investigate. It would be pretty simple to write a report to flag up such evidence.
By contrast, some solutions offer no device control, or enforce a large, hard-coded device limit such as 25. Either way, you don't get to choose your own level of risk. In addition, audit facilities are sometimes very technical in content, requiring considerable expertise to identify potential abuse.