I think I would agree with those who are saying "Don't mess with it", not only because it might help the cracker, but also you may be eliding your own security policy. You (hopefully) put a lot of thought into your RACF policy, so let RACF do it's job. If people get bit/revoked because they fuzzy fingered it with a TSO session, and you have no problem with that, then I think your new "proxy" should retain the same severity of requirements.
Aaron > >In terms of validation, I was more thinking along the lines of "I know >that RACF ids can be a maximum of 8 characters, and are composed of the >characters A-Z,@#$,0-9. So I'll check that the id doesn't contain >anything else." I don't consider this a security problem, per se, but a >way to "help" somebody (like me) who may have "fat fingered" something. >Otherwise, it will not be detected unless/until the person attempts an >ftp (if they even do that). > >So far, the consensus of opinion is to allow the far end to even do >syntax verification. Sounds good to me. > >What I may do is to have a button like "Validate host / userid / >password" so that the user can click that and attempt to connect to the >host using the given userid and password. If the logon fails, I'll >report that to the user. If the user doesn't want to valid at that time, >then it is his problem if the ftp fails later on. That's what I'm trying >to avoid. > >-- >John McKown >Senior Systems Programmer >HealthMarkets >Keeping the Promise of Affordable Coverage >Administrative Services Group >Information Technology > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
