• Intro
• Downloads
• Community
• Development
• News
• TALK

Enterprise - Tried and tested provisioning strategies

Each of the provisioning strategies in this chapter are either in daily use or at least built and tested as proof-of concept.

In the pictures, thick red dashed lines represent logical connections between actors. If a line has an arrow, it represents direction of the initiation of the communication (which is the direction of the required firewall rule).

Contents 1 Strategy 1: Simple and direct 1.1 The process 1.2 Components 1.3 Firewall rules 1.4 Security considerations 1.5 Pros and cons 2 Strategy 2: SMS based 2.1 The process 2.2 Components 2.3 Firewall rules 2.4 Security considerations 2.5 Pros and cons 3 Strategy 3: Offline installation 3.1 The process 3.2 Components 3.3 Firewall rules 3.4 Security considerations 3.5 Pros and cons 4 Summary

[edit] Strategy 1: Simple and direct

This is the most simple strategy and the most straightforward to implement. In this strategy, direct enrollment is used. Also, since the whole process takes place at the same server, the line between the enrollment and the bootstrapping phases are blurred.

[edit] The process

1. Since repositories at the public Internet are usually not accessible, to avoid Application Manager halting problem, the user needs to disable all repositories on the device. Alternatively, the user may authenticate him/herself to pass through the Access Gateway.
2. The user connects directly, using the device keyboard and display, to a URL on the Enrollment/Installation server.
3. The user provides his/her credentials.
4. The Enrollment/Installation server generates the EUF and bootstraps the installation.

[edit] Components

• Web application (CGI script) running at the Enrollment/Installation server. An example (skeleton) CGI script will be provided soon in gagare.maemo.org that corresponds to the examples given for the device side configuration.

[edit] Firewall rules

Firewall rules: Simple and direct strategy

Source	Target	Protocol	Direction	Notes
Enrollment server	Enterprise User Database	LDAPS (636)	Inbound
Admin server	Installation server	SSH (22)	Outbound
Admin server	Installation server	HTTPS (443)	Outbound	Optional

[edit] Security considerations

• The Enterprise User Database must be accessible. This needs a hole on its inbound firewall. This is a concern in case the Enrollment Server is compromized.
• The user password travels (in encrypted form) in an insecure network outside the corporate firewalls.

[edit] Pros and cons

• + Simple and straightforward to implement.
• - Potentially tedious to the user, at worst case they have to authenticate themselves twice using the device keyboad (first for Access Gateway, then for Enrollment Server).

[edit] Strategy 2: SMS based

Although the device does not currently support OTA configuration messages, there is a way to utilize SMS messages in provisioning. The idea is to deliver the configuration data from Enrollment Server to Installation Server behind the scenes, and simultaneously deliver to the device via SMS a one-time time-limited URL which enables access to the configuration data.

This strategy is more complicated to implement but easier to use. It uses indirect enrollment.

[edit] The process

1. Since repositories at the public Internet are usually not accessible, to avoid Application Manager halting problem, the user needs to disable all repositories from the device. Alternatively, the user may authenticate him/herself to pass through the Access Gateway.
2. User connects to the Enrollment Server using a desktop computer and provides his/her credentials.
3. Using the credentials, the Enrollment Server queries user information from Enterprise User Database, including the phone number of the users device.
4. Enrollment Server generates a random pin code.
5. Enrollment Server generates the EUF and transfers it, along with the pin code, to Installation Server.
6. Enrollment Server generates a URL which points to a CGI script at the Installation Server and contains the pin code. For example, https://server.example.com/indirect.cgi?pincode=aa913a5b-6558-44a5-a501-bbf5c81078d3.
7. Enrollment Server generates an SMS message which contains the URL and sends it to the device using SMS gateway.
8. When the user opens the SMS message at the device, Conversations application displays the URL as a clickable link. When the user clicks the link, the Web Browser application is invoked and the URL is opened.
9. When the CGI script at the Installation Server is called, it checks whether there is an EUF matching the pincode. If there is, the script checks the age of the EUF. If the file is older than a predefined time limit (e.g., 5 minutes) an error message is generated and processing stops.
10. If the file age is OK, the script bootstraps the installation according selected bootstrapping strategy. "Via package" bootstrap strategy is probably more feasible, especially if ease of use is among the reasons.
11. At the device, the Web Browser invokes the Application Manager, which installs the on-the-fly generated package and all packages in the dependency chain
12. Post-install script runs and re-enables repositories disabled at step 1

To clean up, Installation server runs a cron job at every few minutes, removing all generated temporary files which are older than predefined time limit

[edit] Components

• Web application (CGI script) running at Enrollment Server
• Web application (CGI script) running at Installation Server
• SMS gateway

[edit] Firewall rules

Firewall rules: SMS-based strategy

Source	Target	Protocol	Direction	Notes
Admin server	Installation server	SSH (22)	Outbound
Enrollment server	Installation server	SSH (22)	Outbound
Admin server	Installation server	HTTPS (443)	Outbound	Optional

[edit] Security considerations

• PIN code can and should be fairly long, longer than a typical username and password together.
• No need for inbound firewall holes.
• User password does not travel outside corporate intranet.

[edit] Pros and cons

• + The obvious advantage of indirect enrollment combined with SMS-URL based bootstrapping is the minimization of user interaction performed from the device keyboard and display. Writing the provisioning URL, username and password from the device keyboard are all avoided. Most of the user interaction can be performed using full size keyboard and display, only couple of touchscreen clicks is left to be to done at the device.
• - A bit more laborious to implement
• - Requires more servers (not necessarily if Admin server can host as Enrollment server as well)

[edit] Strategy 3: Offline installation

This strategy is probably used as a complement to previous strategies. The server topology may be similar to either of the descried ones.

The most important use case for this strategy is to enable provisioning for users located at remote sites and unable to access corporate WLAN.

[edit] The process

1. To avoid Application Manager halting problem, user needs to disable all repositories from the device. Or alternatively, connect to a 3G network.
2. User connects to the Enrollment Server via a VPN connection to the corporate intranet using a desktop computer and provides his/her credentials.
3. Using the credentials, the Enrollment Server queries the user information from the Enterprise User Database.
4. Enrollment Server generates a random pin code.
5. Enrollment Server generates EUF, transfers it and the pin code to Installation server.
6. Enrollment Server generates an URL which points to a CGI script at the Installation Server and contains the pin code. For example, https://server.example.com/offline.cgi?pincode=a913a5bXTgd.
7. Enrollment Server redirects the web browser to that URL, or presents a clickable link.
8. When the CGI script at the Installation Server is called, it checks if there is an EUF matching the pincode. If yes, the script checks the age of the EUF. If the file is older than a predefined time limit (e.g., 5 minutes), an error message is generated and processing stops.
9. If the file age is OK, the script (See Appendix for further instructions for implementing this phase)

• • Generates User Info package ("Via package" bootstrapping strategy is recommended).
  • Produces a list of required packages from the dependencies of the EP.
  • Creates a temporary repository which contains all the required packages and the User Info package.
  • Creates an install file which contains
    • The User Info package and
    • The URL to the local repository on the device.
  • Generates a zip file from the repository and the install file

1. The script outputs the zip file with appropriate content type definitions. See Appendix.
2. User connects the device to the desktop computer via USB cable.
3. User copies the zip file to her device.
4. At the device, the user extracts the repository and the install file from the zip file.
5. User taps the install file to invoke the Application Manager, which installs the User Info package and all the packages in the dependency chain.

[edit] Components

• Web application (CGI script) running at Enrollment server
• Web application (CGI script) running at Installation server

[edit] Firewall rules

Same as in previous two strategies, depending on which server topology is used

[edit] Security considerations

• None

[edit] Pros and cons

• + Enables provisioning at remote locations
• + Fairly simple to use
• - Can be fairly laborious to implement
• - Presumably slow and storage space consuming

[edit] Summary

Here we looked at the tried out solutions for provisioning but some readers might be interested to read our alternative solution considerations or about future prospects for provisioning. If on the other hand these solutions suited already your needs you can move onward to provisioning summary.