JAAS permission checks

IBM^® JGSS performs runtime permission checks at the time the JAAS-enabled program uses credentials and accesses services. You can disable this optional JAAS feature by setting the Java™ property avax.security.auth.useSubjectCredsOnly to false. Moreover, JGSS performs permission checks only when the application runs with a security manager.

JGSS performs permission checks against the Java policy that is in effect for the current access control context. JGSS performs the following specific permission checks:

javax.security.auth.kerberos.DelegationPermission
javax.security.auth.kerberos.ServicePermission

DelegationPermission check

The DelegationPermission allows the security policy to control the use of the ticket forwarding and proxying features of Kerberos. Using these features, a client can allow a service to act on behalf of the client.

DelegationPermission takes two arguments, in the following order:

The subordinate principal, which is the name of the service principal that acts on behalf of, and under the authority of, the client.
The name of the service that the client wants to allow the subordinate principal to use.

Example: Using the DelegationPermission check

In the following example, superSecureServer is the subordinate principal and krbtgt/REALM.IBM.COM@REALM.IBM.COM is the service that we want to allow superSecureServer to use on behalf of the client. In this case, the service is the ticket-granting ticket for the client, which means that superSecureServer can get a ticket for any service on behalf of the client.

     permission javax.security.auth.kerberos.DelegationPermission
          "\"superSecureServer/host.ibm.com@REALM.IBM.COM\"
          \"krbtgt/REALM.IBM.COM@REALM.IBM.COM\"";

In the previous example, DelegationPermission grants the client permission to get a new ticket-granting ticket from the Key Distribution Center (KDC) that only superSecureServer can use. After the client has sent the new ticket-granting ticket to superSecureServer, superSecureServer has the ability to act on behalf of the client.

The following example enables the client to get a new ticket that allows superSecureServer to access only the ftp service on behalf of the client:

     permission javax.security.auth.kerberos.DelegationPermission
          "\"superSecureServer/host.ibm.com@REALM.IBM.COM\"
          \"ftp/ftp.ibm.com@REALM.IBM.COM\"";

For more information, see the javax.security.auth.kerberos.DelegationPermission class in the J2SDK documentation on the Sun Web site.

ServicePermission check

ServicePermission checks restrict the use of credentials for context initiation and acceptance. A context initiator must have permission to initiate a context. Likewise, a context acceptor must have permission to accept a context.

Example: Using the ServicePermission check

The following example allows the client side to initiate a context with the tp service by granting permission to the client:

     permission javax.security.auth.kerberos.ServicePermission
          "ftp/host.ibm.com@REALM.IBM.COM", "initiate";

The following example allows the server side to access and use the secret key or the ftp service by granting permission to the server:

     permission javax.security.auth.kerberos.ServicePermission
          "ftp/host.ibm.com@REALM.IBM.COM", "accept";

For more information, see the javax.security.auth.kerberos.ServicePermission class in the J2SDK documentation on the Sun Web site.