Token-Based Access Control

  Token-based access control        authorizes access to the X
  server based on the presentation of a valid password (or
  token  ) by a client application during a connection request.
  The level to which the client is authenticated and the method
  of authentication varies depending on the procotol in use,
  which is specified in a user's X authority file  .

  In general, each time a client application attempts to connect
  to an X server protected with token-based access control, the
  server references the current X authority file to determine
  the appropriate protocol to apply and authentication method
  to follow in order to grant the connection.

  The token-based access control protocols supported by
  DECwindows are MIT-MAGIC-COOKIE-1 (Magic Cookie)
  and MIT-KERBEROS-5 (Kerberos).

  Magic Cookie
  Magic Cookie authorizes connections to an X server based on
  entries in the X authority file.  Each entry for Magic Cookie
  access control specifies:

  *   the name of the X display ([transport/][host][:]:server[.screen])

  *   the protocol name (MIT-MAGIC-COOKIE-1)

  *   a random, 128-bit numeric code known as a        magic
      cookie

  Once Magic Cookie access control is enabled on the server,
  a new X authority file entry is generated automatically
  each time you successfully log into your local desktop.
  The magic cookie authorizing the local connection, along
  with the device, transport, and protocol name is passed
  to the X server and stored in your X authority file
  (SYS$LOGIN:DECW$XAUTHORITY.DECW$XAUTH).
  By default, cookies generated by the Session Manager do not
  have a set timeout period and are granted trusted network
  privileges.  If a cookie is believed to have been compromised,
  you can choose to generate a new cookie.

  Each time a client application attempts to connect to the
  X server during your session, the application must present a
  valid cookie to the X server along with the connection request.

  If the cookie matches the one currently maintained by the X
  server, the connection is authorized, access is granted to
  the X server, and the display is opened.  If the client does
  not present a valid cookie, a message is displayed, and the
  connection is denied.

  Due to the use of a randomly-generated token, Magic Cookie
  provides a more secure form of access control than the user-
  based scheme.  However, since the the cookies themselves
  are sent across the network unencrypted, they can be prone
  to interception.  As a result, this form of access control is
  recommended for authorizing connections in a local area
  network (LAN) or limited DECnet environment.

  Kerberos

  Kerberos authorizes connections to an X server based on a
  combination of the following:

  *   the protocol name (MIT-KERBEROS-5) in the X
      authority file

  *   a list of valid Kerberos principals and their associated
      passwords

  *   presentation of valid credentials

  Kerberos credentials, or  tickets , are a set of electronic
  information that can be used to verify the identity of a
  principal  .  These principals are stored in an Authorized

  Principals list kept on the server system.  With Kerberos,
  client applications run by a valid principal send requests for a
  ticket from the Kerberos   Key Distribution Center (KDC)
  each time they attempt to connect to the Kerberos-protected

  X server.

  Once Kerberos access control is enabled on the server, a new
  ticket is requested from the KDC automatically each time
  you log into your local desktop.  The KDC creates a ticket-
  granting ticket (TGT) associated with your principal name,
  encrypts it using your password as the key, and returns the
  encrypted TGT.

  If the TGT is decrypted successfully, you are authenticated
  and the TGT is cached.  The TGT permits you, as the
  authenticated principal, to obtain additional tickets.  These
  additional tickets grant access to specific services, in this case,
  access to the X server from other client applications.  The
  requesting and granting of these additional tickets happens
  transparently.

  By default, each TGT expires at a specified time.  If a TGT
  has expired, you can generate a new TGT by disabling and
  reeanbling Kerberos (which forces a Kerberos login).  If
  you believe a ticket has been compromised, you can choose
  to disable Kerberos and revoke the current ticket, which
  effectively flushes the client credentials cache.

  Kerberos is the most secure form of access control since
  it encrypts the initial authentication information between
  the requesting client and the server system.  Therefore, it
  is the recommended method for authorizing remote client
  connections over unsecure networks, such as the Internet.

  For information on how to configure the access control
  settings for the local X display server or DECwindows Motif
  client applications, double click on an item from the list of
  additional topics below.

  Additional topics:

  *   User-Based Access Control

  *   Configuring X Server Access Control

  *   Configuring Client Access Control