Pursuit of Simplicity

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}

{A2BCA9F1-566C-4805-97D1-7FDC93386723}

c:\

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.

Posted by Oliver Goldman at 4:12 PM | Permalink | Comments (1)

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.

Posted by Oliver Goldman at 9:38 AM | Permalink | Comments (4)

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.
  

Enjoy!

Posted by Oliver Goldman at 10:08 AM | Permalink | Comments (0)

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.

Posted by Oliver Goldman at 12:53 PM | Permalink | Comments (4)

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.

Enjoy!

Posted by Oliver Goldman at 8:59 PM | Permalink | Comments (0)

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!

Posted by Oliver Goldman at 10:00 AM | Permalink | Comments (0)

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.

Posted by Oliver Goldman at 9:49 AM | Permalink | Comments (0)

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.

Posted by Oliver Goldman at 11:06 AM | Permalink | Comments (0)

Adobe AIR supports enterprise deployment. There, I've said it. We've had a bit of trouble getting this message out, so I wanted to be clear about this right up front.

Now, before anyone jumps all over me for this one, I'm also sure we could do a better job of supporting enterprise deployment. If you've deployed AIR in an enterprise setting and have thoughts on what we could do better, please send them our way.

If you aren't familiar with AIR's enterprise support—and, as I said, you're probably not—here's what you can do now, in AIR 1.0:

• You can deploy AIR and AIR-based applications via enterprise deployment tools like Microsoft SMS and IBM Tivoli,
  
• You can disable auto-update of both AIR and AIR-based applications, and
  
• You can configure which applications, if any, AIR will permit to be installed.
  

I'll dive into more detail on some of these items in future posts, but there's one more thing I want to cover now. If you want to deploy AIR in an enterprise setting from a centralized server of some sort, instead of deploying it from Adobe's download servers, then you're redistributing AIR. We typically allow this, but you do have to sign a redistribution license in order to be granted the necessary rights. See the redistribution site for further information.

Oh, and feel free to spread the word!

Posted by Oliver Goldman at 8:00 PM | Permalink | Comments (13)

Over the course of our beta releases I've fielded many, many questions about whether or not it would be possible to redistribute AIR and, if so, how that would work. We've promised this would be possible, but haven't allowed it with the beta releases. Now that 1.0 has arrived, I'm pleased to be able to deliver on this promise.

If you're interested in taking advantage of this, instructions are now posted. You'll be asked to accept a distribution agreement and, upon approval, will receive the necessary files and instructions for redistribution.

A couple of quick highlights:

• You cannot redistribute the runtime from your own web site. For web-based install, please use the browser API and our badged install capability.
  
• Writing your own bootstrapper is not necessary. If you want to use the standard AIR installation UI, you can use the provided installer as-is.
  
• 
  

Enjoy!

Posted by Oliver Goldman at 10:38 AM | Permalink | Comments (1)