Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Calling all Sugestions- Putting New Security into Existing Applications

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Calling all Sugestions- Putting New Security into Existing Applications

    I have recently taken over a shop that has been writing RPG code since the early 80's. The code is good and the staff is solid, but security has never been an issue as far as the users are concerned. All of our users until recently have been employed by the same company. We have recently added a VPN so that all our clients may dial in via the internet and view their claims and pull reports for their respective accounts. We have also just recently added a client that wishes to use his personal at his site dialed in using our applications. while all this growth is great, it raises a major question as to security. We want no client to see or in any way access any other clients data. Im looking for the best solution to this opportunity. Are there software packages out there that will help us, ways to assign data sets to certain users, you name it we'll listen. Things we have thought of : 1.) Building a record of paramaters, keyed on the user profile and changing the front end screens of every program to check for validity. 2.) OK thats it were tapped , give us your sugestions. All susgestions are welcome, Thanks-

  • #2
    Calling all Sugestions- Putting New Security into Existing Applications

    I used your first suggestion, linking a user profile to a customer number in a parameter table to provide a key for processing. But I also wrote a front end of transaction API's that called rearranged portions of existing logic with the customer number already set. This is great for handling the need of limiting not only what a customer can see, but what they can do, and is the most logical approach when providing a new front end client. It's not a good approach for making an existing suite of green screens available to customers. In my opinion, the best approach for making available programs and data to customers with bullet proof security with a minimum of modifications is to create a data library per customer and set the library list at signon. This not only isolates customer data, but also allows you to place different versions of green screens in the libraries for different levels of customer access by removing or adding menu options, screen fields, etc. Of course, the big tradeoff on this is lack of consolidated data for internal consumption. The best way that I know of to maintain your existing centralized files of data is to place a trigger on each customer file that then duplicates the add/change/delete of a record to the corresponding internal file at the time it takes place. This gives you a real time aggregation of all of your customer data to use as a data warehouse for reporting and analysis with no change to your existing code. Ralph

    Comment


    • #3
      Calling all Sugestions- Putting New Security into Existing Applications

      I believe Ralph's suggestion is the way to go. However, I suggest that in addition, you restrict ownership and access of each customer's data libraries to different group profiles. This way, you can use the AS/400's built-in resource security to further restrict unauthorized access. This is specially important when some (or all) of your customer's may be business competitors. It is only a matter of time before one of them decides to employ some kind of ODBC package (including Client Access) to 'explore' your AS/400 for some 'bonus' information.

      Comment


      • #4
        Calling all Sugestions- Putting New Security into Existing Applications

        I don't know whether this is off topic, but at one green tube-RPG customer there was a need for banks to look at inventory. We built logical views of inventory that selected a certain bank's stuff and overrode the datafile to the view. In this particular situation, the views were built when the bank signed on... and the views were not a big hit on the 400 cpu. PS: both IMS and DB2 were designed with this problem in mind; IMS -TMK- has not been ported to the 400 and DB2 is seldom used by designers. Sounds like you have to go with what you got. bobh

        Comment


        • #5
          Calling all Sugestions- Putting New Security into Existing Applications

          I agree Bob, When making changes to an existing system to accomodate access from an extranet, it was not much of a big deal to allow each customer access to only those records that pertained to said customer. In this manner you can use DB2/400 (or whatever it's being called this week) to create a secure environment. The programming techniques used are simple, effective, and easy to implement. If programmed properly, you may not have to use object authorities at all. my $.02 Dave

          Comment

          Working...
          X