When signing on to a back-end system, FEPI applications can ask the external
security manager (ESM) to supply a password substitute, or PassTicket. (For an explanation of why PassTickets are necessary, see topic Signon security.)
This section is an overview of how PassTickets work, and describes what
you need to do to use them. For detailed information about PassTickets, see
the OS/390 Security Server (RACF) Security Administrator’s Guide.
- To process PassTickets, the ESM uses keys, known as Secure Signon keys,
that are shared by the front- and back-end systems. You must define a Secure
Signon key for each target system with which FEPI communicates. For information
about how to do this, RACF® users should refer to the OS/390 Security Server (RACF) System Programmer’s Guide. Users
of other ESMs should refer to the documentation for their product.
- The end-user is verified by signing on to the front-end CICS® in the usual
way.
- When he or she runs a transaction that uses FEPI, your application issues
a FEPI REQUEST PASSTICKET command to obtain a PassTicket 1 . A PassTicket is a secure representation
of a password that can be used to sign on to the back-end system. It is valid
for one use only, and is time-stamped. The userid for which the PassTicket
is generated is that of the currently signed-on user. Your FEPI application
can use an EXEC CICS ASSIGN command to check the userid of the currently signed-on
user.
- Your FEPI application uses the PassTicket and userid to perform a sign-on
in the back-end system, just as if it were sending a password and userid.
For example:
EXEC CICS FEPI SEND FORMATTED
CONVID(convid) FROM(CESN userid PassTicket)
FROMLENGTH(length_of_data)
It is the application’s
responsibility to provide the signon processing, because CICS cannot know
either the type of back-end (CICS or IMS™) or the back-end program being used
for signon processing.
- The back-end system uses an unchanged interface to perform the sign-on.
Thus, a CICS system receiving a userid and a PassTicket can use its existing
procedures to sign on the userid. RACF takes care of the fact that a PassTicket,
rather than a password, is passed to it.
Note:
If the PassTicket times out (because, for example, of a session
failure), your application should generate another and try to sign on again.
If signon continues to fail and the front- and back-ends are in different
MVS™ systems, check that the TOD clocks are suitably synchronized. Too many
failed signon attempts could result in the userid being revoked.
For information about using RACF with CICS, see the CICS RACF Security Guide.
The advantages of using PassTickets are that:
- They provide a secure way of signing on to back-end systems. This is because:
- They are valid for one use only and are timestamped--therefore, the
potential damage caused by their being intercepted is minimal.
- Passwords are not transmitted across the network.
- FEPI applications do not have to store passwords (or ask users to reenter
them) in order to sign on to back-end systems.
- No changes are required in the CICS or IMS back-end systems.
- System clocks in the front- and back-end systems do not need to be precisely
synchronized (RACF compensates for variations up to plus or minus 5 minutes).
- The front-end must be a CICS/ESA 4.1 or later system. The back-end can
be an earlier-level CICS or IMS system.
- RACF Version 2 Release 1 or later, or a functionally-equivalent external
security manager, on both the front- and back-end systems.
- End-users must use the same userid in the back-end systems as in the front-end
system.
If EDF is being
used the PassTicket is not displayed.
[[ Contents Previous Page | Next Page Index ]]