Oracle Entitlement Server: Integration with JD Edwards EnterpriseOne

We're in the beginning phases of defining a technical architecture for a JDE EnterpriseOne (version 9.1) installation. This installation will form the backbone of our IT strategy moving forward.

Thus, I'm very new to this application, and I hope this question isn't too elementary. The Oracle documentation didn't turn up much, and Google wasn't of much help, either.

As part of our architecture, we need to centralize our security access (including application permissions). We'll be using the Oracle Entitlement Server to manage application permissions using custom actions. These actions are easily checked in code via an API (an example would be the PEP API for Java or .NET applications).

However, I have been unable find information about how to integrate EnterpriseOne security into the centralized Oracle Entitlement Server repository (or if it's even possible to do so). Given the source of both applications, the purpose of the Entitlement Server, and the scope of EnterpriseOne I would ASSUME that such integration is possible, but I have yet to find such confirmation.

So my (probably elementary) questions are:

1) Does such integration exist? Can the EnterpriseOne security options be managed from the Oracle Entitlement Server by an existing Security Service Module (SSM) [or some other method]?

2) Is there a resource that can be referenced with more information about the process (if it's possible)? Can you point me towards it if it does exist?

Hi Matt

Currently I do not believe that Oracle Entitlement Server provides support for EnterpriseOne. I'm not sure whether this will change, given the different layers involved and thethe way that EnterpriseOne security works. Let me explain a little more on this.

JD Edwards Security has evolved over the past 18 years or so, from a single group based model to todays multi-role based model. Security has also become more granular - 9.1 introduced new security types, and different tools releases often incorporate changes within the security model. As such, there are three ways to manage security within JDE - either you manage it directly with the tools that JDE provides (which are sufficient, but provide minimal reporting and often require a lot of time to manage to an Audit requirement) - or you use either QSoftware or AllOut - two partners that provide security management for those customers with larger numbers of users/roles/audit requirements.

Both of those companies provide a "simple" management technique for SOX or Segregation of Duties on a closed-door model, and are mated extremely closely with the EnterpriseOne product.

However, as JDE starts to be deployed amongst larger corporations - corporations that might be using either a best-of-breed solution - or using many different products for different parts of their business - and then tying these products together through middleware (ie, Oracle SOA Suite integrations) - the segregation of duty requirements become a lot more demanding since multiple products have to be monitored now.

Oracle came out with GRC - Oracle Governance - to combat this, which, with the Greenlight pack for EnterpriseOne (http://download.oracle.com/opndocs/americas/GreenlightGRCforJDE.pdf) - provides a centralized method to report segregation of duty issues across multiple stacks in the SOA suite.

Now, everything we've talked about so far is with the functionality of the product in mind. But EnterpriseOne is more than just an application - it incorporates a centralized suite of development tools that provide objects that often communicate with external products. JDE has provided the Business Services (BSSV) architecture as a "one stop" point for all integrations moving forward - and SOA Suite should communicate to those objects delivered through BSSV

But JDE doesn't provide tools to manage authentication or entitlements for these integrations. Security Certifications and User profiles are expected to be managed outside of JDE. Hence the reason why the Entitlement Server, while quite new to Oracle, will almost certainly have some sort of bearing on JDE provided business objects.

But heres the thing, theres nothing to stop a customer using the entitlement server today. There just isn't any documentation on existing integration points, since many customers develop their own integrations.

So, in summary - yes, you can use Oracle Entitlement Server to manage certificate and permissions within the SOA bus - but it doesn't reach into the application functional security (which you probably don't want it to do) - nor will it provide an overall segregations of duty (which is what GRC provides) - but it can provide permissions within the SOA Stack as far as Business Services.

Hope that helps. If you need help with your implementation - please keep me in mind !

Considering the importance of EnterpriseOne to our strategy, it's unfortunate that it doesn't integrate with the Entitlement Server. Indeed, the proposed guideline was to centralize all of our application permissions into a central repository (Entitlement Server) which would have simplified access management, SOX compliance, auditing, and SoD. Such is life, I guess.

I'll probably need to investigate integrating the JDE permissions into at least a reporting module so we can get all the SOX/auditing information from one source, but that seems like a manageable task.

I'm familiar with both QSoftware and AllOut, actually, although we're unlikely to have access to any of their tools (unless we can twist the right arms). QSoftware, in particular, has a dual role model that I like in concept (the two roles are used to separate out functional access from item access).

Regardless, we are using a SOA suite to integrate with in-house applications, so it's good to note that integrating SOA with the Entitlement Server is feasible (the lack of documentation doesn't worry me much as long as we know it's possible - we can figure out the nuts and bolts once we have an environment to tinker with).

I'll have to look into the GRC. I don't see it in our suite of products, but perhaps that's just an omission.

Thank you for your response. It was very thorough and enlightening.