The R_ticketserv callable service allows callers to read GSS-API context tokens and also provides RACF® PassTicket services. R_ticketserv is similar to the Extract client principal (function code 1) of the R_GenSec callable service (See Extract client principal functions (Function code 1): for more information). The main difference is that R_ticketserv cannot be invoked from AMODE 64.

R_ticketserv can enable z/OS application servers to parse or extract principal names from a GSS-API context token, which when the request includes a GSS-API context token and the intended recipient is the z/OS application server, enables a z/OS application server to determine the client principal who originated an application-specific request. See z/OS Integrated Security Services Network Authentication Service Administration and z/OS Integrated Security Services Network Authentication Service Programming for more information about the GSS-API services supported on z/OS.

R_ticketserv also allows callers to generate and evaluate PassTickets.

R_ticketserv can be used by an application, which does not have access to a C runtime environment providing the GSS-API functions required for authentication, through decrypting the service ticket in the provided token. Decrypting the service ticket allows R_ticketserv to determine if a principle has access to a service. See z/OS Integrated Security Services Network Authentication Service Programming for more information.

The R_ticketserv service, like other SAF calls that use Kerberos for authentication, requires the SKRBKDC started task to be running in the same address space.

R_ticketserv checks that the server principal in the ticket maps to the current user ID, before the ticket is accepted. If tickets for different service principals are to be accepted, a KERBLINK mapping must exist for the service principal, and the current user ID must be granted at least READ authority to the KERBLINK profile. For example, if the server principal in the ticket is princ2/fully_qualified_hostname and is associated with user2, and the current user is user1 who is defined to RACF, you can use the PERMIT command to grant user1 READ authority to the KERBLINK profile of the server principal. With READ authority, user1 can decrypt the tickets of user2. However, before using the PERMIT command to grant this READ authority, you must activate RACF protection for the KERBLINK profile (if not already active). If the server principal does not have a KERBLINK profile, you must create one. The following procedure shows how to activate RACF protection, create a KERBLINK profile, and grant READ authority:

1. Activating RACF protection for the KERBLINK class using the SETROPTS command:

   SETROPTS CLASSACT(KERBLINK)

   See z/OS Security Server RACF Command Language Reference for more information about the SETROPTS command.
2. Creating a KERBLINK profile for the server principal (princ2/fully_qualified_hostname) in the ticket using the RDEFINE command:

   RDEFINE KERBLINK princ2/fully_qualified_hostname 

   See z/OS Security Server RACF Security Administrator's Guide for more information about KERBLINK profiles and automatic local principal name mapping.
3. Using the PERMIT command to grant user1 READ authority to the KERBLINK profile of the server principal (princ2/fully_qualified_hostname):

   PERMIT princ2/fully_qualified_hostname CLASS(KERBLINK) ID(user1) ACCESS(READ)                      

   See z/OS Security Server RACF Security Administrator's Guide for more information about the PERMIT command.