Posts in Category "enterprise"

New Installation and Deployment Options in AIR 3

It is with great pleasure (and a little bit of relief) that I report that AIR 3 will deliver new and much improved installation and deployment options for the desktop. These options enable installation without administrative rights, GPO-based deployment of AIR applications, XCOPY deployment, run-in-place from flash drives, tight binding to specific versions of AIR, and more.

These advantages arise from two new key capabilities:

  1. Captive runtimes. Already used on iOS, this capability allows a copy of the AIR runtime to be embedded with each AIR application. This capability is now supported across Mac OS, Windows, and Android, too.
  2. Custom installers. The application packaging tool, adt, can now be used to generate an application’s file set instead of a complete installer. The file set is a complete copy of the application, capable of being run in place. Or, you can package it up in your own custom installer, whether that’s an MSI for GPO, a PKG for Mac OS, or something else.
For a more comprehensive overview, please see Installation and Deployment Options in AIR 3 on the Adobe Developer Connection.

Deployment Configuration and AIR Applications

All but the simplest of applications accept, or even require, configuration data that affects their behavior. These settings might affect the appearance of a UI element, an algorithm used to compute a calculation, or where to locate a service, such as a database, required by the application.

AIR developers are often tempted to embed this configuration data into the application package. This appears to be a convenient option because standard methods for deploying AIR applications, whether on the desktop or on mobile devices, don’t provide any alternative way of packaging this data with the application. On the other hand, it is inconvenient if more than one configuration is required, because then a separate package must be created, signed, and managed for each set of configuration options.

I encourage you to avoid packaging configuration options with your application. In addition to creating a package management problem that is otherwise avoided, it makes it impossible to move a copy of the application between different environments, be they test, staging, production, or something else. (Jez Humble and David Farley do an excellent job of covering this issue in their book, Continuous Delivery.)

Instead, I encourage you to deploy configuration data via another mechanism. The simplest approach is to use a file deployed to a well-known location. This approach works well in the enterprise, where it has a well-established history (think /etc on Unix), makes the data easily accessible to AIR applications, and is support by most deployment tools. If you’re in a closed environment your platform of choice might offer other options; Windows, for example, offers Active Directory.

It can be useful, by the way, to have a built-in default set of values, especially in the consumer space. This approach makes it easier for your application to be tested against a mocked up service provider in house and then, when deployed, automatically target the real service. For example, an application that talks to Facebook might use your mocked Facebook service in-house, but when deployed by customers always connect directly to Facebook.

As implied above, Adobe does not provide tools that directly support the deployment of configuration data. The AIR team elected not to enter this space because (a) it’s populated by existing players, such as IBM and Microsoft, with deep expertise in this area, and (b) a significant number of customers we speak with already have an existing solution in place. Our approach, then, has been to integrate with existing deployment tools and their capabilities. For more on this, see Distributing AIR in the Enterprise, by Peter Albert and Michael Labriola.

Upgrade Codes, Product Codes, and Silent AIR Application Uninstall

Those who sign up for the Adobe AIR redistribution license have had the ability to silently install and uninstall AIR applications since the AIR 1.0 release. Unfortunately, the silent uninstall support on Windows is a bit rough. I’ve included below a link to a utility I wrote that eases the problem a bit. But first, a little background on the issue.

When an AIR application is installed on Windows, it’s installed via Windows Installer. This is a good thing; it allows leveraging all the capabilities of Windows Installer. For example, silently uninstalling an AIR application on Windows can be accomplished directly via the “msiexec” utility that is part of Windows. All you need to provide to msiexec is the product code of the application.

AIR applications don’t inherently contain product codes—they’re specific to Windows Installer—and you won’t, for example, find one in your application descriptor. Furthermore, Windows Installer requires that product codes change—even for the same application—under certain circumstances. In order to play it safe, AIR generates a unique product code for each version of your application. This, in turn, means you need to know the product code associated with the specific installed version of the application in order to uninstall it. This is a hassle.

Fortunately, Windows Installer also associates an upgrade code with each application. An upgrade code is basically an application identifier that never changes and, given an upgrade code, you can look up the corresponding product code. The mapping from upgrade code to product code is stored in the registry at application install time. Like product codes, AIR generates an upgrade code for your application. Unlike product codes, upgrade codes are the same across all versions of your application and are easily determined via the OSID application that comes with the redistribution support.

Unfortunately, the only way to look up that mapping is via the MsiEnumRelatedProducts() system call, and the msiexec utility won’t do it for you. (Theoretically you can look this mapping up yourself in the registry, but that turns out to be fairly complicated, and I’m not sure it can be done reliably.)

How much of a problem this is depends on the uninstall technology you’re using, whether or not it can perform this lookup for you, and whether or not you’re in a position to write a few lines of C code to perform the lookup. For anyone out of luck on all counts—or just curious—I’ve written a small utility called “msiu2p”. You can download msiu2p here. (The zip package includes the executable and the source.)

Here’s an example:

c:\ msiu2p {8DA920D5-C41C-42E0-BF31-87BA49984EE4}

Of course this isn’t useful just for AIR applications, either: It’s a handy complement to msiexec for any application using Windows Installer.

We plan to improve AIR’s intrinsic support for this kind of thing in an upcoming release. In the meantime, I hope this utility will help fill the gap for those who need it.

Using TLS Client Authentication with AIR Applications

Passwords remain de rigueur for authenticating clients, but applications with stricter security requirements may require an additional authentication factor. Adobe AIR-based applications can use client-side Transport Layer Security (TLS, also still referred to as SSL) authentication to add this second factor.

Many developers are familiar with the use of TLS in the HTTPS protocol to establish the identity of the server to which a client is connected. The server uses a private key to assert its identity, which is in turn validated via a trusted certificate installed on the client machine. What is less well known is that TLS authentication can be symmetric. The same certificate-based validation scheme can be used to authenticate both the server to the client and the client to the server.

The setup details will vary based on which web server and operating systems you’re running. Still, here’s a sketch of the steps involved to get it working. On the server:

  1. Create or select a certificate authority that will issue certificates for each client machine.
  2. Configure your web server to require TLS client authentication.
  3. Configure your web server to trust, for TLS authentication purposes, certificates issued by your certificate authority.

Then, for each client:

  1. Generate a private key for the client.
  2. Generate a certificate signing request for the client, based on this key.
  3. Create, using your certificate authority, a signed certificate for the client.
  4. Install this certificate into the system trust store on the client.

Note that none of these steps are specific to AIR. AIR uses the underlying OS network stack for HTTP, HTTPS, and TLS support. All AIR TLS connections use the system trust store to look up certificates and access private keys. This helps produce consistent behavior across all applications on your machine, whether they are built on AIR or not. If you have an existing enterprise solution in place for managing the trust store, it also means you can re-use this solution to distribute and maintain certificates and keys for AIR applications, too.

The certificates used in TLS client authentication, by virtue of being installed on and tied to a specific machine, authenticate by proving something you have. This makes them a perfect complement to passwords, which are something you know. Together, they create a reasonable and available two-factor authentication scheme for your AIR applications.

More on AIR Enterprise Deployment

Peter Albert and Michael Labriola have written a new article for the Adobe Developer Center: Distributing AIR in the Enterprise. It describes how to deploy AIR and AIR-based applications in the enterprise via:

  • Microsoft Systems Management Server,
  • Microsoft System Center Configuration Manager, and
  • IBM Tivoli Provisioning Manager Express.


Redistribution and Silent Install

When I first posted about AIR’s support for enterprise deployment, there was some confusion over whether or not silent installation was allowed. That was problematic because, in enterprise scenarios, silent install is generally required. (Note that it’s not required for all redistribution scenarios; some of those involve GUI-based installation from a CD, for example.)

When we released AIR 1.1 last month, we also made changes to the redistribution license and documentation to clarify this situation. Silent installation is now supported for anyone who has a redistribution agreement, whether that agreement was signed before or after these changes. For details, see the updated redistribution documentation.

Adobe AIR 1.1 Now Available

Adobe AIR 1.1 is now available. The major focus of this release is localization, both of the AIR installation UI as well as support for localizing AIR applications.

It also contains a new certificate migration feature, which allows you to transition from using a self-sign certificate to a CA-issued certificate. More on this in a later post.

For all the details, see the AIR 1.1 FAQ. Based on your feedback, we’ve tried to do a better job of highlighting the bugs we’ve fixed, too.


Adobe AIR for IT Administrators

We’ve just gone live with a new site for IT administrators who are deploying AIR in the enterprise. On this page you’ll find links to the reference documentation, white papers, and so on for the enterprise capabilities I’ve been discussing here.

We hope you find it helpful. We’ll be continuing to add to this site over time. More announcements coming soon!

Real, Live Enterprise AIR Applications

Yes, I’m going to continue to pound the AIR-in-the-enterprise drum for a while. Read Write Web has posted a nice article describing some real enterprise AIR applications that are already deployed and in use today.

I personally use the Employee Directory application on a daily basis. Here at Adobe we can also use a combination of Outlook and three different web apps to get access to this same information. Another interesting example of how aggregation of data and applications is changing.

Adobe AIR Enterprise Configuration

As I mentioned in my earlier post on enterprise deployment, Adobe AIR does support some enterprise configuration settings. There are three currently supported configuration items, specific to AIR:

  1. Enable/disable automatic AIR updates. If you’ve deployed AIR in a lock-down environment, you’ll want to disable automatic updates since users won’t be able to install them, anyway.
  2. Enable/disable the installation of AIR applications. If you want to limit users to applications already installed on their machine, you can disallow the installation of any additional AIR applications.
  3. Enable/disable the installation of AIR applications with unknown publishers. You might use this setting if you want to allow users to install applications, but only the less-risky applications that come from known publishers.

All of these options default to enabled. They can be configured in Windows-based enterprises via policy settings managed via Active Directory. For more information, see Administering Adobe AIR.