This class is used to restrict the usage of the Kerberos
delegation model, ie: forwardable and proxiable tickets.

The target name of this Permission specifies a pair of
kerberos service principals. The first is the subordinate service principal
being entrusted to use the TGT. The second service principal designates
the target service the subordinate service principal is to
interact with on behalf of the initiating KerberosPrincipal. This
latter service principal is specified to restrict the use of a
proxiable ticket.

For example, to specify the "host" service use of a forwardable TGT the
target permission is specified as follows:



 DelegationPermission("\"host/foo.example.com@EXAMPLE.COM\" \"krbtgt/EXAMPLE.COM@EXAMPLE.COM\"");

To give the "backup" service a proxiable nfs service ticket the target permission
might be specified:



 DelegationPermission("\"backup/bar.example.com@EXAMPLE.COM\" \"nfs/home.EXAMPLE.COM@EXAMPLE.COM\"");

This class encapsulates a long term secret key for a Kerberos
principal.

All Kerberos JAAS login modules that obtain a principal's password and
generate the secret key from it should use this class.
Sometimes, such as when authenticating a server in
the absence of user-to-user authentication, the login module will store
an instance of this class in the private credential set of a
Subject during the commit phase of the
authentication process.

A Kerberos service using a keytab to read secret keys should use
the KeyTab class, where latest keys can be read when needed.

It might be necessary for the application to be granted a
PrivateCredentialPermission if it needs to access the KerberosKey
instance from a Subject. This permission is not needed when the
application depends on the default JGSS Kerberos mechanism to access the
KerberosKey. In that case, however, the application will need an
appropriate
ServicePermission.

This class encapsulates a Kerberos principal.

This class encapsulates a Kerberos ticket and associated
information as viewed from the client's point of view. It captures all
information that the Key Distribution Center (KDC) sends to the client
in the reply message KDC-REP defined in the Kerberos Protocol
Specification (RFC 4120).

All Kerberos JAAS login modules that authenticate a user to a KDC should
use this class. Where available, the login module might even read this
information from a ticket cache in the operating system instead of
directly communicating with the KDC. During the commit phase of the JAAS
authentication process, the JAAS login module should instantiate this
class and store the instance in the private credential set of a
Subject.

It might be necessary for the application to be granted a
PrivateCredentialPermission if it needs to access a KerberosTicket
instance from a Subject. This permission is not needed when the
application depends on the default JGSS Kerberos mechanism to access the
KerberosTicket. In that case, however, the application will need an
appropriate
ServicePermission.

Note that this class is applicable to both ticket granting tickets and
other regular service tickets. A ticket granting ticket is just a
special case of a more generalized service ticket.

This class encapsulates a keytab file.

A Kerberos JAAS login module that obtains long term secret keys from a
keytab file should use this class. The login module will store
an instance of this class in the private credential set of a
Subject during the commit phase of the
authentication process.

If a KeyTab object is obtained from getUnboundInstance()
or getUnboundInstance(java.io.File), it is unbound and thus can be
used by any service principal. Otherwise, if it's obtained from
getInstance(KerberosPrincipal) or
getInstance(KerberosPrincipal, java.io.File), it is bound to the
specific service principal and can only be used by it.

Please note the constructors getInstance() and
getInstance(java.io.File) were created when there was no support
for unbound keytabs. These methods should not be used anymore. An object
created with either of these methods are considered to be bound to an
unknown principal, which means, its isBound() returns true and
getPrincipal() returns null.

It might be necessary for the application to be granted a
PrivateCredentialPermission if it needs to access the KeyTab
instance from a Subject. This permission is not needed when the
application depends on the default JGSS Kerberos mechanism to access the
KeyTab. In that case, however, the application will need an appropriate
ServicePermission.

The keytab file format is described at

http://www.ioplex.com/utilities/keytab.txt.

ServicePermission("krbtgt/EXAMPLE.COM@EXAMPLE.COM", "initiate");

ServicePermission("host/foo.example.com@EXAMPLE.COM", "initiate");

ServicePermission("host/foo.example.com@EXAMPLE.COM", "accept");

This class is used to protect Kerberos services and the
credentials necessary to access those services. There is a one to
one mapping of a service principal and the credentials necessary
to access the service. Therefore granting access to a service
principal implicitly grants access to the credential necessary to
establish a security context with the service principal. This
applies regardless of whether the credentials are in a cache
or acquired via an exchange with the KDC. The credential can
be either a ticket granting ticket, a service ticket or a secret
key from a key table.

A ServicePermission contains a service principal name and
a list of actions which specify the context the credential can be
used within.

The service principal name is the canonical name of the
KerberosPrincipal supplying the service, that is
the KerberosPrincipal represents a Kerberos service
principal. This name is treated in a case sensitive manner.
An asterisk may appear by itself, to signify any service principal.

Granting this permission implies that the caller can use a cached
credential (TGT, service ticket or secret key) within the context
designated by the action. In the case of the TGT, granting this
permission also implies that the TGT can be obtained by an
Authentication Service exchange.

The possible actions are:



   initiate -              allow the caller to use the credential to
                           initiate a security context with a service
                           principal.

   accept -                allow the caller to use the credential to
                           accept security context as a particular
                           principal.

For example, to specify the permission to access to the TGT to
initiate a security context the permission is constructed as follows:



    ServicePermission("krbtgt/EXAMPLE.COM@EXAMPLE.COM", "initiate");

To obtain a service ticket to initiate a context with the "host"
service the permission is constructed as follows:


    ServicePermission("host/foo.example.com@EXAMPLE.COM", "initiate");

For a Kerberized server the action is "accept". For example, the permission
necessary to access and use the secret key of the  Kerberized "host"
service (telnet and the likes)  would be constructed as follows:



    ServicePermission("host/foo.example.com@EXAMPLE.COM", "accept");