E9.2 Application access for external consultants

[sontu99]

Hi all I'm new to the site and JDE in general. I have been tasked to create a user for an external consultant to support our JDE environment but I need to make sure the user doesn't have access to sensitive applications. Do you have any suggestions which applications should be restricted? Security is still a new concept for me. How would I go about restricting access?

 

[jdecoder]

There Is something called JD Edwards EnterpriseOne portlets on WebCenter

Introduction to Portals and Portlets

Explore them for access control to specific areas where external entities will collaborate within JDE example : Supplier self service

 

[MFreitag]

Really depends on what they should support you with. I'd say P0911 e.g. is sensitive, if they are a financial consultant though, they will probably need that

 

[markdcci]

Sontu,
JDE security is very flexible but can be somewhat complex as a result of that flexibility.

This knowledge document on My Oracle Support is a pretty good overview with a lot of links to the sub-topics: Overview and Use of Security Workbench (P00950) (Doc ID 626545.2)

But you should probably also use the Security Administration Guide for any in-depth research.

A couple of general ideas, though.

You will likely want to give them access to the inquiry functions on applications, just not the action functions like Add/Change/Delete. That can be done through Action security (Type 1).
In addition to that, you could also limit them to run only the applications they will be supporting (Type 3). For example you could add a Type 3 row in security workbench where Application Security is N for application of *ALL. Then add a row for each specific application (example, P01012) with a Y that allows them to run it. If they access a lot of different applications this could get a bit tedious, though, and you need to make sure you add back in the basic stuff like changing your password, etc. You can also use the *ALL trick on Action security as well only making Add Change Delete all N, as an example.

This will likely take you several iterations to get right. I recommend allowing the user only access to a test environment until everything is locked down the way you want it.

Don't forget to lock down OMW functions and other system set up things like OCM so they can't circumvent your controls.

Lastly, set this security up via a role and assign the role to the user rather than assign the security directly to their user ID. Might seem obvious but I had to say it.

Good luck.

 

[sontu99]

Sontu,
JDE security is very flexible but can be somewhat complex as a result of that flexibility.

This knowledge document on My Oracle Support is a pretty good overview with a lot of links to the sub-topics: Overview and Use of Security Workbench (P00950) (Doc ID 626545.2)

But you should probably also use the Security Administration Guide for any in-depth research.

A couple of general ideas, though.

You will likely want to give them access to the inquiry functions on applications, just not the action functions like Add/Change/Delete. That can be done through Action security (Type 1).
In addition to that, you could also limit them to run only the applications they will be supporting (Type 3). For example you could add a Type 3 row in security workbench where Application Security is N for application of *ALL. Then add a row for each specific application (example, P01012) with a Y that allows them to run it. If they access a lot of different applications this could get a bit tedious, though, and you need to make sure you add back in the basic stuff like changing your password, etc. You can also use the *ALL trick on Action security as well only making Add Change Delete all N, as an example.

This will likely take you several iterations to get right. I recommend allowing the user only access to a test environment until everything is locked down the way you want it.

Don't forget to lock down OMW functions and other system set up things like OCM so they can't circumvent your controls.

Lastly, set this security up via a role and assign the role to the user rather than assign the security directly to their user ID. Might seem obvious but I had to say it.

Good luck.

Thank you!!!!!

 

[BPConnor]

Hi all I'm new to the site and JDE in general. I have been tasked to create a user for an external consultant to support our JDE environment but I need to make sure the user doesn't have access to sensitive applications. Do you have any suggestions which applications should be restricted? Security is still a new concept for me. How would I go about restricting access?

as others have said, the access required depends on what support they will be providing. If you are in an open model, they already have access to everything and you will need to restrict access to critical programs which again depends on what they are doing. I would also restrict them from Production unless that is a critical need for the company. There are lots of companies that put on webinars around JDE security, google and find some to watch to get a better handle on what is possible and what are some best practices.

 

[Harry Chen]

A few thoughts:
1. Short term: create a role that cannot access production environment. Assign security of an existing user that can fit the need for the consultant.
Then you can add an Action security to put *all object with Add/Change/Delete=N.
2. For sensitive applications restriction,
a. All doors closed: one method is to deny all and grant back what he needs. This method does not need you to know all the sensitive applications.
b. All doors open: if you already granted *all, then you need to deny sensitive applications. There are hundreds applications to deny, like payee control, IT related.
FYI - all doors closed policy should be better.
You might need some time to plan for your security. You can start from your menus and related hidden programs called by the menus. Then you would finally get a list. Also you can use system code to decide what applications you like to deny. For example, 98 - system, 09 - accounting, 01 - address book, 04 - Accounts Payable.
Hope it helps.
--Harry

 

[Luke Phillips]

Hi Sontu,

You can close specific programs of course and leave the system generally open to everyone. If you do that you should close the IT programs (including programmer and CNC functions) to all users. Closing off Business User programs from other business users tends to be at the request of the business users that own their relevant programs.

If this sounds complex to achieve that is because it is. It's simpler to close down everything and work out what is required and have a Deny All/ All Doors Closed model. This has the advantage of facilitating easier reporting and controls.

This is what we and other service providers often help companies to achieve. Hope this helps!