AIR 1.5.1, released today, is not quite a typical dot release containing just bug fixes. It also contains one minor—albeit useful—new feature.
Applications can already detect when they’ve been invoked by listening for the InvokeEvent that is dispatched by NativeApplication. This is dispatched when they’re started from the command line, via the GUI, or by opening an associated file.
Applications can also register to be launched automatically during user login. However, prior to 1.5.1, there was no reliable way to distinguish this login case from the the other reasons an application might be started. That turns out to be awkward: In the login case, applications often want to avoid opening new windows. In all other cases, they generally want to make sure they do open a new window.
Starting with AIR 1.5.1, the InvokeEvent class contains a new property, “reason”, that distinguishes between these two cases. It has two possible values: “standard” and “login”. These are, I hope, self-explanatory.
Note that in order to use this new API, you must update your application to use the AIR 1.5.1 namespace by changing its descriptor. (There are no other changes to the descriptor schema in this release.) The new descriptor will trigger an auto-update to AIR 1.5.1 should someone attempt to install your application against an older version, thus guaranteeing that the new API will actually be available.
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:
- Create or select a certificate authority that will issue certificates for each client machine.
- Configure your web server to require TLS client authentication.
- Configure your web server to trust, for TLS authentication purposes, certificates issued by your certificate authority.
Then, for each client:
- Generate a private key for the client.
- Generate a certificate signing request for the client, based on this key.
- Create, using your certificate authority, a signed certificate for the client.
- 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.