BCL easyPDF SDK
easyPDF SDK Usermanual
PDF Creator Programming API  |  Download Free Trial  |  Contact Us to Purchase

Using Impersonation

Impersonation is an alternative to the Loader Service, available in the Native .NET, Java, PHP, Python and C/C++ APIs.

If you choose to use Impersonation, the Loader Service does not have to be configured or started at all.

It is very important to understand that Impersonation only works on the server side. While the Loader Service works everywhere, you cannot use the Impersonation technique in a desktop application. This is not a disadvantage, as desktop applications do not require special handling.

Just like the Loader Service, Impersonation also requires the purchase of a special server license. Without this license server-side printing is impossible.

Native .NET API

The Printer object has a public member variable called LoaderSettings. This is where the UserName and Password is specified.

using(Printer printer = new Printer())
{
   printer.LoaderSettings.UserName = "easyPDF8User";
   printer.LoaderSettings.Password = "Password";

   printer.PrintJob.PrintOut(inputFileName, outputFileName);
}

The LoaderSettings must be set up right after the Printer object is created. Once you start using the Printer object at all, it is already too late to assign the LoaderSettings.

For a little more security, use SecurePassword instead of Password. While Password is just a string, SecurePassword is a SecureString, which means it is obfuscated and cannot be sniffed so easily.

using(Printer printer = new Printer())
{
   printer.LoaderSettings.UserName = "easyPDF8User";
   SecureString password = new SecureString()
   password.AppendChar('1');
   password.AppendChar('2');
   password.AppendChar('3');
   password.AppendChar('4');
   password.AppendChar('5');
   printer.LoaderSettings.SecurePassword = password;
   int dummy = printer.LibraryVersionMajor; // launch the easyPDF SDK worker process
   printer.LoaderSettings.SecurePassword = null;
   password.Dispose();

   printer.PrintJob.PrintOut(inputFileName, outputFileName);
}

Here we are using the LibraryVersionMajor property just to make sure the worker process starts, then we wipe the password out of the memory. Once the worker process is running, the password is not needed anymore. easyPDF doesn't store the password anywhere else.

If SecurePassword is specified, Password should not be used. If both are present, Password is ignored, and SecurePassword is used.

Note that if either UserName or (Secure)Password is missing, then you are not performing an Impersonation. Instead, the classic Loader Service is going to be used automatically when necessary.

Note that Impersonation cannot and will not be used on the desktop. If UserName and Password are specified inside a desktop application, they will be ignored.

Even though all major SDK objects (Printer, PDFProcessor, PDFConverter, PDFDocument) have a LoaderSettings member, only Printer mandates the use of Loader or Impersonation. The other SDKs should not require the use of LoaderSettings.

If you must gain access to files not accessible any other way, then you may use Loader or Impersonation with any of the four SDKs, although it is not recommended for anything but Printer.

Native Java API

The Printer object has two public member variables called userName and password. This is where the login information is specified.

Printer printer = new Printer();
try
{
   printer.userName = "easyPDF8User";
   printer.password = "Password";

   printer.getPrintJob().PrintOut(inputFileName, outputFileName);
}

Both userName and password must be set up right after the Printer object is created. Once you start using the Printer object at all, it is already too late to assign the user login information.

Note that if either userName or password is missing, then you are not performing an Impersonation.

Note that Impersonation cannot be used on the desktop. Please only specify userName and password on the server side, otherwise the external worker process cannot be launched, and easyPDF will fail with an exception.

Even though all major SDK objects (Printer, PDFProcessor, PDFConverter, PDFDocument) support userName and password, only Printer mandates the use of Loader or Impersonation. The other SDKs should not require the use of userName / password.

If you must gain access to files not accessible any other way, then you may use Loader or Impersonation with any of the four SDKs, although it is not recommended for anything but Printer.

Security Considerations

Unfortunately there is no way around having to store your easyPDF account password. You have many choices regarding where and how you want to store the password.

Storing your Impersonation password in your source code is not as bad as it sounds. No one can see your source code, unless your server gets hacked. In that case there is no point hiding your password anymore.

The most important thing is to make sure your password is not used anywhere else. Do not use the same password for easyPDF Impersonation that you use for your personal accounts (email, social media, banks). This is very important. If you are using a server-side database, that should have a different password as well.

If your organization requires your password to be encrypted, there are several choices:

All of the above solutions rely on the DPAPI. Unfrotunately, the DPAPI is only really secure when it is bound to a physical user account, which cannot be done on the server side, because the Local System account is not a physical user account.

As a result, it is very important to use a custom entropy, which significantly enhances the strength of the encryption. The problem is that now you have to store the entropy securely, which is just as impossible as securely storing the password itself.

The disadvantage of all forms of encryption is that you have to store the encryption key somewhere, which is not any easier than storing the password itself. If you encrypt the password, you also need to encrypt the encryption key, but then your encryption key that encrypts the encryption key that encrypts the password is still exposed. And no matter how deeply it is nested, some piece of information is always exposed. This is a viscious circle.

The two most important practices are the following:

Note that the Loader Service isn't inherently more secure, either. Internally it uses the same DPAPI as well to store an encrypted password in the registry.