UTB and Data Browser security

Alen

Member
Hi,
Anyone knows how to secure UTB and Data browser only from PD environment?

Really appreciate your response.

ERP 9.0
TR 9.1.4.4
SQL 2008 R2
Win 2008 R2
 
Alen,

The only way I can think of quickly is rather drastic. We have actually done it on a temporary basis to test security in a previous version of JDE. We created a copy of the security workbench table and put it in the PD database datasource and changed the OCM to refer to the new table for the users involved for the environment they were using.

If you go this way, research and test it thoroughly. I do not know what Oracle would say about it, maybe something like "system tables should not be modified". It worked for us on a temporary basis. I do not know how it would go on a permanent basis.

I did say it was a rather drastic option.

Luke Phillips from All Out Security may add some comments on this.
 
In Security Workbench, have you tried setting up your production security roles with Data Browser Security (Security Type = B) with Queries = N and Run = N, and then setting up your non-production security roles with Queries = Y and Run = Y ?

-Jim
 
Appreciate your response Peter. So you have modified copy of F98OWSEC and mapped it to the particular users. I am not quiet sure how this option will help me with my case. I am stock at how to deny particular users on fat client and data browser changing the data source from say PY or DV to PD and see production data. You know that they can be in PY while loading UTB and change the default data source from PY to PD.
However, your solution is a good work around if I can some how related to my problem.

Thanks Again,
Alen
 
You could give the user two user ID's, say USERPD and USERDV. The USERPD's role could be set to only have access to PD, and the USERDV's role could be set to have access to DV, PY and PS. Then set security on the USERPD role to no access for UTB and DataBrowser, and set security on the USERDV role to allow access for UTB and DataBrowser. Yes, it's two user ID's, but it would accomplish the separation in access you're requesting.
 
We created two roles and attached them to the same ID. One role only was valid for PD, for instance, and would not have access to databrowser. The other only had access to PY and would have access. Only one role or the other would be active depending on their login environment. But I think your question is how to prevent them from changing the data source once they are within the app.

We didn't have a good way to do this, but in talking with the users they were really only querying on 8 - 10 tables. So we created custom applications over those 8 tables, essentially mirroring the table layout minus irrelevent columns. This gave them access to the data in a grid format, easily queryable and exportable, but no access to anything else. Very quick to develop since you are not doing any logic. Kind of a 'hammer' solution, but it worked.
 
Alen,

The two tables to which I referred were the OCM which is F986101 and the Security Workbench which is F00950. I did not refer to the F98OWSEC.

It seems I misunderstood your request. I thought that you needed to prevent access to Universal Table Browser (UTB) and Data Browser (DB) applications from Production. I did not realise that the need was to prevent access to production data from these applications. Please confirm that this is the requirement.

The prevention of access to production data via UTB and DB probably requires prevention of access to the applications in production.

Please also consider Jim's (jdemes) suggestion of separate roles, one with access to production only and the other with access to non-production only, and separate security applied to these roles as needed. If it works, and I think it is very likely to, it would be a simpler, and therefore a better, arrangement than what I describe below.

In both options the same basic security needs to be applied. For production access no access to UTB (via security type 7 - External Calls) or DB (security Type B - Data Browser). For non production the production data sources need to be secured (via security type 4 - row security). Both options should be thoroughly tested before being put into production. Ironically, it was to test security changes that we temporarily used two copies of the F00950 as described below. It is mainly for this reason it is included in this post.

I will proceed with the requirement to prevent access to production data from the UTB and DB applications.

I am assuming that you have multiple environments and pathcodes in your JDE installation. Also I am assuming that access to these is needed in non-production environments and pathcodes.

Therefore different security needs to be applied to production compared to the non-production. Because the Security Workbench (F00950) cannot be set up to apply separately to production and non-production (only by User or Role), there will need to a separate copies for production and non-production. Entries in the OCM (F986101) would point to the copy of the Security Workbench (F00950) to use for the environment and/or User/Role.
 
Last edited:
Don that is another good logic but again this is not really environment issue and a more of a data source selection issue while in UTB. Even if you restrict users accessing UTB in PD, users can run UTB in DV or PY and then change the data source to Business Data source - Prod. I sort of managed to use the column security on P98TAM for the alias TADP and it works to some point but the disadvantage is that now if developers need to open one same table from two environment e.g. DV and PY then that is not possible. However, data browser access has a similar nature but different story.
 
Peter, thanks for your descriptive in details. I have used security type 7 and type B. Security type 7 on P98TAM somehow worked as long as user clicks and choses the data source from visual assist but there is a flaws there where wondered me so much because even though it would secured it through visual assist, users can just delete the default data source and type Prod and amazingly will take it. The OCM mapping might be more functional but is not in favor with business.
 
Alen,

Security type 7 is for external calls. External calls include UTB.exe which is the UTB executable. I would expect strange results if it was applied to a JDE application such as P98TAM.

Here is the detail for the security:

User and Role Environment Access:

Do not allow access to any environment to the user ID for any Users that need to be secured. Create roles for them which have environment access to either Production or Non-Production, but NOT both.

In Production:

1) Disable access to Data Browser by using security type B - Data Browser Security for Users and/or Roles applicable, with the "Allow Access to Data Browser" box empty or unchecked. I think you have dine this.

2) Disable access to UTB by using security type 7 - External Calls Security for Users and/or Roles applicable and securing UTBrowse.exe. This will not allow users to run the UTB.

In Non Production:

Disable access to the Production Business Datasource by using security type 4 - Row Security for Users and/or Roles applicable. For "*ALL" tables, Alias "DATP", Data Item "DatabasePath", From Value "Business Data - PROD" Thru Value"Business Data - PROD", and View, Add, Change and Delete all "N".

If you have any questions I'll do my best to answer them.
 
Hi Peter,
Sorry for delay getting back to you but this has greatly worked for me. Very well response!

Thanks,
Alen
 
Back
Top