Wednesday May 25, 2011

IRM 11g Quick Setup Guide

The following pages provide a step-by-step guide to setting up an 11g IRM system, covering everything from downloading the software through to creating your first sealed documents, and then provides some guidance on classification design and some examples of how you might use classifications to meet the needs of some typical workflows.

Tuesday Oct 12, 2010

Quick guide to Oracle IRM 11g: Sample use cases

Quick guide to Oracle IRM 11g index

If you've been following this guide step by step, you'll now have a fully functional IRM service and a good understanding of how to start creating some contexts to match your business needs to secure content. The classification design article in the guide goes over some essential advice in creating your classification model in IRM and what follows is additional information in the form of common use cases that I see a lot in our customers. For each I'll walk through the important decisions made and resulting context design to help you understand how IRM is used in the real world.


Work in progress

Let's look at the use case of a financial reporting process where highly sensitive documents are created by a small group of executives. These work in progress (WIP) documents may change content quickly during review and therefore it is important that the wrong and inaccurate versions of the documents do not end up outside the working group. Once a document is ready for wider review it is then secured against another context with a much wider readership. All the unapproved documents are still secured against a context available only to the initial working group. Finally the document is approved to be published and becomes public knowledge. At which time the document may change format, e.g. from a sealed Word document to an unprotected PDF which has no IRM protection at all. This is a nice example of how IRM can protect content through its life.

Financial Reports - Work In Progress (Standard template)
Role Assigned Users & Groups
Contributor Finance Executives
Reviewer Company Board
Reader - No Print
Financial Reports - Review (Standard template)
Contributor david.lee (VP of Finance)
alex.johnson (CFO)
Reviewer Legal Executives
Finance Executives
Company Board
Financial Reports - Published (Export template)
Contributor with export alex.johnson (CFO)

The first context secures work in progress content. Participants are identified as those who are involved in the creation and review of the information and are given contributor and reviewer roles respectively. Note that in this use case there is an attorney privy to the information who is external to the company. However due to the sensitive nature of the material, this external person has been given very restrictive rights, essentially they can only open the content, no printing, editing etc. The offline period for this role may be a matter of hours, allowing the revocation of access to the documents in a very timely manner.

After several iterations of the report have been created, it needs to be reviewed by a wider audience of executives. At this point David Lee (VP of finance) or Alex Johnson (CFO) have the authority to reseal the latest revision to the review context. Therefore there is a trust relationship between the WIP context and the Review context to allow this information to be reclassified. David and Alex are the only authorized users to be able to perform this task and therefore provide a control point for the reclassification of information. Note also that the external attorney now has the ability to review this reclassified document. The Reviewer role allows them to edit, print and use the clipboard within the bounds of the document. Their access to the previous, more sensitive versions remains unchanged.

One aspect of the reviewer role is that in Word change tracking is enforced. This means that every change made in the entire review process is tracked. Up until this enforcement with Oracle IRM, change tracking in Word was only useful if you trusted the end user to not switch it off. IRM brings security to this simple functionality and makes it a powerful tool for document review. Imagine if this was a contract negotiation process, you can be assured that every change to the contract has been recorded.

Finally, the last stage of the life cycle for this financial document is the approval of the report to be released to the investors, employees and the public at large. There is one more context which only the CFO has access to. This context allows for the export of the unprotected document so that it resides outside the realm of IRM security. Such a powerful role is only given to a highly trusted executive, in this example the VP. Again, IRM still protects all the previous versions of content that contain information not appropriate for public consumption.

All the steps in this use case are easy and familiar for the users. All they are doing is opening, editing and working with Word and Excel documents, activity they are used to performing. They may find a slight inconvenience if they are prevented from printing or cut and pasting content into a non-secure location, but overall they require little to no training on how to use IRM content.

Using IRM with a classification model

There are customers with a very mature security strategy which includes a clearly defined and communicated classification policy implemented with procedures and technology to enforce controls and provide monitoring. When IRM is added to the mix of security technologies it is common for the customer to ask how to implement their existing security classification system within IRM. When we deployed IRM at Oracle this was the first point of reference when trying to determine the correct convention for the creation of IRM contexts.

Before we go into the detail of this, it is worth noting that in this use case we are manually recreating elements of an existing security policy inside IRM. There may well be a situation where another product contains all this logic and replicating the information inside IRM would be redundant and costly. For example the Oracle Beehive 2.0 platform is integrated with IRM and as such IRM doesn't use the built in context model but simply leverages the existing security model inside Beehive. So it is possible for Oracle IRM to externalize the entire classification system. This however requires consulting effort which may or may not be appropriate for the return in automation.

But back on topic, let's look at what a security classification model looks like. A common standard that people work to is the ISO 17799 guidelines which was the result of a group of organizations documenting their best practice for security classification. Below is an example of the sort of classification system ISO 17799 recommends.

Level Class Description
1 Top Secret Highly sensitive information about strategies, plans, designs, mergers & acquisitions
2 Highly Confidential Serious impact if shared internally or made public
3 Proprietary Procedures, project plans, specifications and designs for use by authorized personnel
4 Controlled For controlled use within the extended enterprise, but not approved for public circulation
5 Public Information in the public domain

There is an increase in sensitivity of information as you move from bottom to the top of this table. Inversely, the amount of information that is classified decreases as you increase the level of classification. This is important because as you wish to create a model for protecting top secret information, you need to have more control over who can open the documents and who has the power to assign new rights to people. This increases the administration of the solution because someone has to make these decisions. Luckily IRM places this control in the hands of the business users, so those managing top secret contexts are the people who are working with the top secret information. A good example is in Oracle we have a single classification across the entire company for controlled information. Everyone in Oracle has access to this and the provisioning of rights is automatic. However when IRM is used to protect mergers and acquisitions (M&A) documents in Oracle, very top secret information, a small group of users have access and only one or two people can administrate the context. These people however are the ones directly involved in the M&A activity.


Looking at each of these we can determine how IRM might apply. For publicly classified content the response is immediate and quite obvious. You don't use IRM because the information has low to zero risk from a security perspective and therefore requires no controls. However there have been times where documents may be sealed to a public context simply to provide usage statistics.


For controlled content there may be strong reasons to leverage IRM security. However the sensitivity of the information is such that the risks are relatively low. Therefore consider a single company, or at least department wide context. This is born from our best practice which leans towards a simple, wide context model which balances risk versus the usability and manageability of the technology. Essentially controlled information needs some level of security, but it isn't important enough to warrant a fine grained approach with a high cost of maintenance. Usually every professional member of staff is a contributor to the context which allows them to create new content, edit, print etc. This at a minimum provides security of content if it is accidentally lost, emailed to the wrong person outside the company and provides a clear indication that the information has some value and should be treated with due care and attention. Yes allowing everyone the ability to cut and paste information outside the IRM document exists, but disallowing this to a low level of classification may impact business productivity. If control of the information is that necessary, then it should result in a higher classification.

Business partners are given appropriate roles which allow them to open, print and interact with the content but not have the authority to create controlled information or copy and paste to other documents. For the rare exceptions where you wish to give access to un-trusted users you can create guest roles which are assigned as part of a work flow requesting for exceptions to the rule.


As we move up through the classification policy we find an increase in the need for security from finer grained control. Proprietary information carries with it a greater risk if exposed outside the company. Therefore the balance of risk and usability requires a finer granularity of access than a single context. So now you have to decide at what level of granularity these contexts are created and this varies. There are however some good common rules. Avoid a general "proprietary" context, this would undermine the value of the classification. Follow a similar pattern to the work-in-progress use case defined above. Be careful to not be too generous about assigning the contributor role, restricting this group guarantee's document authenticity. Remember with IRM you can add/change access rights at any time in the future, so here is a chance to start out with a limited list and grow as the business requires.

Highly Confidential

As we get closer to your organizations most important information, we start to see an increase in the amount of contexts you need to provide adequate security. Highly confidential information requires a high level of security and as such the risk versus usability trade off favors a more granular approach. Here you are identifying explicit business owners of classifications instead of groups of users or using an automated system for unchecked provisioning of access. Training increases a little here as well because as you hand these classifications into the business, they need to know how to administrate the classification and understand the impact of their assignments of rights. The contexts also become very specific in their naming because instead of relating to wide groups of data, they now apply to very specific, high risk information. The right level of granularity and administration is hard to predict, therefore always start with a few contexts initially and pilot with a small number of business units with well defined use cases. You will learn as you go the right approach and more contexts will emerge over time.

Top Secret

Last but most definitely not least, the Top Secret contexts. Sometimes these are the first to be created because they protect the most important documents in the company. These contexts are very controlled and tightly managed. Even the knowledge that these exist can be a security issue and as such the contexts are not visible to the support help desk. The number of top secret contexts is also typically very small due to the nature of the information. A company will only generate a small number of highly sensitive financial documents or a few critical documents which contain the secret sauce of the product your company creates. Top secret contexts also can have a short life span as they sometimes apply to a short lived, top secret project. Mergers and acquisitions is again another good example, these are often very top secret but also short lived. L1 classified contexts quite often contain external users, executives from a target acquisition or attorneys from your legal firm. But the sensitivity of the information means external users are closely monitored by the context managers.

Example context map

Typically to map a classification policy to IRM requires a business consulting project which asks each elements of the business how they use sensitive information, who should be able allowed to open and it and manage the access. At the end of this exercise you end up with a context map. This is a simple table which shows the IRM contexts and their relationship to the classification policy. Here is an example table from when we used the technology in SealedMedia before we were acquired by Oracle.

Top Secret Highly Confidential Proprietary Controlled
L1 L2 L3 L4
Board Communications Executive WIP Executive Company
Intellectual Property   Competitive  
Security Product Management WIP Product Management  
  Professional Services WIP Professional Services  
  Sales WIP Sales  
  Marketing WIP Marketing  
  Finance WIP Finance  
  Engineering WIP Engineering  
    External External

Note the use of the labels L1 through L4 to indicate level of sensitivity. This would be used as part of the actual context name, e.g. "L1 (Top Secret) Intellectual Property". This serves a few purposes, firstly if a user has access to many classifications, they will be listed in order or sensitivity with the most important at the top when users are making decisions about classification of documents. Also it makes it very clear how sensitive each classification is. If I attempt to open a document I do not have rights to, the IRM software redirects me to a web page informing me that I don't have access to "L1 (Top Secret) Security". Immediately I understand that I shouldn't be opening this top secret document because it is classified above my access level. Note that in the above map only ongoing contexts are documented. There may well be a context called "L1 (Top Secret) Smith versus Jones dispute" which would be used to secure the information about a highly confidential law suit. But this classification exists for only a short period of time and therefore is created as and when needed. The context map is designed to document classifications which will exist for ongoing future of the company.

Periodic expiry & version control

The last example in this set of use cases is when IRM can allow for the periodic expiry of access to information which in turn can also be used to implement security related version control. Consider the situation where your company has some very valuable product roadmap documents which detail information on the next release of your products. This information may have valuable insight to the direction of the company and the disclosure of such information to competitors, the press or just the general public may have a significant impact to your business. However road map information changes often and therefore not only do you need to ensure who has access to it, but ensure that authorized users are access the right versions. Another useful aspect of IRM is that you may wish to review who has access to your product road maps on a annual basis and examine if the rights model you've decided on is still appropriate, e.g. do you still want users to be able to print the documents. IRM can satisfy both of these requirements when you appropriately design the classification model. Consider the context below;

Context title 2010 L1 (Top Secret) Product Roadmap
Contributor VP Product Management
Item Readers Trusted users in the company who have been training on how to deliver product roadmap presentations and messaging
Context managers VP of product development and those who approve and verify the training of trusted users

This is a very simple definition of a context but a great demonstration of the powerful capabilities of Oracle IRM. The only person who can create product roadmap documents is the VP. This is because this person is the last point in the review and approval process and as such has the authority to reseal the final product roadmap document from the work in progress context to this published context. The Item Reader role by default gives no access to anything in the context. So as each person completes the product roadmap training, they are given the role Item Reader and at the same time you add the specific documents which they've been trained on. There is of course an administrative overhead here, if you have hundreds of users being trained a month, someone has to be administrating IRM. Using groups at this point does allow for the management to be simplified. You might have a group called "Trained 2010 product roadmap presentation field sales users" and this group has been given the Item Reader role with the document restriction of the current 2010 product roadmap presentation. Then the management of users who can access these documents is done in the user directory, such as managing group membership in Active Directory. A better solution for the management of this rights assignment would be to use a provisioning system such as the Oracle Identity Manager. Here you can centralize the workflow of users being trained and then not only give them access to the IRM context but also automate the provisioning to the location where the documents are stored.


Periodic expiry

Because the context name is prepended with the year it means that in 2011 the owner of this classification needs to review this classification. This review may decide that users with the "Item Reader" role can be trusted to print the content and that the 2 week offline period is too long and should be reduced to 1 week. The use case may also require that for each year users must be trained on the presentation of product roadmap information. So the creation of a new context, "2011 L1 (Top Secret) Product Roadmap" is created with a blank list of Item Readers, ready for new trained users to be given access to the new product roadmap. All Item Readers in the 2010 context are then removed and in one simple action you now ensure that nobody can access the old, out dated 2010 information. Because Oracle IRM separates out all the access rights from the documents themselves, there is nothing else to do. You remove access from the server, and as the offline periods to these documents expire, so does the access. The advantage for this retirement of access to old content, is that in the future if you ever need to be able to access a product roadmap document from 2010, the IRM administrator can simply go back to the old context and give access to a specific person.

Version control

With the Item Reader role you are explicitly defining what documents users have access to. Whilst this might incur an administrative cost in maintaining this list, the value from a security perspective is very fine grained control and high visibility of who can access what. Another benefit of this is because Oracle IRM allows you to change your access rights at any time, you can update this list. So imagine that you have a group of trained users assigned with an Item Reader role that has version 1 of the product roadmap presentation listed. Then after a few months, the roadmap changes, as it often does and a new version 2 is created. After making this new version available somewhere you can now remove the groups access to version 1 and add version 2. What does this mean? Now everyone in that group trying to open version 1 is going to get an access denied message. But, this message is in the form of a web status page which you have full control over. You can now modify that status page to provide the link to the new version 2, which they do have the ability to open.

This is incredibly powerful. Not only is IRM providing the means to ensure only authorized users have access to your most sensitive information, but it is ensuring they can only access the latest versions of that information AND allowing you to easily communicate to them where to GET that latest version from.

These are just a few of the many uses for Oracle IRM, if you would like to discuss your own particular use cases and see how Oracle IRM can help, please contact us.

Monday Jun 14, 2010

Quick guide to Oracle IRM 11g: Classification design

Quick guide to Oracle IRM 11g index

This is the final article in the quick guide to Oracle IRM. If you've followed everything prior you will now have a fully functional and tested Information Rights Management service. It doesn't matter if you've been following the 10g or 11g guide as this next article is common to both.


Why this is the most important part...

Now the real work begins, installing and getting an IRM system running is as simple as following instructions. However to actually have an IRM technology easily protecting your most sensitive information without interfering with your users existing daily work flows and be able to scale IRM across the entire business, requires thought into how confidential documents are created, used and distributed. This article is going to give you the information you need to ask the business the right questions so that you can deploy your IRM service successfully. The IRM team here at Oracle have over 10 years of experience in helping customers and it is important you understand the following to be successful in securing access to your most confidential information.


Whatever you are trying to secure, be it mergers and acquisitions information, engineering intellectual property, health care documentation or financial reports. No matter what type of user is going to access the information, be they employees, contractors or customers, there are common goals you are always trying to achieve.

  • Securing the content at the earliest point possible and do it automatically. Removing the dependency on the user to decide to secure the content reduces the risk of mistakes significantly and therefore results a more secure deployment.
  • K.I.S.S. (Keep It Simple Stupid) Reduce complexity in the rights/classification model. Oracle IRM lets you make changes to access to documents even after they are secured which allows you to start with a simple model and then introduce complexity once you've understood how the technology is going to be used in the business. After an initial learning period you can review your implementation and start to make informed decisions based on user feedback and administration experience.
  • Clearly communicate to the user, when appropriate, any changes to their existing work practice. You must make every effort to make the transition to sealed content as simple as possible. For external users you must help them understand why you are securing the documents and inform them the value of the technology to both your business and them.

Before getting into the detail, I must pay homage to Martin White, Vice President of client services in SealedMedia, the company Oracle acquired and who created Oracle IRM. In the SealedMedia years Martin was involved with every single customer and was key to the design of certain aspects of the IRM technology, specifically the context model we will be discussing here. Listening carefully to customers and understanding the flexibility of the IRM technology, Martin taught me all the skills of helping customers build scalable, effective and simple to use IRM deployments. No matter how well the engineering department designed the software, badly designed and poorly executed projects can result in difficult to use and manage, and ultimately insecure solutions.


The advice and information that follows was born with Martin and he's still delivering IRM consulting with customers and can be found at

It is from Martin and others that Oracle not only has the most advanced, scalable and usable document security solution on the market, but Oracle and their partners have the most experience in delivering successful document security solutions.


Understanding the classification and standard rights model

The goal of any successful IRM deployment is to balance the increase in security the technology brings without over complicating the way people use secured content and avoid a significant increase in administration and maintenance. With Oracle it is possible to automate the protection of content, deploy the desktop software transparently and use authentication methods such that users can open newly secured content initially unaware the document is any different to an insecure one. That is until of course they attempt to do something for which they don't have any rights, such as copy and paste to an insecure application or try and print.


Central to achieving this objective is creating a classification model that is simple to understand and use but also provides the right level of complexity to meet the business needs. In Oracle IRM the term used for each classification is a "context". A context defines the relationship between.

  • A group of related documents
  • The people that use the documents
  • The roles that these people perform
  • The rights that these people need to perform their role


The context is the key to the success of Oracle IRM. It provides the separation of the role and rights of a user from the content itself. Documents are sealed to contexts but none of the rights, user or group information is stored within the content itself. Sealing only places information about the location of the IRM server that sealed it, the context applied to the document and a few other pieces of metadata that pertain only to the document. This important separation of rights from content means that millions of documents can be secured against a single classification and a user needs only one right assigned to be able to access all documents.

If you have followed all the previous articles in this guide, you will be ready to start defining contexts to which your sensitive information will be protected. But before you even start with IRM, you need to understand how your own business uses and creates sensitive documents and emails.


Identifying business use cases

Oracle is able to support multiple classification systems, but usually there is one single initial need for the technology which drives a deployment. This need might be to protect sensitive mergers and acquisitions information, engineering intellectual property, financial documents. For this and every subsequent use case you must understand how users create and work with documents, to who they are distributed and how the recipients should interact with them.


A successful IRM deployment should start with one well identified use case (we go through some examples towards the end of this article) and then after letting this use case play out in the business, you learn how your users work with content, how well your communication to the business worked and if the classification system you deployed delivered the right balance. It is at this point you can start rolling the technology out further.


Creating an effective IRM classification model

Once you have selected the initial use case you will address with IRM, you need to design a classification model that defines the access to secured documents within the use case. In Oracle IRM there is an inbuilt classification system called the "context" model. In Oracle IRM 11g it is possible to extend the server to support any rights classification model, but the majority of users who are not using an application integration (such as Oracle IRM within Oracle Beehive) are likely to be starting out with the built in context model.


Before looking at creating a classification system with IRM, it is worth reviewing some recognized standards and methods for creating and implementing security policy. A very useful set of documents are the ISO 27002 (previously ISO 17799) guidelines and the SANS security policy templates.

First task is to create a context against which documents are to be secured. A context consists of a group of related documents (all top secret engineering research), a list of roles (contributors and readers) which define how users can access documents and a list of users (research engineers) who have been given a role allowing them to interact with sealed content. Before even creating the first context it is wise to decide on a philosophy which will dictate the level of granularity, the question is, where do you start? At a department level? By project? By technology? First consider the two ends of the spectrum...


One single classification across the entire business

Imagine that instead of having separate contexts, one for engineering intellectual property, one for your financial data, one for human resources personally identifiable information, you create one context for all documents across the entire business. Whilst you may have immediate objections, there are some significant benefits in thinking about considering this.

  • Document security classification decisions are simple. You only have one context to chose from!
  • User provisioning is simple, just make sure everyone has a role in the only context in the business.
  • Administration is very low, if you assign rights to groups from the business user repository you probably never have to touch IRM administration again.


There are however some obvious downsides to this model.

  • All users in have access to all IRM secured content. So potentially a sales person could access sensitive mergers and acquisition documents, if they can get their hands on a copy that is.
  • You cannot delegate control of different documents to different parts of the business, this may not satisfy your regulatory requirements for the separation and delegation of duties.
  • Changing a users role affects every single document ever secured.


Even though it is very unlikely a business would ever use one single context to secure all their sensitive information, thinking about this scenario raises one very important point. Just having one single context and securing all confidential documents to it, whilst incurring some of the problems detailed above, has one huge value. Once secured, IRM protected content can ONLY be accessed by authorized users. Just think of all the sensitive documents in your business today, imagine if you could ensure that only everyone you trust could open them. Even if an employee lost a laptop or someone accidentally sent an email to the wrong recipient, only the right people could open that file.


A context for each and every possible granular use case

Now let's think about the total opposite of a single context design. What if you created a context for each and every single defined business need and created multiple contexts within this for each level of granularity?


Let's take a use case where we need to protect engineering intellectual property. Imagine we have 6 different engineering groups, and in each we have a research department, a design department and manufacturing. The company information security policy defines 3 levels of information sensitivity... restricted, confidential and top secret. Then let's say that each group and department needs to define access to information from both internal and external users. Finally add into the mix that they want to review the rights model for each context every financial quarter. This would result in a huge amount of contexts. For example, lets just look at the resulting contexts for one engineering group.

Q1FY2010 Restricted Internal - Engineering Group 1 - Research
Q1FY2010 Restricted Internal - Engineering Group 1 - Design
Q1FY2010 Restricted Internal - Engineering Group 1 - Manufacturing
Q1FY2010 Restricted External- Engineering Group 1 - Research
Q1FY2010 Restricted External - Engineering Group 1 - Design
Q1FY2010 Restricted External - Engineering Group 1 - Manufacturing
Q1FY2010 Confidential Internal - Engineering Group 1 - Research
Q1FY2010 Confidential Internal - Engineering Group 1 - Design
Q1FY2010 Confidential Internal - Engineering Group 1 - Manufacturing
Q1FY2010 Confidential External - Engineering Group 1 - Research
Q1FY2010 Confidential External - Engineering Group 1 - Design
Q1FY2010 Confidential External - Engineering Group 1 - Manufacturing
Q1FY2010 Top Secret Internal - Engineering Group 1 - Research
Q1FY2010 Top Secret Internal - Engineering Group 1 - Design
Q1FY2010 Top Secret Internal - Engineering Group 1 - Manufacturing
Q1FY2010 Top Secret External - Engineering Group 1 - Research
Q1FY2010 Top Secret External - Engineering Group 1 - Design
Q1FY2010 Top Secret External - Engineering Group 1 - Manufacturing

Now multiply the above by 6 for each engineering group, 18 contexts. You are then creating/reviewing another 18 every 3 months. After a year you've got 72 contexts. What would be the advantages of such a complex classification model?


  • You can satisfy very granular rights requirements, for example only an authorized engineering group 1 researcher can create a top secret report for access internally, and his role will be reviewed on a very frequent basis.
  • Your business may have very complex rights requirements and mapping this directly to IRM may be an obvious exercise.


The disadvantages of such a classification model are significant...

  • Huge administrative overhead. Someone in the business must manage, review and administrate each of these contexts. If the engineering group had a single administrator, they would have 72 classifications to reside over each year.
  • From an end users perspective life will be very confusing. Imagine if a user has rights in just 6 of these contexts. They may be able to print content from one but not another, be able to edit content in 2 contexts but not the other 4. Such confusion at the end user level causes frustration and resistance to the use of the technology.
  • Increased synchronization complexity. Imagine a user who after 3 years in the company ends up with over 300 rights in many different contexts across the business. This would result in long synchronization times as the client software updates all your offline rights.
  • Hard to understand who can do what with what. Imagine being the VP of engineering and as part of an internal security audit you are asked the question, "What rights to researchers have to our top secret information?". In this complex model the answer is not simple, it would depend on many roles in many contexts.


Of course this example is extreme, but it highlights that trying to build many barriers in your business can result in a nightmare of administration and confusion amongst users. In the real world what we need is a balance of the two. We need to seek an optimum number of contexts. Too many contexts are unmanageable and too few contexts does not give fine enough granularity.


What makes a good context?

Good context design derives mainly from how well you understand your business requirements to secure access to confidential information. Some customers I have worked with can tell me exactly the documents they wish to secure and know exactly who should be opening them. However there are some customers who know only of the government regulation that requires them to control access to certain types of information, they don't actually know where the documents are, how they are created or understand exactly who should have access. Therefore you need to know how to ask the business the right questions that lead to information which help you define a context.


First ask these questions about a set of documents

  • What is the topic?
  • Who are legitimate contributors on this topic?
  • Who are the authorized readership?


If the answer to any one of these is significantly different, then it probably merits a separate context. Remember that sealed documents are inherently secure and as such they cannot leak to your competitors, therefore it is better sealed to a broad context than not sealed at all. Simplicity is key here. Always revert to the first extreme example of a single classification, then work towards essential complexity. If there is any doubt, always prefer fewer contexts. Remember, Oracle IRM allows you to change your mind later on. You can implement a design now and continue to change and refine as you learn how the technology is used. It is easy to go from a simple model to a more complex one, it is much harder to take a complex model that is already embedded in the work practice of users and try to simplify it.

It is also wise to take a single use case and address this first with the business. Don't try and tackle many different problems from the outset. Do one, learn from the process, refine it and then take what you have learned into the next use case, refine and continue. Once you have a good grasp of the technology and understand how your business will use it, you can then start rolling out the technology wider across the business.


Deciding on the use of roles in the context

Once you have decided on that first initial use case and a context to create let's look at the details you need to decide upon. For each context, identify;


Administrative roles

  • Business owner, the person who makes decisions about who may or may not see content in this context. This is often the person who wanted to use IRM and drove the business purchase. They are the usually the person with the most at risk when sensitive information is lost.
  • Point of contact, the person who will handle requests for access to content. Sometimes the same as the business owner, sometimes a trusted secretary or administrator.
  • Context administrator, the person who will enact the decisions of the Business Owner. Sometimes the point of contact, sometimes a trusted IT person.


Document related roles

  • Contributors, the people who create and edit documents in this context.
  • Reviewers, the people who are involved in reviewing documents but are not trusted to secure information to this classification. This role is not always necessary. (See later discussion on Published-work and Work-in-Progress)
  • Readers, the people who read documents from this context.


Some people may have several of the roles above, which is fine. What you are trying to do is understand and define how the business interacts with your sensitive information. These roles obviously map directly to roles available in Oracle IRM.


Reviewing the features and security for context roles

At this point we have decided on a classification of information, understand what roles people in the business will play when administrating this classification and how they will interact with content. The final piece of the puzzle in getting the information for our first context is to look at the permissions people will have to sealed documents.


First think why are you protecting the documents in the first place? It is to prevent the loss of leaking of information to the wrong people. To control the information, making sure that people only access the latest versions of documents. You are not using Oracle IRM to prevent unauthorized people from doing legitimate work. This is an important point, with IRM you can erect many barriers to prevent access to content yet too many restrictions and authorized users will often find ways to circumvent using the technology and end up distributing unprotected originals.

Because IRM is a security technology, it is easy to get carried away restricting different groups. However I would highly recommend starting with a simple solution with few restrictions. Ensure that everyone who reasonably needs to read documents can do so from the outset. Remember that with Oracle IRM you can change rights to content whenever you wish and tighten security. Always return to the fact that the greatest value IRM brings is that ONLY authorized users can access secured content, remember that simple "one context for the entire business" model. At the start of the deployment you really need to aim for user acceptance and therefore a simple model is more likely to succeed. As time passes and users understand how IRM works you can start to introduce more restrictions and complexity.

Another key aspect to focus on is handling exceptions. If you decide on a context model where engineering can only access engineering information, and sales can only access sales data. Act quickly when a sales manager needs legitimate access to a set of engineering documents. Having a quick and effective process for permitting other people with legitimate needs to obtain appropriate access will be rewarded with acceptance from the user community. These use cases can often be satisfied by integrating IRM with a good Identity & Access Management technology which simplifies the process of assigning users the correct business roles.


The big print issue...

Printing is often an issue of contention, users love to print but the business wants to ensure sensitive information remains in the controlled digital world. There are many cases of physical document loss causing a business pain, it is often overlooked that IRM can help with this issue by limiting the ability to generate physical copies of digital content. However it can be hard to maintain a balance between security and usability when it comes to printing. Consider the following points when deciding about whether to give print rights.



  • Oracle IRM sealed documents can contain watermarks that expose information about the user, time and location of access and the classification of the document. This information would reside in the printed copy making it easier to trace who printed it.
  • Printed documents are slower to distribute in comparison to their digital counterparts, so time sensitive information in printed format may present a lower risk.
  • Print activity is audited, therefore you can monitor and react to users abusing print rights.


In summary it is important to think carefully about the way you create your context model. As you ask the business these questions you may get a variety of different requirements. There may be special projects that require a context just for sensitive information created during the lifetime of the project. There may be a department that requires all information in the group is secured and you might have a few senior executives who wish to use IRM to exchange a small number of highly sensitive documents with a very small number of people. Oracle IRM, with its very flexible context classification system, can support all of these use cases. The trick is to introducing the complexity to deliver them at the right level.


In another article i'm working on I will go through some examples of how Oracle IRM might map to existing business use cases. But for now, this article covers all the important questions you need to get your IRM service deployed and successfully protecting your most sensitive information.

Quick guide to Oracle IRM 11g: Creating your first sealed document

Quick guide to Oracle IRM 11g index

The previous articles in this guide have detailed how to install, configure and secure your Oracle IRM 11g service. This article walks you through the process of now creating your first context and securing a document against it. I should mention that it would be worth reviewing the following to ensure your installation is ready for that all important first document.

  • Ensure you have correctly configured the keystore for the IRM wrapper keys. If this is not correctly configured, creating the context below will fail.
  • Make sure the IRM server URL correctly resolves and uses the right protocol (HTTP or HTTPS)


Create the first context

In Oracle 11g there is a built in classification and rights system called the "standard rights model" which is based on 10 years of customer use cases and innovation. It is a system which enables IRM to scale massively whilst retaining the ability to balance security and usability and also separate duties by allowing contacts in the business to own classifications. The final article in this guide goes into detail on this inbuilt classification model, but for the purposes of this current article all we need to do is create at least one context to test our system out.

With a new IRM server there are a set of predefined context templates and roles which again are setup in a way which reflects the most common use we've learned from our customers. We will use these out of the box configurations as they are to create the first context against which we will seal some content.
First login to your Oracle IRM Management Website located at Currently the system is only configured to use the built in LDAP for users, so use the only account we have at the moment, which by default is weblogic. Once logged in switch to the Contexts tab.

Click on the New Context icon (
) in the menu bar on the left. In the resulting dialog select the Standard context template and enter in a name for the context. Then just hit finish, the weblogic account will automatically be made the manager. You'll now see your brand new context ready for users to be assigned.

Now click on the Assign Role icon (
) in the menu bar and in the resulting dialog search for your only user account, weblogic, and add to the list on the right.

Now select a role for this user. Because we need to create a document with this user we must select contributor, as this is the only role which allows for the ability to seal.

Finally hit next and then finish. We now have a context with a user that has the rights to create a document. The next step is to configure the IRM Desktop to get these rights from the server.


Install the Oracle IRM Desktop

Before we can seal a document we need the client software installed. Oracle IRM has a very small, lightweight client called the Oracle IRM Desktop which can be freely downloaded in 27 languages from here. Double click on the installer and click on next...


Next again...


And finally on install...


Very easy. You may get a warning about closing Outlook, Word or another application and most of the time no reboots are required. Once it is installed you will see the IRM Desktop icon running in your tool tray, bottom right of the desktop.

Seal your first document

Finally the prize is within reach, creating your first sealed document. The server is running, we've got a context ready, a user assigned a role in the context but there is the simple and obvious hoop left to jump through.

To seal a document we need to have the users rights cached to the local machine. For this to take place, the IRM Desktop needs to know where the Oracle IRM server is on the network so we can synchronize these rights and then be able to seal a document. The usual way for the IRM Desktop to know about the IRM server is it learns automatically when you open an existing piece of content that someone has sent you... ack. Bit of a chicken or the egg dilemma. The solution is to manually tell the IRM Desktop the location of the IRM Server and then force a synchronization of rights.

Right click on the Oracle IRM Desktop icon in the system tray and select Options.... Then switch to the Servers tab in the resulting dialog. There are no servers in the list because you've never opened any content. This list is usually populated automatically but we are going to add a server manually, so click on New.... Into the dialog enter in the full URL to the IRM server. Note that this time you use the path /irm_desktop/ and not /irm_rights/. You can see an example from the image below.

Click on the validate button and you'll be asked to authenticate. Enter in your weblogic username and password and also check the Remember my password check box. Click OK and the IRM Desktop will confirm a successful connection to the server. OK all the dialogs and we are ready to Synchronize this users rights to the desktop. Right click once more on the Oracle IRM Desktop icon in the system tray. Now the Synchronize menu option is available. Select this and the IRM Desktop will now talk to the IRM server, authenticate using your weblogic account and get your rights to the context we created.


Because this is the first time this users has communicated with the IRM server the IRM Desktop presents a privacy policy dialog. This is a chance for the business to ask users to agree to any policy about the use of IRM before opening secured documents. In our guide we've not bothered to setup this URL so just click on the check box and hit Accept. The IRM Desktop will then talk to the server, get your rights and display a success dialog.

Lets protect a document

Now we are ready to seal a piece of content. In my guide i'm going to protect a Microsoft Word document. This mean's I have to have copy of Office installed, in this guide i'm using Microsoft Office 2007. You could also seal a PDF document, you'll need to download and install Adobe Acrobat Reader. A very simple test could be to seal a GIF/JPG/PNG or piece of HTML because this is rendered using Internet Explorer. But as I say, i'm going to protect a Word document. The following example demonstrates choosing a file in Windows Explorer, there are many ways to seal a file and you can watch a few in this video.
  • Open a copy of Windows Explorer and locate the file you wish to seal.
  • Right click on the document and select Seal To -> Context
  • You are now presented with the Select Context dialog.


You'll now have a sealed copy of the document sat in the same location. Double click on this document and it will open, again using the credentials you've already provided.


That is it, now you just need to add more users, more documents, more classifications and start exploring the different roles and experiment with different offline periods etc. You may wish to setup the server against an existing LDAP or Active Directory environment instead of using the built in WebLogic LDAP store. You can read how to use your corporate directory here.


But before we finish this guide, there is one more article and arguably the most important article of all. Next I discuss the all important decision making surrounding the actually implementation of Oracle IRM inside your business. Who has rights to what? How do you map contexts to your existing business practices? It is the next article which actually ensures you deploy a successful IRM solution by looking at the business and understanding how they use your sensitive information and then configuring Oracle IRM to reflect their use.

Quick guide to Oracle IRM 11g: Configuring SSL

Quick guide to Oracle IRM 11g index

So far in this guide we have an IRM Server up and running, however I skipped over SSL configuration in the previous article because I wanted to focus in more detail now. You can, if you wish, not bother with setting up SSL, but considering this is a security technology it is worthwhile doing.


  1. Setting up a one way, self signed SSL certificate in WebLogic
  2. Setting up an official SSL certificate in Apache 2.x
  3. Configuring Apache to proxy traffic to the IRM server

There are two common scenarios in which an Oracle IRM server is configured. For a development or evaluation system, people usually communicate directly to the WebLogic Server running the IRM service. However in a production environment and for some proof of concept evaluations that require a setup reflecting a production system, the traffic to the IRM server travels via a web server proxy, commonly Apache. In this guide we are building an Oracle Enterprise Linux based IRM service and this article will go over the configuration of SSL in WebLogic and also in Apache.

Like in the past articles, we are going to use two host names in the configuration below,

  • will refer to the public Apache server
  • will refer to the internal WebLogic IRM server

Setting up a one way, self signed SSL certificate in WebLogic

First lets look at creating just a simple self signed SSL certificate to be used in WebLogic. This is a quick and easy way to get SSL working in your environment, however the downside is that no browsers are going to trust this certificate you create and you'll need to manually install the certificate onto any machine's communicating with the server. This is fine for development or when you have only a few users evaluating the system, but for any significant use it's usually better to have a fully trusted certificate in use and I explain that in the next section. But for now lets go through creating, installing and testing a self signed certificate.

We use a library in Java to create the certificates, open a console and running the following commands. Note you should choose your own secure passwords whenever you see password below.

[oracle@irm /] source /oracle/middleware/wlserver_10.3/server/bin/

[oracle@irm /] cd /oracle/middleware/user_projects/domains/irm_domain/config/fmwconfig/

[oracle@irm /] java utils.CertGen -selfsigned -certfile MyOwnSelfCA.cer -keyfile MyOwnSelfKey.key -keyfilepass password -cn ""

[oracle@irm /] java utils.ImportPrivateKey -keystore MyOwnIdentityStore.jks -storepass password -keypass password -alias trustself -certfile MyOwnSelfCA.cer.pem -keyfile MyOwnSelfKey.key.pem -keyfilepass password

[oracle@irm /] keytool -import -trustcacerts -alias trustself -keystore TrustMyOwnSelf.jks -file MyOwnSelfCA.cer.der -keyalg RSA

We now have two Java Key Stores, MyOwnIdentityStore.jks and TrustMyOwnSelf.jks. These contain keys and certificates which we will use in WebLogic Server. Now we need to tell the IRM server to use these stores when setting up SSL connections for incoming requests. Make sure the Admin server is running and login into the WebLogic Console at and do the following;

  • In the menu on the left, select the + next to Environment to expose the submenu, then click on Servers.
  • You will see two servers in the list, AdminServer(admin) and IRM_server1. If the IRM server is running, shut it down either by hitting CONTROL + C in the console window it was started from, or you can switch to the CONTROL tab, select IRM_server1 and then select the Shutdown menu and then Force Shutdown Now.
  • In the Configuration tab select IRM_server1 and switch to the Keystores tab. By default WebLogic Server uses it's own demo identity and trust. We are now going to switch to the self signed one's we've just created. So select the Change button and switch to Custom Identity and Custom Trust and hit save.
  • Now we have to complete the resulting fields, the setting's i've used in my evaluation server are below.

    • Custom Identity Keystore: /oracle/middleware/user_projects/domains/irm_domain/config
    • Custom Identity Keystore Type: JKS
    • Custom Identity Keystore Passphrase: password
    • Confirm Custom Identity Keystore Passphrase: password

    • Custom Trust Keystore: /oracle/middleware/user_projects/domains/irm_domain/config/fmwconfig
    • Custom Trust Keystore Type: JKS
    • Custom Trust Keystore Passphrase: password
    • Confirm Custom Trust Keystore Passphrase: password

  • Now click on the SSL tab for the IRM_server1 and enter in the alias and passphrase, in my demo here the details are;

    • Private Key Alias: trustself
    • Private Key Passphrase: password
    • Confirm Private Key Passphrase: password

    And hit save.

Now lets test a connection to the IRM server over HTTPS using SSL. Go back to a console window and start the IRM server, a quick reminder on how to do this is...

[oracle@irm /] cd /oracle/middleware/user_projects/domains/irm_domain/bin

[oracle@irm /] ./startManagedWeblogic IRM_server1

Once running, open a browser and head to the SSL port of the server. By default the IRM server will be listening on the URL Note in the example image on the right the port is 7002 because it's a system that has the IRM services installed on the Admin server, this isn't typical (or advisable). Your system is going to have a separate managed server which will be listening on port 16101. Once you open this address you will notice that your browser is going to complain that the server certificate is untrusted. The images on the right show how Firefox displays this error. You are going to be prompted every time you create a new SSL session with the server, both from the browser and more annoyingly from the IRM Desktop.

If you plan on always using a self signed certificate, it is worth adding it to the Windows certificate store so that when you are accessing sealed content you do not keep being informed this certificate is not trusted. Follow these instructions (which are for Internet Explorer 8, they may vary for your version of IE.)

  • Start Internet Explorer and open the URL to your IRM server over SSL, e.g. IE will complain that about the certificate, click on Continue to this website (not recommended).
  • From the IE Tools menu select Internet Options and from the resulting dialog select Security and then click on Trusted Sites and then the Sites button.
  • Add to the list of trusted sites a URL which mates the server you are accessing, e.g. and select OK. Now refresh the page you were accessing and next to the URL you should see a red cross and the words Certificate Error. Click on this button and select View Certificates.
  • You will now see a dialog with the details of the self signed certificate and the Install Certificate... button should be enabled. Click on this to start the wizard. Click next and you'll be asked where you should install the certificate.
  • Change the option to Place all certificates in the following store. Select browse and choose the Trusted Root Certification Authorities location and hit OK. You'll then be prompted to install the certificate and answer yes.
    You also need to import the root signed certificate into the same location, so once again select the red Certificate Error option and this time when viewing the certificate, switch to the Certification Path tab and you should see a CertGenCAB certificate. Select this and then click on View Certificate and go through the same process as above to import the certificate into the store.
  • Finally close all instances of the IE browser and re-access the IRM server URL again, this time you should not receive any errors.



Setting up an official SSL certificate in Apache 2.x

At this point we now have an IRM server that you can communicate with over SSL. However this certificate isn't trusted by any browser because it's path of trust doesn't end in a recognized certificate authority (CA). Also you are communicating directly to the WebLogic Server over a non standard SSL port, 16101. In a production environment it is common to have another device handle the initial public internet traffic and then proxy this to the WebLogic server. The diagram below shows a very simplified view of this type of deployment. What i'm going to walk through next is configuring Apache to proxy traffic to a WebLogic server and also to use a real SSL certificate from an official CA.

First step is to configure Apache to handle incoming requests over SSL. In this guide I am configuring the IRM service in Oracle Enterprise Linux 5 update 3 and Apache 2.2.3 which came with OpenSSL and mod_ssl components. Before I purchase an SSL certificate, I need to generate a certificate request from the server. uses Verisign and for my own personal needs I use cheaper certificates from GoDaddy. The following instructions are specific to Apache, but there are many references out there for other web servers. For Apache I have OpenSSL and the commands are;

[oracle@irm /] cd /usr/bin

[oracle@irm bin] openssl genrsa -des3 -out irm-apache-server.key 2048

Generating RSA private key, 2048 bit long modulus



e is 65537 (0x10001)

Enter pass phrase for irm-apache-server.key:

Verifying - Enter pass phrase for irm-apache-server.key:

[oracle@irm bin] openssl req -new -key irm-apache-server.key -out irm-apache-server.csr

Enter pass phrase for irm-apache-server.key:

You are about to be asked to enter information that will be incorporated
into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.


Country Name (2 letter code) [GB]:US

State or Province Name (full name) [Berkshire]:CA

Locality Name (eg, city) [Newbury]:San Francisco

Organization Name (eg, company) [My Company Ltd]:Oracle

Organizational Unit Name (eg, section) []:Security

Common Name (eg, your name or your server's hostname) []

Email Address []

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:testing

An optional company name []:

You must make sure to remember the pass phrase you used in the initial key generation, you will need this when later configuring Apache. In the /usr/bin directory there are now two new files. The irm-apache-server.csr contains our certificate request and is what you cut and paste, or upload, to your certificate authority when you purchase and validate your SSL certificate. In response you will typically get two files. Your server certificate and another certificate file that will likely contain a set of certificates from your CA which validate your certificate's trust. Next we need to configure Apache to use these files. Typically there is an ssl.conf file which is where all the SSL configuration is done. On my Oracle Enterprise Linux server this file is located in /etc/httpd/conf.d/ssl.conf and i've added the following lines.


# Setup SSL for


SSLEngine On

SSLCertificateFile /oracle/secure/

SSLCertificateKeyFile /oracle/secure/

SSLCertificateChainFile /oracle/secure/gd_bundle.crt


Restarting Apache (apachectl restart) and I can now attempt to connect to the Apache server in a web browser, If all is configured correctly I should now see an Apache test page delivered to me over HTTPS.

Configuring Apache to proxy traffic to the IRM server

Final piece in setting up SSL is to have Apache proxy requests for the IRM server but do so securely. So the requests to Apache will be over HTTPS using a legitimate certificate, but we can also configure Apache to proxy these requests internally across to the IRM server using SSL with the self signed certificate we generated at the start of this article. To do this proxying we use the WebLogic Web Server plugin for Apache which you can download here from Oracle. Download the zip file and extract onto the server.

The file extraction reveals a set of zip files, each one specific to a supported web server. In my instance I am using Apache 2.2 32bit on an Oracle Enterprise Linux, 64 bit server. If you are not sure what version your Apache server is, run the command /usr/sbin/httpd -V and you'll see version and it its 32 or 64 bit. Mine is a 32bit server so I need to extract the file The from the resulting lib folder copy the file into /usr/lib/httpd/modules/.

First we want to test that the plug in will work for regular HTTP traffic. Edit the httpd.conf for Apache and add the following section at the bottom.

LoadModule weblogic_module modules/
<IfModule mod_weblogic.c>
   WebLogicPort 16100
   WLLogFile /tmp/wl-proxy.log
<Location /irm_rights>
   SetHandler weblogic-handler
<Location /irm_desktop>
   SetHandler weblogic-handler
<Location /irm_sealing>
   SetHandler weblogic-handler
<Location /irm_services>
   SetHandler weblogic-handler

Now restart Apache again (apachectl restart) and now open a browser to Apache will proxy the HTTP traffic from the port 80 of your Apache server to the IRM service listening on port 16100 of the WebLogic Managed server. Note above I have included all four of the Locations you might wish to proxy. is the URL to the management website, /irm_desktop is the URL used for the IRM Desktop to communicate. irm_sealing is for web services based document sealing and irm_services is for IRM server web services. The last two are typically only used when you have the IRM server integrated with another application and it is unlikely you'd be accessing these resources from the public facing Apache server. However, just in case, i've mentioned them above.

Now let's enable SSL communication from Apache to WebLogic. In the ZIP file we extracted were some more modules we need to copy into the Apache folder. Looking back in the lib that we extracted, there are some more files. Copy the following into the /usr/lib/httpd/modules/ folder.

Now the documentation states that should only need to do this, but I found that I also needed to create an environment variable called LD_LIBRARY_PATH and point this to the folder /usr/lib/httpd/modules/. If I didn't do this, starting Apache with the WebLogic module configured to SSL would throw the error.

[crit] (20014)Internal error: WL SSL Init failed for server: (null) on 0

So I had to edit the file /etc/profile and add the following lines at the bottom. You may already have the LD_LIBRARY_PATH variable defined, therefore simply add this path to it.


Now the WebLogic plug in uses an Oracle Wallet to store the required certificates.You'll need to copy the self signed certificate from the IRM server over to the Apache server. Copy over the MyOwnSelfCA.cer.der into the same folder where you are storing your public certificates, in my example this is /oracle/secure. It's worth mentioning these files should ONLY be readable by root (the user Apache runs as).

Now lets create an Oracle Wallet and import the self signed certificate from the IRM server. The file orapki was included in the bin folder of the Apache 1.1 plugin zip you extracted.

orapki wallet create -wallet /oracle/secure/my-wallet -auto_login_only
orapki wallet add -wallet /oracle/secure/my-wallet -trusted_cert -cert MyOwnSelfCA.cer.der -auto_login_only

Finally change the httpd.conf to reflect that we want the WebLogic Apache plug-in to use HTTPS/SSL and not just plain HTTP.

<IfModule mod_weblogic.c>
   WebLogicPort 16101
   SecureProxy ON
   WLSSLWallet /oracle/secure/my-wallet
   WLLogFile /tmp/wl-proxy.log

Then restart Apache once more and you can go back to the browser to test the communication. Opening the URL will proxy your request to the WebLogic server at

At this point you have a fully functional Oracle IRM service, the next step is to create a sealed document and test the entire system.

Quick guide to Oracle IRM 11g: Server configuration

Quick guide to Oracle IRM 11g index

Welcome to the second article in this quick quide to Oracle IRM 11g. Hopefully you've just finished the first article which takes you through deploying the software onto a Linux server. This article walks you through the configuration of this new service and contains a subset of information from the official documentation and is focused on installing the server on Oracle Enterprise Linux. If you are planning to deploy on a non-Linux platform, you will need to reference the documentation for platform specific information.



  1. Introduction
  2. Create IRM WebLogic Domain
  3. Starting the Admin Server and initial configuration 


In the previous article the database was prepared, the WebLogic Application Server installed and the files required for an IRM server installed. But we don't actually have a configured system yet. We need to now create a WebLogic Domain in which the IRM server will run, then configure some of the settings and crypography so that we can create a context and be ready to seal some content and test it all works. This article doesn't cover the configuration of SSL communication from client to server. This is quite a big topic and a separate article has been dedicated for this area.

In these articles I also use the hostname, to reference the IRM server and later on use the hostname in reference to the public facing service.

Create IRM WebLogic Domain

First step is creating the WebLogic domain, in a console switch to the newly created IRM installation folder as shown below and we will run the domain configuration wizard.

[oracle@irm /]$ cd /oracle/middleware/Oracle_IRM/common/bin

[oracle@irm bin]$ ./

Note: A common mistake when installing on a Windows platform is to run the config.cmd from the "Start- All Programs" in Windows. This is not the same utility as config.cmd under ECM_HOME\common\bin.


First thing the wizard will ask is if you wish to create a new or extend an existing domain. This guide is creating a standalone system so you should select to create a new domain.

Next step is to choose what technologies from the Oracle ECM Suite you wish this domain to host. You are only interested in selecting the option "Oracle Information Rights Management". When you select this check box you will notice that it also selects "Oracle Enterprise Manager" and "Oracle JRF" as these are dependencies of the IRM server.

You then need to specify where you wish to place the domain files. I usually just change the domain name from base_domain or irm_domain and leave the others with their defaults.

Now the domain will have a single user initially and by default this user is called "weblogic". I usually change this account name to "sysadmin" or "administrator", but in this guide lets just accept the default.

With respects to the next dialog, again for eval or dev reasons, leave the server startup mode as development. The JDK should also be automatically detected.

We now need to provide details of the database. This guide is using the Oracle 11gR2 database and the settings I used can be seen in the image to the right.

There is a lot of configuration that can now be done for the admin server, any managed servers and where the deployments reside. In this guide I am leaving all of these to their defaults so do not check any of the boxes. However I will on this blog be detailing later how you can go back and setup things such as automated startup of an IRM server which require changes to these default settings. But for now, lets leave it all alone and just click next.

Now we are ready to install. Note that from this dialog you can scroll the left window and see there are going to be two servers created from the defaults. The AdminServer which is where you modify settings for the WebLogic Server and also hosts the Oracle Enterprise Manager for IRM which allows to monitor the IRM service performance and also make service related settings (which we shortly do below) and the IRM_server1 which hosts the actual IRM services themselves. So go right ahead and hit create, the process is pretty quick and usually under 10 minutes.

When the domain creation ends, it will give you the URL to the admin server. It's worth noting this down and the URL is usually;

Starting the Admin Server and initial configuration

First thing to do is to start the WebLogic Admin server and review the initial IRM server settings. In this guide we are going to run the Admin server and IRM server in console windows, in another article I will discuss running these as background services. So for now, start a console and run the Admin server by doing the following.

cd /oracle/middleware/user_projects/domains/irm_domain/


Wait for the server to start, you are looking for the following line to be reported in the console window.

<BEA-00360><Server started in RUNNING mode>

First step is configuring the IRM service via Enterprise Manager. Now that the Admin server is running you can point a browser at Login with the username and password you supplied when you created the domain.

In Enterprise Manager the IRM service administrator is able to make server wide configuration. However finding where to access the pages with these settings can be a bit of a challenge. After logging in on the left you'll see a tree containing elements of the Enterprise Manager farm Farm_irm_domain. Open up Content Management, then Information Rights Management and finally select the IRM node. On the right then select the IRM menu item, navigate to the Administration section and now we have four options, for now, we are just going to look at General Settings. The image on the right proves that a picture is worth a thousand words (or 113 in this case).

The General Settings page allows you to set the cryptographic algorithms used for protecting sealed content. Unless you have a burning need to increase the key lengths or you need to comply to a regulation or government mandate, AES192 is a good start. You can change this later on without worry. The most important setting here we need to make is the Server URL. In this blog article I go over why this URL is so important, basically every single piece of content you protect with Oracle IRM is going to have this URL embedded in it, so if it's wrong or unresolvable, then nobody can open the secured documents. Note that in our environment we have yet to do any SSL configuration of the service. If you intend to build a server without SSL, then use http as the protocol instead of https. But I would recommend using SSL and setting this up is described in the next article.

I would also probably up the device count from 1 to 3. This means that any user can retrieve rights to access content onto 3 computers at any one time. The default of 1 doesn't really make sense in development, evaluation nor even production environments and my experience is that 3 is a better number.

Next step is to create the keystore for the IRM server. When a classification (called a context) is created, Oracle IRM generates a unique set of symmetric keys which are used to secure the content itself. These keys are then encrypted with a set of "wrapper" asymmetric cryptography keys which are stored externally to the server either in a Java Key Store or a HSM. These keys need to be generated and the following shows my commands and the resulting output.

One common error here is using the wrong keytool. In my guide I am using Oracle Enterprise Linux (Basically RedHat EL) and by default it ships with a GNU version of Java and a keytool that doesn't work as well. Make sure you are using the keytool in the right Java distribution. Check this with the command;

[oracle@irm ~]$ which java

Don't use the keytool that ships with Linux, its in /usr/bin/

I have greyed out the responses from the commands so you can see the input a little easier.

[oracle@irm ~]$ cd /oracle/middleware/wlserver_10.3/server/bin/

[oracle@irm bin]$ ./



Your environment has been set.

[oracle@irm bin]$ cd /oracle/middleware/user_projects/domains/irm_domain/config/fmwconfig/

[oracle@irm fmwconfig]$ keytool -genkeypair -alias oracle.irm.wrap -keyalg RSA -keysize 2048 -keystore irm.jks

Enter keystore password:

Re-enter new password:

What is your first and last name?

[Unknown]: Simon Thorpe

What is the name of your organizational unit?

[Unknown]: Oracle

What is the name of your organization?

[Unknown]: Oracle

What is the name of your City or Locality?

[Unknown]: San Francisco

What is the name of your State or Province?

[Unknown]: CA

What is the two-letter country code for this unit?

[Unknown]: US

Is CN=Simon Thorpe, OU=Oracle, O=Oracle, L=San Francisco, ST=CA, C=US correct?

[no]: yes

Enter key password for

(RETURN if same as keystore password):

At this point we now have an irm.jks in the directory /oracle/middleware/user_projects/domains/irm_domain/config/fmwconfig. The reason we store it here is this folder would be backed up as part of a domain backup. As with any cryptographic technology, DO NOT LOSE THESE KEYS OR THIS KEY STORE. Once you've sealed content against a context, the keys will be wrapped with these keys, lose these keys, and you can't get access to any secured content, pretty important.

Now we've got the keys created, we need to go back to the IRM Enterprise Manager and set the location of the key store. Going back to the General Settings page in Enterprise Manager scroll down to Keystore Settings. Leave the type as JKS but change the location to;



and hit Apply.

The final step with regards to the key store is we need to tell the server what the password is for the Java Key Store so that it can be opened and the keys accessed. Once more fire up a console window and run these commands (again i've greyed out the clutter to see the commands easier). You will see dummy passed into the commands, this is because the command asks for a username, but in this instance we don't use one, hence the value dummy is passed and it isn't used.

[oracle@irm fmwconfig]$ cd /oracle/middleware/Oracle_IRM/common/bin/

[oracle@irm bin]$ ./

... lots of settings fly by...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands


Connecting to t3:// with userid weblogic ...

Successfully connected to Admin Server 'AdminServer' that belongs to domain

Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire
security, the SSL port or Admin port should be used instead.


Location changed to domainRuntime tree. This is a read-only tree with DomainMBean
as the root.

For more help, use help(domainRuntime)


Already in Domain Runtime Tree


At last we are now ready to fire up the IRM server itself. The domain creation created a managed server called IRM_server1 and we need to start this, use the following commands in a new console window.

cd /oracle/middleware/user_projects/domains/irm_domain/bin/

./ IRM_server1

This will start up the server in the console, unlike the Admin server, you need to provide the username and password for the service to start. Enter in your weblogic username and password when prompted. You can change this behavior by putting the password into a file, read more about this in the WebLogic Server documentation. Once running, wait until you see the line;

<Notice><WebLogicServer><BEA-000360><Server started in RUNNING mode>

At this point we can now login to the Oracle IRM Management Website at the URL.

The server is just configured for HTTP at the moment, no SSL involved. Just want to ensure we can get a working system up and running. You should now see a login like the image on the right and you can now login using your weblogic username and password.

The next article in this guide goes over adding SSL and now testing your server by actually adding a few users, sealing some content and opening this content as a user.


Quick guide to Oracle IRM 11g: Server installation

Quick guide to Oracle IRM 11g index

This is the first of a set of articles designed to assist with the successful installation, configuration and deployment of a document security solution using Oracle IRM. This article goes through a set of simple instructions which detail how to download, install and configure the IRM server, the starting point for building a document security solution. This article contains a subset of information from the official documentation and is focused on installing the server on Oracle Enterprise Linux. If you are planning to deploy on a non-Linux platform, you will need to reference the documentation for platform specific information.


  1. Introduction
  2. Downloading the software
  3. Preparing a database
  4. Creating the schema
  5. WebLogic Server installation
  6. Installing Oracle IRM



Because we are using Oracle Enterprise Linux in this guide, and before we get into the detail of IRM, i'd like to share some tips with Linux to make life a bit easier.
  1. Use a 64bit platform, IRM 11g runs just fine on a 32bit server but with 64bit you will build a more future proof service.
  2. Download and install the latest Java JDK package. Make sure you get the 64bit version if you are on a 64bit server.
  3. Configure Linux to use a good Yum server to simplify installing packages. For Oracle Enterprise Linux we maintain a great public Yum here.
  4. Have at least 20GB of free disk space on the partition you intend to install the IRM server. The downloads are big, then you extract them and then install. This quickly consumes disk space which you can easily recover by deleting the downloaded and extracted files after wards. But it's nice to have the disk space spare to keep these around in case you need to restart any part of the installation process again.

Downloading the software

OK, so before you can do anything, you need the software install kits. Luckily Oracle allows you to freely download every technology we create. You'll need to get the following;

 You can use Microsoft SQL server 2005 or 2008, in this guide i've used Oracle RDBMS 11gR2 for Linux.

Preparing the database

I'm not going to go through the finer points of installing the database. There are many very good guides on installing the Oracle Database. However one thing I would suggest you think about is enabling TDE, network encryption and using Database Vault. These Oracle database security technologies are excellent for creating a complete end to end security solution. No point in going to all the effort to secure document access with IRM when someone can go directly to the database and assign themselves rights to documents. To understand this further, you can see a video of the IRM service using these database security technologies here.

With a database up and running we need to create a schema to hold the IRM data. This schema contains the rights model, cryptographic keys, user account id's and associated rights etc.

Creating the IRM database schema

Oracle uses the Repository Creation Tool which builds your schema, extract the files from the rcu zip. Then in a terminal window;

cd /oracle/install/rcu/bin


This will launch the Repository Creation Tool and you will be presented with the image to the right. Hit next and continue onto the next dialog.

You are asked if you are going to be creating a new schema or wish to drop an existing one, you obviously just need to click next at this point to create a new schema.

The RCU next needs to know where your database is so you'll need the following details of your database instance. Below, for reference, is the information for my installation.


Port: 1521 (This is the default TCP port for the Oracle Database)

Service Name: Note this is not the SID, but the service name.

Username: sys

Password: ********


And then select next.

Because the RCU contains schemas for many of the Oracle Technologies, you now need to select to just deploy the Oracle IRM schema. Open the section under "Enterprise Content Management" and tick the "Oracle Information Rights Management" component. Note that you also get the chance to select a prefix which defaults to "DEV" (for development). I usually change this to something that reflects my own install. PROD for a production system, INT for internal only etc.

The next step asks for the passwords for the schema users. We are only creating one schema here so you just enter one password. Some brave souls store this password in an Excel spreadsheet which is then secure against the IRM server you're about to install in this guide.

Nearing the end of the schema creation is the mapping of the tablespaces to the schema. Note I had setup a table space already that was encrypted using TDE and at this point I was able to select that tablespace by clicking in the "Default Tablespace" column.

The next dialog confirms your actions and clicking on next causes it to create the schema and default data. After this you are presented with the completion summary.

WebLogic Server installation

The database is now ready and the next step is to install the application server. Oracle IRM 11g is a JEE application and currently only supported in Oracle WebLogic Server. So the next step is get WebLogic Server installed, which is pretty easy. Depending on the version you download, you either run the binary or for a 64 bit platform (like mine) run the following command.

java -d64 -jar wls1033_generic.jar

And in the resulting dialog hit next to start walking through the install.

Next choose a directory into which you will install WebLogic Server. I like to change from the default and install into /oracle/. Then all my software goes into this one folder, all owned by the "oracle" user.

The next dialog asks for your Oracle support information to ensure you are kept up to date. If you have an Oracle support account, enter your details but for most evaluation systems I leave these fields blank.

Again, for evaluation or development systems, I usually stick with the "Typical" install type which you are next asked for.

Next you are asked for the JDK which will be used for the server. When installing from the generic jar on a 64bit platform like in this guide, no JDK is bundled with the installer. But as you can see in the image on the right, that it does a good job of detecting the one you've got installed.

Defaults for the install directories are usually taken, no changes here, just click next.

And finally we are ready to install, hit next, sit back and relax. Typically this takes about 10 minutes.

After the install, do not run the quick start, we need to deploy the IRM install itself from which we will create a new WebLogic domain. For now just hit done and lets move to the final step of the installation process.

Installing Oracle IRM

The last piece of the puzzle to getting your environment ready is to deploy the IRM files themselves. Unzip the Oracle Enterprise Content Management 11g zip file and it will create a Disk1 directory. Switch to this folder and in the console run ./runInstaller. This will launch the installer which will also ask for the location of the JDK. Look at the image on the right for the detail.

You should now see the first stage of the IRM installation. The dialog warns you need to have a WebLogic server installed and have created the schema's, but you've just done all that above (I hope) so we are ready to go.

The installer now checks that you have all the required libraries installed and other system parameters are correct. Because nearly all of my development and evaluation installations have the database server on the same system, the installer passes these checks without issue... Next...

Now chose where to install the IRM files, you must install into the same Middleware Home as the WebLogic Server installation you just performed. Usually the installer already defaults to this location anyway. I also tend to change the Oracle Home Directory to Oracle_IRM so it's clear this is just an IRM install.

The summary page tells you about space needed to deploy the files. Unfortunately the IRM install comes with all of the other Oracle ECM software, you can't just select the IRM files, everything gets deployed to disk and uses 1.6GB of space! Not fun, but Oracle has to package up similar technologies otherwise we would have a very large number of installers to QA and manage, again, not fun. Hit Install, time for another drink, maybe a piece of cake or a donut... on a half decent system this part of the install took under 10 minutes.

Finally the installation of your IRM server is complete, click on finish and the next phase is to create the WebLogic domain and start configuring your server.

 Now move onto the next article in this guide... configuring your IRM server ready to seal your first document.


Oracle IRM protects and tracks your sensitive information no matter where it goes. It combines business friendly encryption with role based usage rights and auditing.

11g quick guide


« June 2016