|C H A P T E R 10|
This chapter describes Kiosk Mode, which enables controlled, simplified access to anonymous users without compromising the security of the Sun Ray server. For a detailed explanation of Kiosk Mode functionality, see kiosk(5).
In earlier releases of Sun Ray Server Software, Kiosk Mode was known as Controlled Access Mode (CAM).
|Caution - Sun Ray Server Software and NIS (Network Information System) store user names and groups in the same system file (/etc/passwd). Be sure to use unique user names when setting up a Kiosk Mode application if the same physical server is used to host both the Sun Ray Server Software and the NIS software. If both systems use the same user names, then the utconfig -u command can overwrite the NIS entries.|
Kiosk Mode allows the administrator to specify what types of sessions are available to users, based on policy choices for different types of user and usage scenario. For instance, settings can differ for smart card users as opposed to non-smart card users, for those with registered as opposed to unregistered tokens, and for other characteristics.
Kiosk Mode functionality can be enabled and disabled from the System Policy section of the Advanced tab, and administered from the Kiosk Mode section, which provides check boxes to enable Kiosk Mode for smart card users, non-smart card users, or both.
|Note - Before enabling Kiosk Mode you must configure it with the utconfig utility.|
As superuser, type the utpolicy command for your authentication policy with the addition of the -k argument. Some examples are suggested below.
|Note - The following options determine access to the Sun Ray server:
-r both/pseudo/card [-s both/pseudo/card]
The -k both/pseudo/card option determines whether some or all of the granted sessions are Kiosk sessions.
All users are directed to Kiosk sessions.
Only card users are directed to Kiosk sessions.
Only non-card users are directed to Kiosk sessions.
Card sessions are non-Kiosk (ordinary login) sessions. Non-card sessions are Kiosk sessions.
All sessions are in Kiosk Mode and available only to card users unless you specify overrides.
Non-card sessions are Kiosk sessions. Non-Kiosk card sessions are allowed only for registered tokens.
Card sessions are Kiosk sessions, non-card sessions are non-Kiosk (ordinary login) sessions. Users can self-register card tokens and DTUs.
The Admin GUI presents a set of choices that may be more convenient to use than the CLI.
1. Start the Administration Tool.
2. Select the Advanced tab.
3. Select the System Policy tab (see FIGURE 10-1).
4. Select the Kiosk Mode checkbox in the Card Users section, the Non-Card Users section, or both, depending on whether you wish to enable Kiosk Mode for card users, non-card users, or both.
5. Click the Save button.
6. Select the Servers tab
7. Select the relevant server(s) from the list of servers.
8. Click the Cold Restart button.
FIGURE 10-1 Kiosk Mode Enabled for Non-Card Users
It may be desirable to use a different authentication policy setting for a particular user or DTU, or subset of users or DTUs, than for other users or DTUs. You can override Kiosk Mode policy with the utkioskoverride CLI or with the GUI.
For more detailed information on overriding Kiosk Mode policy, see the utkioskoverride(1m) man page.
Use the utkioskoverride command to override Kiosk Mode policy for a user’s smart card token or for a DTU’s pseudo-token.
|Note - If your policy specifies access for All Users, as in FIGURE 10-1, there is no need to override Kiosk Mode policy.|
For example, to enable Kiosk sessions regardless of Kiosk Mode policy for the registered smart card MicroPayFlex.12345678:
To disable Kiosk sessions regardless of Kiosk Mode policy for the logical token user.12345678:
|Note - Only registered tokens--those that have already been registered--can be assigned policy overrides.|
1. Select the Tokens tab.
2. Select the token of interest from the list of tokens.
This token can be a card owner’s smart card token or a pseudo-token associated with a DTU’s MAC address. However, only tokens that have been registered in the Sun Ray data store can be overridden. To register a smart card token, see To Register a Token. To register a pseudo-token, see To Register a Pseudo-Token.
3. Click the Edit button.
FIGURE 10-2 Edit Token Properties
4. Select the desired Session Type from the list of available session types.
The available session types are Default, Kiosk, and Regular.
a. Select Default to prevent Kiosk Mode policy from being overridden for this token.
b. Select Kiosk to use a Kiosk session for this token regardless of Kiosk Mode policy.
c. Select Regular to ensure that a Kiosk session is not used for this token, regardless of Kiosk Mode policy.
5. Click the OK button.
Once you have selected a Kiosk session, that session is launched by default to provide basic Kiosk Mode functionality. Some Kiosk sessions will support the addition of applications to extend this basic functionality.
1. Select the Advanced tab.
2. Select the Kiosk Mode tab.
3. Click the Edit button.
4. Select your preferred Kiosk Session from the Session drop-down list, as shown in FIGURE 10-2.
5. Provide appropriate values for the remaining settings. See TABLE 10-1 for descriptions of individual settings.
6. Click the OK button.
Changes to Kiosk Mode Settings are applied automatically to Kiosk sessions that start after the changes have been saved. Thus, there is no need to restart Sun Ray services for changes to take effect.
Indicates a list of arguments that should be passed to Kiosk sessions as they start. This is a Kiosk session-specific setting. For more information on supported arguments, consult the session-specific documentation for your selected session.
|Caution - Choosing unsuitable values for ulimit(1)settings may cause Kiosk sessions to start incorrectly or to crash due to lack of resources.|
1. Select the Advanced tab.
2. Select the Kiosk Mode tab.
If the currently selected Kiosk session supports the addition of applications, there is an Applications setting at the bottom of the page.
3. Click the New button.
a. To use one of the predefined Kiosk application descriptors:
i. Select Predefined Descriptor.
ii. Choose the relevant descriptor from the drop-down menu.
b. To define a custom Kiosk application descriptor:
i. Select Custom Path to use your own custom Kiosk application descriptor or a system application.
ii. Enter the path to your custom Kiosk application descriptor or executable.
If you choose Custom Path, indicate whether the path refers to a custom Kiosk application descriptor or an executable by choosing either Descriptor or Executable.
4. Select your preferred Start Mode for the application.
a. Choose USER to allow users to start the application themselves, for instance from a menu or launcher item.
b. Choose AUTO to make the application start automatically when the Kiosk session starts.
c. Choose CRITICAL to make the application start automatically when the Kiosk session starts, to allow users to start the application themselves, and to force the Kiosk session to restart if the application terminates.
5. Enter any application specific arguments.
|Note - Individual Kiosk sessions may handle the various application start modes and arguments differently. For precise details on these, consult the session-specific documentation of your selected Kiosk session.|
Since Kiosk Mode bypasses the system login mechanism, you must consider the security of the applications added to the user environment. Many custom applications provide built-in security; however, other applications do not and are therefore not suitable for Kiosk Mode.
For example, adding an application such as xterm provides users with access to a command-line interface from a Kiosk Mode session. This is not desirable in a public environment and is not advised. However, using a custom application for a call center would be perfectly acceptable.
In a failover environment, the Kiosk Mode administrative settings are copied to the failover (i.e., secondary) servers. Be sure that all application descriptors and executable paths added to the Kiosk Mode sessions are copied across the servers in the failover group. For example, if the Mozilla application is added to the sessions with the executable path /usr/sfw/bin/mozilla, make sure that the path to the binary is available to all servers in the failover group. One way to ensure that sessions and applications are available on all servers in a failover group is to put them into a shared network directory, which is available on all hosts in the failover group.