How SEAM Works

The following is a generalized overview of the SEAM authentication system. For a more detailed description, see "How the Authentication System Works".

From the user's standpoint, SEAM is mostly invisible after the SEAM session has been started. Initializing a SEAM session often involves no more than logging in and providing a Kerberos password.

The SEAM system revolves around the concept of a ticket. A ticket is a set of electronic information that serves as identification for a user or a service such as the NFS service. Just as your driver's license identifies you and indicates what driving permissions you have, so a ticket identifies you and your network access privileges. When you perform a SEAM-based transaction -- for example, if you kinit to a new principal -- you transparently send a request for a ticket to a Key Distribution Center, or KDC, which accesses a database to authenticate your identity. The KDC returns a ticket granting you permission to access the other machine. "Transparently" means that you do not need to explicitly request a ticket; it happens as part of the kinit command. Because only the authenticated client can get a ticket for a specific service, another client cannot use kinit under an assumed identity.

Tickets have certain attributes associated with them. For example, a ticket can be forwardable (meaning that it can be used on another machine without a new authentication process), or postdated (not valid until a specified time). How tickets are used -- for example, which users are allowed to obtain which types of ticket -- is set by policies determined when SEAM is installed or administered.

You will frequently see the terms credential and ticket. In the greater Kerberos world, they are often used interchangeably. Technically, however, a credential is a ticket plus the session key for that session. This difference is explained in more detail in "Gaining Access to a Service Using SEAM".

Principals

A client in SEAM is identified by its principal. A principal is a unique identity to which the KDC can assign tickets. A principal can be a user, such as joe, or a service, such as nfs.

By convention, a principal name is divided into three parts: the primary, the instance, and the realm. A typical SEAM principal would be, for example, joe/admin@ENG.ACME.COM, where:

• joe is the primary. This can be a username, as shown here, or a service, such as nfs. It can also be the word host, signifying that this is a service principal set up to provide various network services.

• admin is the instance. An instance is optional in the case of user principals, but it is required for service principals. For example: if the user joe sometimes acts as a system administrator, he can use joe/admin to distinguish himself from his usual user identity. Likewise, if joe has accounts on two different hosts, he can use two principal names with different instances (for example, joe/denver.acme.com and joe/boston.acme.com). Notice that SEAM treats joe and joe/admin as two completely different principals.

  In the case of a service principal, the instance is the fully qualified hostname. bigmachine.eng.acme.com is an example of such an instance, so that the primary/instance might be, for example, nfs/bigmachine.eng.acme.com or host/bigmachine.eng.acme.com.

• ENG.ACME.COM is the SEAM realm. Realms are discussed in the next section.

The following are all valid principal names:

• joe

• joe/admin

• joe/admin@ENG.ACME.COM

• nfs/host.eng.acme.com@ENG.ACME.COM

• host/eng.acme.com@ENG.ACME.COM

Realms

A realm is a logical network, like a domain, which defines a group of systems under the same master KDC. The figure below shows how realms can relate to one another. Some realms are hierarchical, with one being a superset of the other. Otherwise, the realms are non-hiearchical and the mapping between the two realms must be defined. A feature of SEAM is that it permits authentication across realms; each realm only needs to have a principal entry for the other realm in its KDC.

Figure 21-1 Realms

Realms and Servers

Each realm must include a server that maintains the master copy of the principal database. This is called the master KDC server. Additionally, each realm should contain at least one slave KDC server, which contains duplicate copies of the principal database. Both the master and the slave KDC servers create tickets used to establish authentication.

The realm can also include two additional types of SEAM servers. A SEAM network application server is a server that provides access to Kerberized applications (such as ftp, telnet and rsh). Realms can also include NFS servers, which provide NFS services, using Kerberos authentication.

The figure below shows what a hypothetical realm might contain.

Figure 21-2 A Typical Realm