Sun Ray sessions are groups of services or applications that are associated with an authentication token and controlled by the Session Manager. They reside on a Sun Ray server and can be directed to any Sun Ray Client.
Sessions can be in one of two states, Connected or Disconnected:
Connected: Every session with a connected status is displayed on client. The session is automatically disconnected when the user removes the smart card or explicitly switches the client to a different session, for example, with the utswitch or utselect commands.
Disconnected: These sessions are still executed on a server but are not connected to a client and, consequently, are not displayed. However, a user can reconnect to a disconnected session, for example by inserting a smart card containing the appropriate token into the card reader on a client. This changes the session's state to connected and causes it to be displayed on that client.
Sessions can further be grouped into two categories:
Idle sessions: These sessions typically display only a login screen (or login greeter such as dtlogin) where no user has been logged in yet. The lifetime of these sessions is controlled by the Sun Ray system. For example, disconnected idle sessions are automatically terminated (reaped off) by the system after a specific time interval.
User sessions (or non-idle sessions): These are sessions with UNIX users logged in. Users may start up additional applications from within the sessions, thus potentially consuming a lot of system resources. User sessions are therefore of more interest to administrators than idle sessions. To free system resources, monitor the number of long-running disconnected user sessions and, when appropriate, terminate sessions that are no longer in use.
The Authentication Manager implements chosen policies for identifying and authenticating users on Sun Ray Clients using pluggable components called modules to verify user identities, and implements site access policies defined by the administrator. It also supplies an audit trail of the actions of users who have been granted administrative privileges for Sun Ray services. The Authentication Manager is not visible to users.
The interaction between the Authentication Manager and the client is shown in Figure 7.1, “Authentication and Session Manager Interaction” and works as follows:
A user accesses a client.
The client sends the user's token information to the Authentication Manager and requests access. If the user inserts a smart card in the client, the card's type and ID are used as the token. If not, the client's Ethernet address is used as a pseudo-token.
Based on the policy defined by the system administration, the Authentication Manager accepts or denies the access request.
If the user's access request is accepted, the Authentication Manager tells the Session Manager to start an X Windows session, which displays the login screen. Oracle Solaris implementations use the dtlogin screen. Oracle Linux implementations use the Gnome Display Manager (GDM).
If no Sun Ray server is found to provide a session (see Chapter 2, Planning a Sun Ray Network Environment), the client sends a broadcast request for any Authentication Manager on its subnet.
The Session Manager interacts with the Authentication Manager and directs services to the user. A service is any application that can connect directly to the Sun Ray client. Such applications can include audio, video, Xservers, and device control of the client. For example, dtmail is not a service because it is accessed through an Xserver rather than directly.
The Session Manager is used at startup for services, for managing screen space, and as a rendezvous for the Authentication Manager.
The Session Manager keeps track of sessions and services by
mapping services to sessions and binding and unbinding related
services to or from a specific client. The Session Manager
takes authentication only from authorized Authentication
Managers listed in the
/etc/opt/SUNWut/auth.permit file.
The following sequence describes how the process starts, ends, and restarts:
After a user's token is authenticated, the Authentication Manager determines whether a session exists for that token. If a session does not exist, the Authentication Manager asks the Session Manager to create a session and then starts the appropriate services for the session according to the authentication policy decisions taken by the administrator. Creating a session usually requires starting an Xserver process for the session.
When services are started, they join the session explicitly by contacting the Session Manager.
The Authentication Manager informs the Session Manager that the session associated with the token is to be connected to a specific Sun Ray Client. The Session Manager then informs each service in the session that it must connect directly to the client.
The user can then interact with the session. The Session Manager mediates control of the screen space between competing services in a session and notifies the services of changes in screen space allocation.
When the user removes the smart card, or presses Shift-Pause in an NSCM session, or power cycles the client, or is inactive for longer than the screen lock idle timeout interval, the Authentication Manager determines that the session associated with that token must be disconnected from that client. The Authentication Manager notifies the Session Manager, which in turn notifies all the services in the session and any USB devices to disconnect.
When the user re-inserts the smart card, or logs in again to get access to an NSCM session, the Authentication Manager requests the Session Manager to create a new temporary session and then uses it to authenticate the user. This is known as Remote Hotdesk Authentication (RHA). After the user has been authenticated, the Sun Ray Client is connected directly to the user's session.
RHA does not apply to anonymous Kiosk Mode or to token readers. Sun Ray Software can be configured to turn this security policy feature off.
The Session Manager is consulted only if the state of the session changes or if other services are added. When a user's token is no longer mapped to a client, for example, when a card is removed, the Session Manager disconnects the services from the client, but the services remain active on the server. For example, programs attached to the Xserver continue to run although their output is not visible. The Session Manager daemon must continue running. To verify that the Session Manager daemon is running, use the ps command and look for utsessiond.
If the Authentication Manager quits, the Session Manager disconnects all the authorized sessions and requires them to be reauthenticated. These services are disconnected but still active. If the Session Manager is disrupted, it restarts automatically. Each service contacts the Session Manager to request reattachment to a particular session.
