You need to go to the online information center and do a search on
"authentication". Select the first result, a perfect match, read it,
then follow the link to "Authentication methods for your server". That
page has a chart that shows the differences.
Authentication is determining that you are who you claim you are. Server
authentication, as you state, does the checking on the server. This
requires transmitting the userid and password (unencrypted in your case)
to the server. When the server's operating system tells UDB that the
password is valid for the user, the authentication is complete. When
client authentication is being used, the client performs the check.
You are correct that UDB will not understand that your client id FJS
will be unknown to UDB and that UDB will not know to correlate FJS with
MGR_DEV1. This may or may not be a problem. The decision to allow a user
to do anything in UDB is called "authorization" and is a different
function from the authentication perfromed by an operating system. The
UDB "GRANT" statement us used to control authorizations.
I don't know what happens with client group authentication on a VSE
system. On Linux, the user's groups on the authenticating system would
be the ones made available for authorization purposes. (Note that this
could be a security problem if you have root access to a client system
and can make yourself a member of a group that matches the sysadm group
on the server.) Windows systems have the same issues as Linux but there
are additional server profile variables that can control how groups are
determined in a Windows networking environment where domain controllers
exist.
If MGR_DEV1 is a dbadm or sysadm through a group authorization, I"d keep
the authentication as server. Changing your AUTHENTICATION to
SERVER-ENCRYPT at the server and the client will provide additional
security if your communication lines are compromised. Passwords should
never be sent in the clear when encrypted methods are readily available.
Kerberos authentication is also an option but that will require at least
two additional servers (one active and one backup) on your network
unless you're willing to share that function on a server that does
something else.
Phil Sherman
Frank Swarbrick wrote:
I am trying to understand "client authentication" works. My environment is
DB2/UDB LUW 8.2 on zSeries SLES9 as the database server and DB2 for VSE 7.4
as the client. We currently have DB2/LUW set up as follows:
Client Userid-Password Plugin (CLNT_PW_PLUGIN) =
Client Kerberos Plugin (CLNT_KRB_PLUGIN) =
Group Plugin (GROUP_PLUGIN) =
GSS Plugin for Local Authorization (LOCAL_GSSPLUGIN) =
Server Plugin Mode (SRV_PLUGIN_MODE) = UNFENCED
Server List of GSS Plugins (SRVCON_GSSPLUGIN_LIST) =
Server Userid-Password Plugin (SRVCON_PW_PLUGIN) =
Server Connection Authentication (SRVCON_AUTH) = NOT_SPECIFIED
Database manager authentication (AUTHENTICATION) = SERVER
Cataloging allowed without authority (CATALOG_NOAUTH) = NO
Trust all clients (TRUST_ALLCLNTS) = YES
Trusted client authentication (TRUST_CLNTAUTH) = CLIENT
Bypass federated authentication (FED_NOAUTH) = NO
When we connect from VSE we always specify a userID and password. The
userID and password we specify exist only on the Linux server, and not at
all on VSE.
Reading about client authentication I see that VSE can act as a "trusted
client". But I'm still not sure what this means.
The way we have things set up on VSE is we are running as "client only". We
do not have the server part of DB2 Server for VSE running. I don't know if
this will have any bearing on my questions, but I wanted to point it out.
First of all, from a batch client application in any case, and I believe
also from an online CICS client application, the VSE CONNECT statement
requires both an authorization name (user ID) and a password. When the
server is set to AUTHENTICATION = SERVER, which it is right now, it makes
sense that I use the userID and password that is defined on that server
(Linux). This all works just fine.
What I don't understand is how AUTHENTICATION = CLIENT is supposed to work.
What user ID (authorization name) and password would I supply in this case?
I can't just omit them, as VSE does not support this (for batch clients, at
least). At first appearances it sounds like I would supply the USERID and
password that are defined to my VSE security system (CA-Top Secret). But
this doesn't make sense, as this user ID is not even defined within DB2/LUW.
Specifically, my VSE user ID is "FJS". But the user defined to DB2/LUW is
"MGR_DEV1". How would DB2/LUW know that the user connected as FJS
corresponds to the user MGR_DEV1.
Confused!
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
