AppLife Cloud

Controlling Access to AppLife Applications and Packages

AppLife Cloud provides an excellent channel to distribute custom software applications to Windows desktops and servers. For many subscribers, they publish their packages using the default anonymous access settings and it works great for them. But there are many scenarios where it becomes important to filter access to specific applications and packages. The most common scenario is for limiting new versions to testing and QA installations and then opening them up later for wider distribution. Whatever the scenario, when applications require limited access, AppLife Cloud provides a simple method that works well. Our method works like this…

A string token is assigned to each installation, called a Client Access Key (CAK).  Client Access Keys do not have to be unique.  Through your dashboard you can create lists of Client Access Keys.   These lists are assigned to Applications and AppLife Packages which determine their visibility to installations checking for packages.   It’s that simple. In this post, we’ll review how to work with Client Access Keys and Access Lists in AppLife Cloud.

Assigning Client Access Keys

Client Access Keys can be any string value and are specific to the applications domain. While individual installations don’t require unique Client Access Keys, we recommend creating unique keys for each application installation. This not only provides the most flexibility in controlling access to Applications and Packages, but it allows for better monitoring your install base throughout the life of your application within your AppLife online dashboard.

AppLife Manager

When using AppLife Manager on deployed clients, the Client Access Key is set when AppLife Manager is connected (registered) to your AppLife subscription. When installed independently on a computer, the Register Subscription command is used.

Setting Client Access Key through AppLife Manager

When AppLife Manager is installed through automation, a subscription is added through a Command Line Action.

AppLifeManagerInstallDir\AppLife Manager UI\RegisterNewServer.exe  <SubscriptionId> <ClientAccessKey> [<disableAppApprovals>]

Setting Client Access Key through Command Line

AppLife Controller API

When the AppLife API is used through NuGet to integrate an update process directly into your application, the Client Access Key is set as a property value of the Update Controller object.

Using an Update Controller to set Client Access Key

Creating Access Lists

Access Lists are collections of Client Access Keys that can be assigned to Applications and AppLife packages to control visibility of these assets.

Individual Access Lists are “owned” by an application and the editor is opened through the dashboard Application view.  When viewing any application in your dashboard, the Client Access view can be opened through the Application Menu.

Client Access Menu Option

From there you can control most of the features of Access Control.  Clicking to Manage Access Lists displays all of the applications Access Lists.  By selecting a list, you can edit that list, clone the list into a new one, delete it or copy the entries onto the clipboard.  You can also add a new list from here.

Access List Actions

When adding/editing a list, the list name is editable and a list of the Client Access Keys included in the list is displayed.  When adding a Client Access Key, the list of existing keys that don’t match the current entry are hidden from view.  This helps find an existing Client Access Key in a list and also prevents entering duplicates.

Editing an Access List

Bulk Add

To assist in adding an existing list of Client Access Keys, there is a Bulk Add option.  Using Bulk Add, multiple Client Access Keys can be added at the same time, one per line. This supports using the clipboard to paste from spreadsheets or query results.

Bulk Add Operation

Client Access API

In situations where Client Access Keys are managed from a separate supervisory system, Access Lists can be manipulated through the Client Access API.  This will allow lists to be created, removed and entries added and removed.  To use the Client Access API, it must be enabled per application and a token must be generated.  The different API actions are called through HTTP Post to the respective addresses.  More information is available in the AppLife Cloud documentation.

Sharing Lists

Access Lists are created and maintained for individual applications, however lists can be shared across all applications within an AppLife Subscription.  This allows a single set of lists to be maintained for subscribers with multiple applications that use some or all the same Access Lists.  To share an Access List, the list must be selected as shared.

On applications where this shared list is to be used, toggle the option to Use Shared Lists.  Any lists shared through any subscription application will be available for selection.

Share an Access List

Use a Shared List

Assigning Access Lists

With Access Lists created and shared as necessary, they can be assigned to Applications and Individual AppLife packages to control exposure to clients.  By default, new applications are configured for Anonymous access.  To filter access based on Client Access Keys, disable the Allow Anonymous Access setting, and then check the appropriate access lists that should be able to see the application.

Assigning Access Lists to an Application

Assign Lists to Individual Packages

Access to individual AppLife packages can be set during publishing and can be modified afterwards through the dashboard or through the AppLife Builder application.  A common use-case is to publish packages initially for testers, and then open it up for wider distribution through the dashboard later.  When publishing, the Version Access Mode options are Application, Version, and None.  When Version is selected, the Access List selections will override the application level selections.

Set Access Lists when publishing

Version Mode Access Entries can also be modified through AppLife Builder.

Modifying Version Access through AppLife Builder

Version Access Lists can also be assigned through the dashboard.  Select to edit the individual AppLife package properties by clicking on the row in the Application Versions table.

Versions Table. Click to Edit.
Modify Version Access List Assignment

Conclusion

Visibility of your Applications and AppLife packages published to your AppLife Cloud can be controlled by setting Client Access Keys on each installation and then assigning lists of your Client Access Keys to your Applications and packages.

The AppLife tooling provides the ability to easily integrate Access Control into your dev ops routine. This article provides instruction on how to accomplish access control using AppLife.

Explore Manager Deployment Options

The AppLife Cloud solution provides a turn-key custom software management system, enabling deployment and maintenance of your software that targets the Windows operating system. On your deployed clients, the AppLife Manager provides the significant task of orchestrating the discovery, download and execution of AppLife packages. In this post we’ll dive into AppLife Manager, looking at it’s options and features.

Visual Branding

AppLife Manager is a Windows Service that performs most of it’s work behind the scenes. Your users won’t often interact with Manager at all, but when they do we want them to know what they are interacting with. Namely your software and your company. AppLife Manager sits in the System Tray and pops up messages from time to time.

When the user does open the AppLife Manager user interface, there are options to adorn it with your company and your application visuals.

Publisher Settings

Your AppLife Subscription has settings that determine how your AppLife Manager header looks, as well as what is shown on the information form within AppLife Manager.

  • Organization
  • By-line
  • Publisher Image
  • First Name
  • Last Name
  • Phone
  • Email

By settings these values, your company information is displayed to the Applife Manager user.

Application Settings

For each application you can define a name and an image. We’ve already set the name of the application to First Look in the last post, where we created and published an installer for the application. You can also set an image setting that can be defined in the application properties view.

Putting this together, by changing a few properties in the AppLife Dashboard, we can transform the visual representation of our company and our applications within AppLife Manager.

Application Behavior

The behavior of AppLife Manager applications is customizable as well.

  • How often does an application check for new packages?
  • What happens when a new package is discovered. Apply automatically or prompt a user?
  • Restrict applying packages to off-peak times?

These behavior settings can be set globally for all clients, or you can allow these settings to be modified locally. Or, you can allow only specific clients to modify locally.

Check for Updates Frequency – Sets the number of minutes between checks. The default is 1440 (once a day), and can be set as low as every 5 minutes.

Apply Updates Automatically – When checked, updates will be applied automatically. If the application is running at the time of initiation, a prompt will be presented to any logged in user that is running the application. If any decline the update, it is postponed. If the application is not running, the update is applied immediately, unless an Off-Peak Time Windows is defined and the current time is not in the time window. In this case, the update is postponed until the start of the off-peak time window.

Disable Sending Failed Execution Logs – When an update fails, the execution log is posted back to the AppLife Cloud for troubleshooting and can be viewed in the dashboard. This post can be disabled.

Off-Peak Updating Time Window – It’s often advantageous to apply updates during off peak hours so as not to disturb daily operations. You can set a beginning time and number of hours to allow updates to be applied. When set, package installations will be be initiated in that time window. AppLife Manager will still check for, and download packages based on the frequency settings, but will not apply a package outside of your defined time window.

Allow Behavior Settings Locally – Checking this option allows local users to define their own application behaviors.

The example above shows a local setting that overrides the update frequency to check every 5 minutes and sets a daily off-peak time window from 02:00 AM to 06:00 AM.

Note the Disable Application Updating option available in the local settings window. When local settings are enabled, users can disable updating completely on their machine. Also note that local settings are application specific, so local settings can be allowed on one subscription application, but not others.

Allow Local Settings on Specific Clients

In circumstances where overriding application behavior isn’t desirable for every client, this setting can be toggled for specific clients through the AppLife Dashboard Client View.

Installation and Process Settings

Beyond behavior settings, there are settings that affect the installation and operation of an application within AppLife Manager.

  • Application Directory
  • Process Name
  • Primary Executable
  • This Application has an integrated Update API
  • Client Version Mode

Application Directory – Defines the directory on the local client that will be used as the application’s directory. Actions within AppLife Packages can target this directory for file placement. Windows environment path variables can be used in this setting. The default value is %ProgramFiles%\%ApplicationId%.

* – * is a special value in the application directory settings and can be used in coordination with an AppLife Action that will set the application directory during a package execution. The action will search specified directories for a designated executable and use the discovered directory, or use a defined directory if the executable is not found. In the scenario where an application is already deployed, but you would like to start using AppLife Manager to maintain existing installations, you can use an AppLife Action to set the Application Directory to the discovered existing installation directory.

Process Name – The defined process name is the process that AppLife Manager looks for to determine if the application is running. This value is usually in coordination with the Primary Executable, and is defaulted based on the defined Primary Executable, but it does not have to be. It can be set independently.

Primary Executable – The primary executable is used for multiple functions. It is used by the Start button in AppLife Manager. It can be used to determine the current version of the application that is installed, and it’s used to re-launch the application if it was running when the package installation started. One caveat is when Windows Services are being maintained. In this case Manager does not shutdown or restart directly. Instead you will need to use Update Actions in your package, which use the Windows Service Manager to stop and subsequently restart your Windows Service processes.

Integrated API – When an update controller is integrated into the application being maintained by AppLife Manager, the inter-process communications that occur between controllers will initiate the shutdown of the application being maintained. Events are triggered that you can integrate with and use to perform customized tasks within your application code during the update process. Integration is not necessary for AppLife Manager to maintain your applications, but the integration hook is available for advanced or more technically challenging scenarios.

Client Version Mode – An important determination in the software maintenance process is identifying what version is actually installed on the deployed client. The simplest method to use is to let AppLife Manager maintain this value for you. This is the default method. The local version is based entirely on the version stamp of the last update package installed. No explicit action is necessary to use this versioning mode. You have additional options which might be better suited for your applications. You can use the configured primary executable’s assembly version or file version. This is advantageous when you start maintaining an application that was previously deployed. Another option is to use the MSI display version. This is best suited for applications that are using AppLife Manager solely for deploying and initiating Windows Installer packages. In this case, AppLife Manager can use the Windows Installer display version, which is maintained by the MSI process itself, to determine the locally installed version of the application.

Summary

Using AppLife you can easily deploy and maintain one or more applications over your fleet of Windows based client systems. In this post, we reviewed many of the options available to you, out of the box, when you use AppLife Manager on deployed systems. With no source code integration whatsoever, AppLife Manager can completely automate your maintenance processes. In the next post, we’ll explore what can be accomplished by the AppLife Engine during the execution of AppLife packages, whether discovered and initiated by AppLife Manager or through a direct integration with your application source code using the AppLife API.

Deploying Applications with AppLife Cloud

AppLife provides the ability to easily deploy and maintain many applications on your Windows clients and servers. By installing AppLife Manager on your deployed systems a channel is created with which one or more applications can be deployed and maintained using AppLife packages. This is the first of a series of posts that will discuss and demonstrate the use of AppLife tools to deploy software. This series will include:

  1. Deploying an application with AppLife
    Using mostly default settings, we’ll start from a brand new AppLife subscription and deploy a .NET WPF application through AppLife Manager.
  2. Explore Manager Deployment Options
    After looking at a default deployment in the first post, we’ll demonstrate the different configuration options available with AppLife Manager.
  3. Explore the AppLife Engine
    The deployment package in the first post added two files to the installation directory. In this post, we’ll look at other actions and demonstrate the features of the AppLife Update engine.
  4. Using the Dashboard
    The AppLife Dashboard provides the ability to control which of your deployed systems get applications and updates. It can help in troubleshoot defective packages, can identify which clients are running what version of your applications and more. The final post in the series will look at how the dashboard enhances your AppLife deployment model.

Connecting AppLife Manager to your Subscription

The AppLife Manager application gets installed on all of the systems that will run your software and connects your deployed clients to your AppLife subscription. AppLife Manager is downloaded from AppLife Update home page (www.applifeupdate.com). Once installed, you’ll connect Manager to your subscription through a registration process. To register AppLife Manager, you’ll need your Publisher Code. You’ll also need to define a Client Access Key. The Client Access Key will be a value that identifies an individual client, or perhaps a group of clients.

Your publisher code can be found on the Subscription view of your dashboard and can be replaced with a custom value.

Find your publisher code

Defining a Custom Publisher Code

You can set a custom publisher code for your subscription. One that is more meaningful and easier to remember, such as your domain name. A custom publisher code is set from the Subscription view on your dashboard.

With your publisher code entered, the default settings of your initial application will allow it to be discovered. It’ll be displayed within AppLife Manager. Nothing is actually installed on this deployed client yet, as there are no AppLife packages published for the application.

Deploying an Application

We have an application, called First Look that we want to deploy. We are going to effectively XCopy deploy our First Look application to our client machines through AppLife Manager. To accomplish this, we’ll create and publish an AppLife package that, when executed, will place our application on the deployed client. Once published, AppLife Manager will automatically discover and apply the package.

To create the package, we’ll use the AppLife Builder application. Like AppLife Manager, this can be downloaded from the AppLife Update home page. Once downloaded and installed, log into AppLife using your credentials. Select your subscription application. You’ll be prompted for the basic information about your application.

  1. Application Name
    Set this to your application’s name. In this case, First Look. Note that this will change the name displayed in AppLife Manager.
  2. Executable Name
    Set this to the name of the primary executable of your application. FirstLook.exe.
  3. Local Working Directory
    This is a local value that defines the local directory for your application and will be used for relative paths later. For custom software, this is usually a bin directory or an output directory of your build process.

AppLife Actions

An AppLife Package consists of a series of Actions that will take place when the package is executed on a deployed client. There are many actions available. This first package is going to include only one action. An Add & Replace Files action, which will copy two files to the designated Application Directory. When AppLife Manager discovers and applies this package, these two files will be copied.

By default, AppLife Manager applications will check for new versions every 24 hours. After having published this package, any connected clients will install First Look on their next check. AppLife Manager can also be refreshed manually, which will find the application immediately.

Deployments in the Dashboard

When a client applies an AppLife Package, the results are reported to your dashboard and can be reviewed there.

Summary

Using a new AppLife Subscription, we just built an AppLife Package that deploys our existing application through AppLife Manager. With the exception of setting a custom Publisher Code and changing the application name, we used entirely default settings. In the next post, we’ll explore the configuration options available through AppLife Manager that will let you customize the deployment and maintenance model to better fit different scenarios.

Publishing IP Address Filtering

Using the AppLife Cloud solution makes it easy to deploy and maintain applications by creating a channel between you the application publisher, and all your deployed client systems. It’s very important to protect that channel and keep it secure. Steps to keep your deployed clients secure started with:

  • Setting a strong password on your account. We require 8 characters, a letter, a number and special character, but going beyond these minimums is recommended. Using a password tool such as Last Pass makes using long strong passwords very manageable.

  • Enabling Two-Factor authentication on your account. In addition to a strong password, requiring something you have in addition to something you know adds a significant level of protection.

The next step to consider taking is enabling Publishing IP Address Filtering on your AppLife subscription. This is a great idea if your application publishing always originates from static IP addresses. Once enabled, your application update packages must originate from an IP address in your defined list.

To enable IP Address Filtering, navigate to your Subscription Properties view within your dashboard. IP Filtering is subscription scoped, and covers all applications in your subscription with one list.

Once on the Subscription Properties view, you’ll find the IP Filtering list towards the bottom. When you click the enable checkbox, your current IP Address is automatically added to the list. You can add as many IP Addresses as you need. Save the list and you have successfully enabled IP Filtering.