Question about authentication from a (non-mainframe) Websphere server

Larry Kirkpatrick

Question about authentication from a (non-mainframe) Websphere server

I have a question regarding the authentication process in DB2. I am not
sure I have all the facts straight, but will try to relate the question as
I understand it.

We have an application that runs on a (non-mainframe) Websphere server.
This application connects to DB2 mainframe presenting a logon ID and
password as it connects. Everything works fine except we would like to
"lock down" this particular logon id and password (from all users except
for from this process). The reason for our wanting to "lock down" this
logon id and password is that from time to time, someone attempts to logon
with this logon id and when they use an incorrect password an excessive
number of times, the logon id is disabled. This then shuts down our
production application that signs on from Websphere. Of course, another
reason for "locking down" this logon id is to enhance security.

We use ACFII for our security on the mainframe. My security person tells
me that when this application is signing on to DB2, the logon ID and
password are passed to ACFII, and the fact that this is a TCP/IP sign-on is
also presented. However, the TCP/IP address is not passed on to ACFII. If
we also had the specific TCP/IP address of this Websphere server, we would
have the ability to specify that this logon ID can only be authenticated
when it comes in from this Websphere server.

Is there anything I can do to specify that DB2 should provide the TCP/IP
address when authenticating a user? Or, as an alternative, can I limit a
specific logon ID to a specific TCP/IP address by some other means?

Larry Kirkpatrick

Myron Miller

Re: Question about authentication from a (non-mainframe) Websphere server
(in response to Larry Kirkpatrick)
Good luck, Larry. I asked IBM about a similar question about a year ago only
going from Weblogic rather than websphere. Basically they stated that there is
no way to lock down a userid/password from a given TCPIP address.

Myron

--- Larry <[login to unmask email]> wrote:

>
> I have a question regarding the authentication process in DB2. I am not
> sure I have all the facts straight, but will try to relate the question as
> I understand it.
>
> We have an application that runs on a (non-mainframe) Websphere server.
> This application connects to DB2 mainframe presenting a logon ID and
> password as it connects. Everything works fine except we would like to
> "lock down" this particular logon id and password (from all users except
> for from this process). The reason for our wanting to "lock down" this
> logon id and password is that from time to time, someone attempts to logon
> with this logon id and when they use an incorrect password an excessive
> number of times, the logon id is disabled. This then shuts down our
> production application that signs on from Websphere. Of course, another
> reason for “locking down†this logon id is to enhance security.
>
> We use ACFII for our security on the mainframe. My security person tells
> me that when this application is signing on to DB2, the logon ID and
> password are passed to ACFII, and the fact that this is a TCP/IP sign-on is
> also presented. However, the TCP/IP address is not passed on to ACFII. If
> we also had the specific TCP/IP address of this Websphere server, we would
> have the ability to specify that this logon ID can only be authenticated
> when it comes in from this Websphere server.
>
> Is there anything I can do to specify that DB2 should provide the TCP/IP
> address when authenticating a user? Or, as an alternative, can I limit a
> specific logon ID to a specific TCP/IP address by some other means?
>
> Larry Kirkpatrick

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

James Campbell

Re: Question about authentication from a (non-mainframe) Websphere server
(in response to Myron Miller)
I'm not sure if this is doable but
- lock down the user-id so that DB2 is the only thing it can logon to
- modify the connection/sign-on exits so that when the user-id logs
on EXPLTYPE and EXPLSITE are examined.
If it's not a distributed request from the the known IP address (or
backup addresses), then the exit returns EXPLARC=12.

James Campbell


On 8 Dec 2005 at 15:23, Larry wrote:

>
> I have a question regarding the authentication process in DB2. I am not
> sure I have all the facts straight, but will try to relate the question as
> I understand it.
>
> We have an application that runs on a (non-mainframe) Websphere server.
> This application connects to DB2 mainframe presenting a logon ID and
> password as it connects. Everything works fine except we would like to
> "lock down" this particular logon id and password (from all users except
> for from this process). The reason for our wanting to "lock down" this
> logon id and password is that from time to time, someone attempts to logon
> with this logon id and when they use an incorrect password an excessive
> number of times, the logon id is disabled. This then shuts down our
> production application that signs on from Websphere. Of course, another
> reason for “locking down†this logon id is to enhance security.
>
> We use ACFII for our security on the mainframe. My security person tells
> me that when this application is signing on to DB2, the logon ID and
> password are passed to ACFII, and the fact that this is a TCP/IP sign-on is
> also presented. However, the TCP/IP address is not passed on to ACFII. If
> we also had the specific TCP/IP address of this Websphere server, we would
> have the ability to specify that this logon ID can only be authenticated
> when it comes in from this Websphere server.
>
> Is there anything I can do to specify that DB2 should provide the TCP/IP
> address when authenticating a user? Or, as an alternative, can I limit a
> specific logon ID to a specific TCP/IP address by some other means?
>
> Larry Kirkpatrick

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Raymond Bell

Re: Question about authentication from a (non-mainframe) Websphere server
(in response to James Campbell)
Larry,

I know it doesn't answer your direct question (about IP addresses) but we
have a similar setup here ie. WebSphere apps connecting to DB2 (both z/OS
and NT) subsystems/databases. I'm not sure how you get to be allowed to use
a particular WebSphere data source - my education on that one has only gone
so far - but there's an ID/password hard-coded in the data source definition
which WebSphere (4; WS6 does it slightly differently, but still has an
ID/password combo in there somewhere) uses when it communicates with DB2
z/OS on behalf of the app.

The IDs we use for WS are unique to each application, and the passwords are
only known to ourselves. So no one attempts to connect using the ID as
they've no idea what the password might be and don't risk it. Or, if you're
talking about someone trying to log onto z/OS with your WS IDs, there's a
simple fix for that - the IDs have been defined so they're unable to log
onto TSO. Bit of an ACF2 (or, if you're lucky, RACF) thing, but that's how
we've nailed that one down.

Like I said, doesn't answer your question but might provide a nice
workaround.


Raymond Bell
Database Administrator

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Myron Miller
Sent: 09 December 2005 01:47
To: [login to unmask email]
Subject: Re: [DB2-L] Question about authentication from a
(non-mainframe) Websphere server


Good luck, Larry. I asked IBM about a similar question about a year ago
only
going from Weblogic rather than websphere. Basically they stated that there
is
no way to lock down a userid/password from a given TCPIP address.

Myron

--- Larry <[login to unmask email]> wrote:

>
> I have a question regarding the authentication process in DB2. I am not
> sure I have all the facts straight, but will try to relate the question as
> I understand it.
>
> We have an application that runs on a (non-mainframe) Websphere server.
> This application connects to DB2 mainframe presenting a logon ID and
> password as it connects. Everything works fine except we would like to
> "lock down" this particular logon id and password (from all users except
> for from this process). The reason for our wanting to "lock down" this
> logon id and password is that from time to time, someone attempts to logon
> with this logon id and when they use an incorrect password an excessive
> number of times, the logon id is disabled. This then shuts down our
> production application that signs on from Websphere. Of course, another
> reason for âEURoelocking downâEUR this logon id is to enhance security.
>
> We use ACFII for our security on the mainframe. My security person tells
> me that when this application is signing on to DB2, the logon ID and
> password are passed to ACFII, and the fact that this is a TCP/IP sign-on
is
> also presented. However, the TCP/IP address is not passed on to ACFII.
If
> we also had the specific TCP/IP address of this Websphere server, we would
> have the ability to specify that this logon ID can only be authenticated
> when it comes in from this Websphere server.
>
> Is there anything I can do to specify that DB2 should provide the TCP/IP
> address when authenticating a user? Or, as an alternative, can I limit a
> specific logon ID to a specific TCP/IP address by some other means?
>
> Larry Kirkpatrick

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
The IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at http://conferences.idug.org/index.cfm


This e-mail (and any attachments) may contain privileged and/or confidential information. If you are not the intended recipient please do not disclose, copy, distribute, disseminate or take any action in reliance on it. If you have received this message in error please reply and tell us and then delete it. Should you wish to communicate with us by e-mail we cannot guarantee the security of any data outside our own computer systems. For the protection of Legal & General's systems and staff, incoming emails will be automatically scanned.

Any information contained in this message may be subject to applicable terms and conditions and must not be construed as giving investment advice within or outside the United Kingdom.

The following companies are subsidiary companies of the Legal & General Group Plc which are authorised and regulated by the Financial Services Authority for advising and arranging the products shown: Legal & General Partnership Services Limited (insurance and mortgages), Legal & General Insurance Limited (insurance), Legal & General Assurance Society Limited
(life assurance, pensions and investments), Legal & General Unit Trust Managers Limited and Legal & General Portfolio Management Services Limited (investments).

They are registered in England under numbers shown.
The registered office is Temple Court, 11 Queen Victoria Street, London EC4N 4TP.

Legal & General Partnership Services Limited: 5045000 Legal & General Assurance Society Limited: 166055 Legal & General (Unit Trust Managers) Limited: 1009418 Legal & General (Portfolio Management Services) Limited: 2457525 Legal & General Insurance Limited: 423930

They are registered with the Financial Services Authority under numbers shown. You can check this at www.fsa.gov.uk/register

Legal & General Partnership Services Limited: 300792 Legal & General Assurance Society Limited: 117659 Legal & General (Unit Trust Managers) Limited: 119273 Legal & General (Portfolio Management Services) Limited: 146786 Legal & General Insurance Limited: 202050

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Larry Kirkpatrick

Re: Question about authentication from a (non-mainframe) Websphere server
(in response to Raymond Bell)
From my research on this, I also was told that changing the [login to unmask email] was a
possible solution.

However, in the manual (admin manual) that describes the authentication
process, it looks like ACF II (or RACF) is called before the exit is run.
This means that the password can still be abused (an incorrect password can
be typed in three times which will invalidate the logonid in our shop). To
do a test on this, I went ahead and changed the exit routine - [login to unmask email] -
so my logon id could not sign in to DB2. I signed onto development center
and sure enough, I could not sign onto DB2. The message I received was
SQL30082N - Attempt to establish connection failed with security
reason "15". I believe that this was my expected results for the way I
recoded the exit.

Then I proceeded to try to sign on three times during which time I typed in
an invalid password all three times. When I did this, my logon ID was
invalidated (the message DSNL030I with reason code 00F30085 showed up
twice followed by message DSNL030I with reason code 00F30088.)

It looks like I really cannot solve this problem by changing the code in
[login to unmask email]


Does anyone have any other ideas?

Larry

On Fri, 9 Dec 2005 15:09:23 +1100, James Campbell
<[login to unmask email]> wrote:

>I'm not sure if this is doable but
>- lock down the user-id so that DB2 is the only thing it can logon to
>- modify the connection/sign-on exits so that when the user-id logs
>on EXPLTYPE and EXPLSITE are examined.
>If it's not a distributed request from the the known IP address (or
>backup addresses), then the exit returns EXPLARC=12.
>
>James Campbell
>
>
>On 8 Dec 2005 at 15:23, Larry wrote:
>
>>
>> I have a question regarding the authentication process in DB2. I am not
>> sure I have all the facts straight, but will try to relate the question
as
>> I understand it.
>>
>> We have an application that runs on a (non-mainframe) Websphere server.
>> This application connects to DB2 mainframe presenting a logon ID and
>> password as it connects. Everything works fine except we would like to
>> "lock down" this particular logon id and password (from all users except
>> for from this process). The reason for our wanting to "lock down" this
>> logon id and password is that from time to time, someone attempts to
logon
>> with this logon id and when they use an incorrect password an excessive
>> number of times, the logon id is disabled. This then shuts down our
>> production application that signs on from Websphere. Of course, another
>> reason for “locking down†this logon id is to enhance security.
>>
>> We use ACFII for our security on the mainframe. My security person tells
>> me that when this application is signing on to DB2, the logon ID and
>> password are passed to ACFII, and the fact that this is a TCP/IP sign-on
is
>> also presented. However, the TCP/IP address is not passed on to ACFII.
If
>> we also had the specific TCP/IP address of this Websphere server, we
would
>> have the ability to specify that this logon ID can only be authenticated
>> when it comes in from this Websphere server.
>>
>> Is there anything I can do to specify that DB2 should provide the TCP/IP
>> address when authenticating a user? Or, as an alternative, can I limit a
>> specific logon ID to a specific TCP/IP address by some other means?
>>
>> Larry Kirkpatrick
>
>---------------------------------------------------------------------------
------
>Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at DB2-L-
[login to unmask email] Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Basivi Inaganti

Re: Question about authentication from a (non-mainframe) Websphere server
(in response to Larry Kirkpatrick)
Hi Larry, I am glad that you are still looking into it. I didn't get much
help form my RACF team when I thought that there might be a way to allow
the user coming form an IP address/host name (say XYZ) and reject in case
the IP address is not XYZ. I didn't remember exactly what analysis I did
long back. I thought it might be possible by using Conditional PERMIT
command in RACF using SERVAUTH profile name.
Check with your RACF gurus that they can do this. All we need to try is
define a new SERVAUTH profile and use that profile for the user (by PERMIT
command).

Please let us know how it works.

Thanks,
Basivi.



---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm