Importance of hostnames for IRM production servers
By Simon Thorpe on Sep 16, 2009
During the installation phase of an IRM server for production use there are important prerequisite steps that must be performed to ensure the system is to work flawlessly. Making sure the firewall has rules to allow communication to and from the public internet to the IRM server, attaining access to the database and assigning IP addresses to the IRM server's public network interfaces are all key to allowing successful communication to the server from anywhere the sealed content may travel.
The most important of all these steps, and it cannot be stressed enough, is the registration and use of the fully qualified hostname for the IRM service itself. During the installation of the IRM server and the Management Website you are asked for some hostnames which are then inserted into every single piece of content you secure with IRM.
Fully qualified hostnames in use
When a user attempts to open a sealed document, the Oracle IRM Desktop first reads the unencrypted (but signed) header which contains a URL back to the server that secured the document, this URL typically looks like;
Oracle IRM 10g: seal://irm.domain.com:80
Oracle IRM 11g: https://irm.domain.com/irm_desktop
The desktop then attempts to connect to the server by resolving the hostname to an IP address and then making a connection to the server over a secured protocol. If communication is successful and the IRM Desktop can authenticate the user, any valid rights are then sent to the user allowing them to open the content. At the same time the URL for the IRM server is added to the sync list so that the IRM Desktop can transparently ensure these rights are updated on a schedule as defined by the same IRM server.
Therefore for every copy of every sealed document, every initial online access to that content, for every subsequent transparent sync, the hostname back to the server is referenced. If the client cannot resolve that address, it cannot give access to the document.
Of course if you have successfully synchronized rights and are offline, then you don't need to rely on this chain of events because your offline cache has the rights to content. But this usability feature doesn't detract from the importance of these hostnames.
Management Website hostname is just as important
What if you can't communicate to the IRM server? What if you can, but your credentials cannot be authenticated, or you don't have rights to the document you are trying to open? The IRM Desktop will then attempt to redirect you to the status page for the classification of the document you are opening. How does it know where this online status page is? Exactly... it is also sealed into the content and in Oracle IRM 10g it typically looks like;
Clicking on the above link takes you to an example of the sort of page you would see when the IRM Desktop fails to connect to the IRM Server.
Note that with Oracle IRM 11g the URL to the service for getting rights is also the same URL for the out of the box status pages, unless of course you design your own and override the defaults.
So during the planning and installation phase of your production IRM service, the choices and management around these hostnames is critical for long term success. The following are common scenarios in how these hostnames do actually resolve back to the server.
- Hostname resolves to one address no matter where the request comes from. This address is the internet facing interface. So if you try to access content from the internet, or the corporate network, the traffic always goes via the public internet IP address.
- Hostname resolves to a different address depending on where the request was made. So for those on a public network, they resolve the hostname from a publicly visible DNS server to the publicly listening interface. A request made from the corporate network is resolved from a corporate DNS server to a different IP that is listening on the internal corporate network.
- Sometimes if the IRM server is protecting very sensitive information then access to it may be limited purely by a VPN or other tightly controlled network route. Therefore the hostname to the service can only be resolved from a specific set of name servers that are only accessed from a virtual network.
Sometimes you may use option 3 above for access to the IRM server, and yet have the Management Website publicly facing. Then when users get the "Cannot connect to IRM server" as in the above example, the web page can inform them they must be connected to the corporate VPN. This is a nice example of how Oracle IRM is both secure and yet easy to use for authorized end users.
No matter what method is employed to manage the resolution of the hostnames, the fact remains you must be diligent in managing the names such that they always resolve to the IRM service when users attempt to open sealed documents.