Ok, so very busy end of the year (Oracle Q4 just ended) and i'm really sorry for a lack of activity on the blog. There is some very interesting news on the way however and things are going to liven up significantly... watch this space...
In the meantime a question came through on the grapevine regarding the status pages in Oracle IRM. These are HTML web pages that are displayed to an end user when they don't have access to sealed content or they are for some other reason unloading a sealed document. Our mantra that security is nothing without an adequate user experience and a manageable administrative model is reinforced by these very flexible status pages. So often a security product will deny you access to a file, directory or other resource and all you get is an "Access denied" error with an OK button. Oracle IRM however sends the client to a web page of your choice to display a more informative error message, like the example below.
Out of the box Oracle IRM gives you a set of standard pages which look like the above. These can be customized at three levels. Actually before I go into the customizations its worth knowing of a simple test page that allows you to look at all the possible status codes and pass in some data to see how they render. You can look at our evaluation server test page here.
Basic changes to status pages
| Logging into the Oracle IRM Management website and clicking on "Settings" presents you with the dialog below. The first step here is that you can change the organization name that is displayed on the status pages. Not exactly the most uber of customizations, but you have to start somewhere right? You can also change the logo used on the pages to your own, simply replace the org_logo.gif in the folder \smweb\custom. More detail on this can be found in the Oracle IRM core customization guide. |  |
Modifying the distributed web pages
Further reading of the document above details more files you can customize.- support_contact.htm This file, by default, contains a single line of HTML which is a HREF that contains two macros that are place holders for the system email address as per the settings dialog above. This line is then displayed on certain status pages. You can modify this line as you wish, just be careful to ensure whatever HTML you drop in plays safe with the rest of the page. You can see an example of where this would get used here.
- footer.htm and header.asp allow you to again modify the HTML that is displayed top and bottom of the status page.
- default.css means you can really go crazy with these status pages. There is a good set of style declarations already in this file so you've got a nice place to start from.
- Finally there are a set of folders for English, German, Spanish, French and Italian versions of the website homepage. Sometimes the Oracle IRM Desktop will instead of sending you to a status page will redirect you to the basic homepage of the website and depending on the language version of the IRM Desktop you'll see the relavent file from these folders. It is often a good idea to reinforce your corporate security policies on these home pages and maybe link to other resources that an end user would find useful. Remember making the end user experience as smooth as possible is crucial to your security strategy.
Creating your own status pages from scratch
The Oracle IRM Management website has a bunch of logic which you could go changing the ASP pages if you wanted, but you'd be out of Oracle support. Sometimes customers want to do something very different and instead of using these provided files they want to write their own from scratch. This is entirely possible and to venture down this path requires knowledge of the following concepts.- default URL. Every file that is sealed has embeded in it something called the default URL. This is the address which the Oracle IRM Desktop will redirect the end user to when they are unable to open a sealed document. The URL typically looks like this;
http://irmweb.domain.com/status/default.asp?%%allparams%%&%%usefordefault%%
There are two very important macro's that sit on the URL. These macros are replaced by data during runtime when the client decides to send the user to the website.- %%usefordefault%% means that the IRM Desktop will always send the user to the website. There are also some offline HTML pages that are displayed in place of the online website when the user is not connected to the internet. If you were to remove this macro, even when the user is online they would be shown the offline pages, something you'd not want and in all honestly I think even removing this line may have no effect! Much more interesting is the other macro...
- %%allparams%% is replaced by a whole set of data which pertains to the user and activity at time of redirection. This data is placed directly onto the query string and is therefore available to the web page that the URL refers to. Here is a broken down example of what the URL would look like;
http://irmweb.domain.com/status/default.asp?
cntxt=nolic
&status=nolic
&clntver=5.5.8
&user=john.smith@domain.com
&lang=EN
&cat=Default
&cs=default
&item=2009_05_16%2001:10:36%20Finance%20report.sxls
&mime=application/vnd.sealed.xls
&srvurl=seal://irm.domain.com:80
&pub=Top%20Secret%20Financial%20Data
&vrsn=Default
&brand=0
&prod=Office%20Unsealer&src=2
&sealedby=fred.bloggs@domain.com
&cntschema=5.0.0.0.release&
Lots and lots of very useful information. status contains the information of what actually happened such as "No License available" or "Not Logged In". The list of these is on the test page. The user field contains who the logged in user was that is being redirected, sealedby tells you who sealed the document that the user is accessing.
- User attempts to open a sealed document on a machine and has hit their device limit. The device limit stops a user opening the same document to a certain number of machines. They are redirected to the default URL and the status that is passed is licinuse which means all available rights are in use.
- A dynamic web page then takes this information, including the user, and queries the IRM server to see how many devices they have access to and what groups the user is a member of.
- If the user is a member of an executive group, then the code automatically increases the users device limit.
- An email is then generated in the dynamic web page and is sent to the owner of the IRM classification the content was sealed to informing them of the activity.
- The status page then informs the end user that they've had their ability to open content on multiple machines increased and tells them to retry opening the content.
- Each classification can have a different URL! This means two main things, if you want have the skills or the time to build a fancy dynamically driven status page application, you can set a different URL for each classification and point it to a static HTML page. Secondly from a dynamic perspective you now have even more flexibility. You can point different classifications to different applications, and have some simply point to static files. Some classifications could be forced to deliver these pages over SSL for instance whilst others not.
