107 lines
6.2 KiB
HTML
107 lines
6.2 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
<!DOCTYPE html
|
|||
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|||
|
<html lang="en-us" xml:lang="en-us">
|
|||
|
<head>
|
|||
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|||
|
<meta name="security" content="public" />
|
|||
|
<meta name="Robots" content="index,follow" />
|
|||
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
|||
|
<meta name="DC.Type" content="reference" />
|
|||
|
<meta name="DC.Title" content="System methods for sending information about a user" />
|
|||
|
<meta name="abstract" content="APPC architecture provides three methods for sending security information about a user from the source system to the target system." />
|
|||
|
<meta name="description" content="APPC architecture provides three methods for sending security information about a user from the source system to the target system." />
|
|||
|
<meta name="DC.Relation" scheme="URI" content="rzamvappctarget.htm" />
|
|||
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
|
|||
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
|
|||
|
<meta name="DC.Format" content="XHTML" />
|
|||
|
<meta name="DC.Identifier" content="appcsendinfo" />
|
|||
|
<meta name="DC.Language" content="en-us" />
|
|||
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
|||
|
<!-- US Government Users Restricted Rights -->
|
|||
|
<!-- Use, duplication or disclosure restricted by -->
|
|||
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
|||
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
|||
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
|||
|
<title>System methods for sending information about a user</title>
|
|||
|
</head>
|
|||
|
<body id="appcsendinfo"><a name="appcsendinfo"><!-- --></a>
|
|||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|||
|
<h1 class="topictitle1">System methods for sending information about a user</h1>
|
|||
|
<div><p>APPC architecture provides three methods for sending security information
|
|||
|
about a user from the source system to the target system.</p>
|
|||
|
<div class="section"><p>These methods are referred to as the architected security values.
|
|||
|
The <a href="../books/sc415443.pdf" target="_blank">APPC
|
|||
|
Programming</a> book provides more information about the architected security
|
|||
|
values.</p>
|
|||
|
<p>The following table shows the security values in the APPC architecture: </p>
|
|||
|
|
|||
|
<div class="tablenoborder"><a name="appcsendinfo__sysmeth"><!-- --></a><table cellpadding="4" cellspacing="0" summary="" id="appcsendinfo__sysmeth" width="100%" frame="border" border="1" rules="all"><caption>Table 1. Security values in the APPC
|
|||
|
architecture</caption><thead align="left"><tr valign="bottom"><th valign="bottom" id="d0e29">Architected security value</th>
|
|||
|
<th valign="bottom" id="d0e31">User ID set to target system</th>
|
|||
|
<th valign="bottom" id="d0e33">Password sent to target system</th>
|
|||
|
</tr>
|
|||
|
</thead>
|
|||
|
<tbody><tr><td valign="top" headers="d0e29 ">None</td>
|
|||
|
<td valign="top" headers="d0e31 ">No</td>
|
|||
|
<td valign="top" headers="d0e33 ">No</td>
|
|||
|
</tr>
|
|||
|
<tr><td valign="top" headers="d0e29 ">Same</td>
|
|||
|
<td valign="top" headers="d0e31 ">Yes<sup>1</sup></td>
|
|||
|
<td valign="top" headers="d0e33 ">See note 2.</td>
|
|||
|
</tr>
|
|||
|
<tr><td valign="top" headers="d0e29 ">Program</td>
|
|||
|
<td valign="top" headers="d0e31 ">Yes</td>
|
|||
|
<td valign="top" headers="d0e33 ">Yes<sup>3</sup></td>
|
|||
|
</tr>
|
|||
|
<tr><td colspan="3" valign="top" headers="d0e29 d0e31 d0e33 "><div class="note"><span class="notetitle">Note:</span> <ol><li>The source system sends the user ID if the target system specifies SECURELOC(*YES)
|
|||
|
or SECURELOC(*VFYENCPWD).</li>
|
|||
|
<li id="appcsendinfo__note2"><a name="appcsendinfo__note2"><!-- --></a>The user does not enter a password on the request because the
|
|||
|
password is already verified by the source system. For SECURELOC(*YES) and
|
|||
|
SECURELOC(*NO), the source system does not send the password. For SECURELOC(*VFYENCPWD),
|
|||
|
the source system retrieves the stored, encrypted password and sends it, in
|
|||
|
encrypted form.</li>
|
|||
|
<li>The system sends the password in encrypted form if both the source and
|
|||
|
target systems support password encryption. Otherwise, the password is not
|
|||
|
encrypted.</li>
|
|||
|
</ol>
|
|||
|
</div>
|
|||
|
</td>
|
|||
|
</tr>
|
|||
|
</tbody>
|
|||
|
</table>
|
|||
|
</div>
|
|||
|
<p>The application that you request determines the architected security
|
|||
|
value. For example, SNADS always uses SECURITY(NONE). DDM uses SECURITY(SAME).
|
|||
|
With display station passthrough, you specify the security value by using
|
|||
|
parameters on the STRPASTHR command. </p>
|
|||
|
<p>In all cases, the target system
|
|||
|
chooses whether to accept a request with the security value that is specified
|
|||
|
on the source system. In some situations, the target system might reject the
|
|||
|
request completely. In other situations, the target system might force a different
|
|||
|
security value. For example, when you specify both a user ID and a password
|
|||
|
on the STRPASTHR command, the request uses SECURITY(PGM). However, if the
|
|||
|
QRMTSIGN system value is *FRCSIGNON on the target system, you still see a
|
|||
|
Sign On display. With the *FRCSIGNON setting, the systems always use SECURITY(NONE),
|
|||
|
which is the equivalent of the user entering no user ID and password on the
|
|||
|
STRPASTHR command.</p>
|
|||
|
<p>The source and target systems negotiate the security
|
|||
|
value before data is sent. In the situation where the target system specifies
|
|||
|
SECURELOC(*NO) and the request is SECURITY(SAME), for example, the target
|
|||
|
system tells the source system to use SECURITY(NONE). The source system does
|
|||
|
not send the user ID.</p>
|
|||
|
<div class="p">The target system rejects a session request when
|
|||
|
the user’s password on the target system has expired. This applies only to
|
|||
|
connection requests that send a password, including the following: <ul><li>Session requests of type SECURITY(PROGRAM).</li>
|
|||
|
<li>Session requests of type SECURITY(SAME) when the SECURELOC value is *VFYENCPWD.</li>
|
|||
|
</ul>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
<div>
|
|||
|
<div class="familylinks">
|
|||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzamvappctarget.htm" title="The topics that follow describe the elements that determine how an APPC user gains entrance to the target system.">APPC user access to the target system</a></div>
|
|||
|
</div>
|
|||
|
</div>
|
|||
|
</body>
|
|||
|
</html>
|