Date: Tue, 29 May 2001 22:43:13 +1200
Reply-To: Don Stanley <don_stanley@XTRA.CO.NZ>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Don Stanley <don_stanley@XTRA.CO.NZ>
Subject: Re: Using a generic userid under RACF
Content-Type: text/plain; charset=us-ascii
Not sure you interpreted the question right Michael. My interpretation is that
Colin wants a signon that the batch job he submits via FTP runs under, not just
the DB2 component of the job.
Either way, he's wrestling with a very similar issue to me at present. Ours is
SAS/CONNECT and security depts not wanting to permit us to use a generic signon
in an RLINK. I see the issue, anyone can see the userid and password. I did
exactly what Colin mentioned below, encrypted in a SAS dataset. That hasn't
placated them to any great extent, although they seem to have found useful
things to do and left me alone a bit since.
However the security guys point is valid, even if we encrypt the password in a
SAS dataset, somewhere there is code to de-encrypt and obtain that password, and
the exact same arguments apply, as in our place ultimately anyone can see that
code, be it in a public code library, or in SDSF or OMCS archives.
In my opinion, a bigger exposure is products like ConnectDirect and XCOM where
parameter files seem to demand that passwords are written for the world to see.
I collated a list of about 20 different signons and passwords that were publicly
available in parms files, just to show them the precedent existed -- I got the
impression it wasn't really appreciated :-)
To me, the security argument is valid. But I always have to ask, who is going to
bother searching archives and code for a password they don't know exists. Thats
pretty irrelevant though, the basic premise of security is that an exposure
should be removed.
If anyone does have answers, please post them to the group, its a question that
anyone using RLINK files should have an interest in.
Don
Michael Davis wrote:
> Hello Colin and other SAS-L friends,
>
> It took a re-read for me to figure out where you want to go with this. You
> want to set up passwords to DB2, not SAS. Also you probably need
> write-access to DB2 to use plan tables or similar structures.
>
> How about a touch of SAS/AF? Your SCL program would look something like:
>
> init:
>
> rc=libname('test', 'c:\test')
> ;
>
> rc=rc
> ;
>
> return ;
>
> In your case, you'd have to specify the DB2 as the engine and the password
> and SSID as options. The general syntax from the OnLine doc would be:
>
> sysrc=LIBNAME(libref<,SAS-data-library<,engine <,options>>>);
>
> How do you use it in your SAS program? Try PROC DISPLAY, which does *not*
> require SAS/AF on your mainframe.
>
> proc display c=work.sasltest.test.scl ; run ;
>
> where sasltest would be changed to the catalog that you put your SCL
> program into (test.scl here).
>
> When you run PROC DISPLAY, the log is going to look something like:
>
> NOTE: PROCEDURE DISPLAY used:
> real time 0.09 seconds
> cpu time 0.07 seconds
>
> There will be additional messages but the password will be masked on the
> SAS Log.
>
> If you compile the SCL so that the source code is not available, your
> security will be complete.
>
> - Michael "Mad Doggy" Davis
>
> At 10:02 PM 5/28/01 +1000, Colin Holmes <holmesc@ICA.NET.AU> wrote:
> >Hi SAS-Listers,
> >
> >we are running SAS V8.x on Windows NT and download DB2 data from the
> >mainframe (OS/390) via SAS/ACCESS.
> >To allow us to run jobs overnight we use a "generic" userid to be
> >authenticated by RACF. We would now like to submit jobs to JES2 via FTP,
> >however all jobs that are submitted run under the generic userid which has
> >limited access (i.e. read only).
> >
> >Before the system programmers / security departments will increase the
> >access permissions we need to ensure that the password
> >used by the generic userid is protected. Currently we have it encrypted in
> >a SAS dataset and use macros to build the libname and filename statements
> >which hold the password in a macro variable.
> >
> >Does anyone have any suggestions / recommendations for protecting the
> >password or a better solution to allow us to achieve the above ?
> >
> >TIA,
> >
> >Colin.
>
> Michael L. Davis
> Vice President
> Bassett Consulting Services, Inc.
> 10 Pleasant Drive
> North Haven CT 06473-3712
> E-Mail: michael@bassettconsulting.com
> Web: http://www.bassettconsulting.com
> Telephone: 203-562-0640
> Facsimile: 203-498-1414
> Messages: 888-477-1412
--
Don Stanley, B.SC, Dip O.R.S, MNZCS
EMAIL:: don_stanley@xtra.co.nz, don@sysware.co.nz
Author:: Beyond the obvious with SAS Screen Control Language.
Author:: Solutions for your GUI Applications Development Using SAS/AF FRAME
Technology
http://www.sysware.co.nz , http://www.geocities.com/don_stanley_nz/don_home.htm
| 
