Insights into information rights management

Complete guide to Oracle IRM (Part 4): Using Windows authentication

Due to an increase in customer activity I have been unable get this guide completed as quick as I would like, sorry! However a whole load of people have been configuring IRM servers to leverage the advantages of using Windows authentication and as such I realized I should add another section to the proposed guide.

Advantages of using Windows authentication

When using sealed content several things are needed for authorized users to successfully gain access. The aim of any IRM deployment should always be to make use of sealed content as transparent as possible for authorized users. The security of IRM should only be evident when someone attempts to do something they are not allowed to, such as copy/pasting information from the document or trying to take a screen shot. The following are required to allow a user to open sealed content.

Oracle IRM Desktop software must be installed

Rendering application for the content they are opening should be installed, e.g. Acrobat Reader if they are opening sealed PDF content

User must successfully authenticate to the IRM server using either standard or Windows authentication

User must have been given rights to the classification the content is sealed to

In a corporate environment you typically have access to the end user desktop and therefore are able to deploy the IRM Desktop without the users knowledge. The Oracle IRM Desktop can be deployed silently (page 5 of install guide) and rendering applications are also commonly installed, such as Acrobat Reader and Microsoft Office.

Corporations commonly use Windows authentication as part of an Active Directory deployment. Users authenticate to the workstation/laptop using an account from the Active Directory repository and the workstation/laptop must be a member of either the domain/forest the user account is in, or at least a member of a trusted domain. Using this authentication mechanism with Oracle IRM means that a user doesn't need to re authenticate when accessing sealed documents, because IRM can use their already authenticated Windows credentials.

Ultimately you are trying to achieve the following experience;

The Oracle IRM Desktop is installed on end users machines without their interaction

Users are automatically setup on the IRM server to use Windows authentication and have rights to the relevant classifications

Sealed documents are automatically protected in the repository or network file shares

An authorized user then logs into their Windows machine, double clicks on a sealed document and it opens

The only initial difference for the end user is that they may see the Oracle IRM toolbar at the top of the document.

Oracle IRM and the user identity

This article will go into the details of configuring the IRM server to be able to authenticate users using Windows authentication and also how to use the Oracle IRM Directory Gateway to import users from your Active Directory into the IRM server. For deploying the IRM Desktop automatically, please refer to the installation guide on page 5.

The way in which Oracle has implemented Windows authentication in IRM isn't immediately obvious and there are some sound reasons why it works as it does. First we must look at how the IRM Desktop handles controlling access to sealed content.

User double clicks on a sealed document

Windows looks up the extension of the document (.sdoc, .spdf etc) and loads the Oracle IRM Desktop, passing it the reference to the file

IRM Desktop authenticates end user

If authentication is successful IRM Desktop validates if user has rights to the document

If rights exist, document is securely opened for the user

Before looking at the authentication, lets look at how the IRM Desktop determines rights to content. Each sealed document contains information about its classification and what server it was sealed against. When the user opens sealed content the IRM Desktop, after user authentication, does a rights lookup and tries to determine if the user has access to the content. If the IRM Desktop had to communicate to the IRM server, rights are then cached to the local encrypted offline storage. The IRM Desktop will then on subsequent opening of content use the offline cached right as long as the offline period is valid. Remember that each right given to a user in a classification can have a different offline period. This allows very sensitive information to have a short offline lease so that rights changes on the server can have impact on the users within short periods of time, e.g. hours. Other rights may have offline periods of days or sometimes weeks.

When rights are cached offline, so is the users identity. The identity describes the user and what server they are on. For the above rights lookup, the IRM Desktop must obtain a valid identity.

Technical detail of how Oracle IRM authenticates Windows users

So this is where we get the Windows authentication piece. For a valid identity for a user that is configured to use Windows authentication, we need to authenticate them. When the workstation is offline we use the same mechanism that allows a user log into their Windows desktop without having a direct connection to the domain. When the user is online, we must authenticate the users Windows credentials. When successful the users identity is then combined with any rights to determine access to content.

For successful Windows authentication the following must be true;

User is logged on to a Windows machine using their Windows account

User account on the IRM server is mapped to their Windows account

Windows machine must be part of the corporate domain

Oracle IRM server must have a valid authentication path to the corporate domain

Network communication for Windows authentication

The IRM Desktop uses Windows API's to get details of the logged in user. This takes the form of an NTLM package. This information is then sent from the IRM Desktop to the IRM Server using our own communications protocol. This is a very important point.

IRM Desktop communication to IRM server for Windows authentication does not use traditional Windows protocols, instead we simply pass the Windows user credentials inside our own encrypted protocol to the IRM server.

This has the great advantage that the same protocol for standard IRM authentication is also used for Windows authentication. Simplifying the deployment model whilst maintaining security. It also means you increase the chances of successful communication, because the IRM protocol communication will have already been enabled irrespective of what authentication model you use. This protocol is designed for effective communication no matter where the client is coming from. The encrypted protocol is tunneled inside HTTP packets marked with the mime type "application/octet-stream" and the IRM encrypted protocol is the binary payload in the HTTP packets.

Once the IRM server receives the data, a classic negotiate, challenge and response occurs with both the client and server using the Windows authentication API, but tunneling the results in our protocol. The IRM server therefore is using Windows authentication local to the server the IRM service is running on. This means the IRM server must have a valid path to the domain controllers for domain the user is a member of. More about ensuring this setup later, but at the end of this communication process the IRM server discovers the users Windows SID.

Windows user look up in IRM server

Now that the IRM server has been able to verify the Windows identity of the user opening content it has the unique identifier from Windows, the SID. This SID is what the IRM server uses to map IRM accounts to Windows accounts for authentication. The IRM server then performs a local look up in the database and if it finds that this Windows user has been mapped to an account, then the IRM server is able to return the identity to the IRM Desktop. At this point the Windows user has been fully authenticated, an IRM identity established and the IRM Desktop can continue to look up rights for the user.

Setting up an IRM server to authenticate Windows domain users

So how do you ensure the IRM server is able to complete the above steps for authenticating Windows accounts accessing sealed content? The IRM server runs on a Windows server, this Windows server must therefore be able to authenticate users against the domains which their accounts exist.

Now this presents a problem, because nearly every IRM server is deployed in the DMZ and therefore any connection from a publicly accessible server back to the corporate user directories presents a security risk. However because the IRM server is just calling standard Windows APIs to authenticate the users, there are many best practice solutions to reducing this risk and deploying an effective solution.

The following are the main methods I have seen customers use to ensure the IRM server can authenticate against the corporate domain.

Promote the IRM Windows server to a domain controller with its own forest/domain

This is the most common scenario I have seen with our customers. Before installing any of the IRM services, the Windows server is promoted to create an Active Directory Domain. Then the IRM services (IRM Server, Management Website) are installed. Then a one way trust relationship needs to be created from this domain to the corporate domain, this lets the IRM domain authenticate and trust users from the corporate domain, yet the IRM domain itself is untrusted. This trust creation involves communication from the DMZ to the corporate network where the corporate domain controllers reside and therefore firewalls needs to be configured correctly.

The pro's of this approach are that you have an entirely self contained environment which, if compromised, only affects the IRM service. The trust relationship ensures a compromised domain controller has no rights to the corporate network.

The downside of this approach is that you need to open firewall access from the DMZ to domain controllers on the corporate network and sometimes this isn't possible due to network design or security policy.

Also note that if you decide to promote a Windows server to a domain controller after you've installed the Oracle IRM Management Website I've seen problems with IIS and permissions as it runs on the newly configured domain controller. A re-installation of IIS and the Management Website does resolve the issues but if it can be avoided it would be wise.

Host another server as the IRM domain and make the IRM server a member of this domain

This solution is very similar to the above, but some customers have already had to create a DMZ domain which trusts the corporate network for other DMZ services which require Windows authentication. In this instance making the IRM server a member of the existing domain is adequate.

Pro's of this approach are you use an existing and proven setup, if it already exists. Also just changing the servers domain membership doesn't have the same impact on the existing IRM installation and therefore can be done after the IRM service has been fully configured.

Problems with this solution are that you increase the infrastructure required for the solution and if the IRM server is compromised, it has a wider impact if that compromise affects the DMZ domain in anyway.

Host the IRM server on the corporate network and proxy all requests

Finally another option, and this is a rare choice but sometimes the only choice. The IRM server is hosted on the corporate domain and all public requests are proxied from the DMZ facing firewall/routers to the IRM server. To proxy these requests you setup a reverse proxy server to take traffic the internet to the IRM server. Note that this only requires the proxy of the HTTP packets in which the IRM encrypted protocol is tunneled.

The pro of this is you don't need to have any exposure of your corporate domain in the DMZ because the IRM service can be a member server directly to the corporate domain. Also the traffic you are forwarding to the IRM server is simple to manage and control. The IRM server has been through Oracle security validation and is heavily tested such that we've never had reported any compromise or security issue (read buffer overruns, SQL injection etc) as a result of communication with the IRM server.

The downside is if the IRM server is somehow compromised, that server is sat on your corporate network.

Summary

With all the of the options above it is best practice to ensure that the Windows server is regularly updated with security patches from Microsoft, that it is monitored for availability and security purposes and that proper backups of the system are taken so that in the advent of a disaster either due to physical or software failure, or security compromise, the system can be returned to operation in a timely manner.

This implementation of enabling Windows authentication for access to sealed content works very nicely with the requirement of having the service accessed from the public internet.

This article only covers how to understand and enable the IRM service to authenticate Windows users. The next article in this guide actually walks through the steps of mapping IRM accounts to Windows accounts, testing the setup works and then how to configure the Oracle IRM Directory Gateway to manage the automation of synchronizing these accounts from Active Directory with the IRM server.