Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Access to sensitive data

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

  • Access to sensitive data

    Any data access (ODBC or otherwise) will require a user id and password. You may establish the initial menu parameter of the user profile to *SIGNOFF. Dave

  • #2
    Access to sensitive data

    You may want to look at third party exit point security software.

    Comment


    • #3
      Access to sensitive data

      You may also want to consider using a validation list. A validation list is used to store user id and password information about remote users. You can find information for a validation list and the validation list APIs in the information center. You could use the validation list interfaces to authenticate these users from a job that is running under a user profile that has authority to your payroll data. Since the validation list users do not have a user profile they can not sign-on or use any other interfaces to access the system. I hope this helps. Ed Fishel

      Comment


      • #4
        Access to sensitive data

        An application (using ODBC) is being developed to access payroll information on the iSeries. The application needs to have a userid and password, but I don't want that userid to be able to sign into the iSeries. What's the easiest/best way to set this up?

        Comment


        • #5
          Access to sensitive data

          There are other alternatives also. The first question is "on what type of system is the client part of the application running?" If the answer is windows, then using Kerberos authentication is a possible choice. Assuming the user signs on to a windows 2000/2003 domain, then kerberos can be used to authenticate the user and the ODBC server will use EIM to map that windows user to an administrator specified user profile. This profile does not require a password. The adminstrator can choose to map all users to the same user profile (many-to-one) or to map each user to a specific profile (one-to-one) or a some users to one profile and others users to different profiles. If the client application is WAS-based, then a different approach that allows the same administrator specified mapping can be used. Using Identity Tokens to establish trust between the client and server parts of the application is done by using one of two possible JCA connectors. The first connector generates an ID token and gives it back to the WAS application which can use it to establish an ODBC connection via the AS400 object in the Java toolbox. The other connector can be used to allow standard JDBC to establish the connection. This connector requires that the WAS application use a JNDI call to register the ID Token datasource. The JDBC connect is then coded with no parameters (e.g. jdbc.connect(); ). The rest of the JDBC is coded as usual.

          Comment

          Working...
          X