JD Edwards Integration Setup
Integrate JD Edwards EnterpriseOne
Table of contents
Overview: BalkanID JD Edwards Agent
The BalkanID JD Edwards Agent is a cross-platform service that extracts identity-governance data from Oracle JD Edwards EnterpriseOne 9.2 and uploads it to the BalkanID identity governance platform. It runs inside your network, on a Linux (systemd) or Windows host.
Ships as a single static binary: no Oracle client, no JDBC, and no JD Edwards middleware to install.
Extracts users, roles, environments, objects, and the permissions between them.
The database connection is read-only. The account created by the shipped grant scripts carries an explicit
DENYonINSERT,UPDATE,DELETE,EXECUTEandALTER.Makes outbound connections only, to the JD Edwards database and to BalkanID over HTTPS. It listens on no port.
Takes a full snapshot every 2 hours by default (
server.extraction_interval).Write-back is optional and disabled by default. When enabled, every change goes through AIS / Orchestrator, never through the database. See Provisioning (write-back).
JD Edwards World is not supported.
Every arrow starts at the agent. Nothing connects to it, and no inbound firewall rule is required. The two thick arrows are the only traffic that leaves your network. The BalkanID and release hostnames are listed under Requirements.
Where the agent runs
The agent can run on the database server, on an EnterpriseOne server, or on a host of its own. Any host that meets these three conditions will do:
Linux with systemd, or Windows.
Network reachability to the JD Edwards database listener.
Outbound HTTPS on
443.
The binary is self-contained, so the host needs no Oracle client, no JDBC and no JD Edwards middleware. A host that is not the database server usually needs a firewall rule opened to the database port.
How JD Edwards security works: deny by exception
The Security Workbench table (F00950) stores exceptions, not entitlements. No record at any level means permitted. A user who was never granted anything is unrestricted.
For any user, object and operation, the first match wins:
A record keyed on the user.
A record on one of the user's roles. The lowest role sequence number wins.
A record on
*PUBLIC.No record anywhere: permitted.
EnterpriseOne does not support multilevel roles. Objects with no Security Workbench record are reported once as the insight "Objects permitted by absence of any Security Workbench record", carrying the counts of objects holding a record, objects in the catalogue, and objects open to everyone.
What is extracted
Users
F0092 (rows not marked *GROUP), Address Book
JD Edwards id, Address Book link, language / time zone / date format, default role
Roles
F0092 (rows marked ULUGRP = '*GROUP'), described by F00926
*PUBLIC is always emitted as a role
Environments
F0094 + F00941 (path code) + F00942 (release)
Classified production / non-production by name prefix, with the classification method recorded
Objects
F9860, plus every object named by a Security Workbench record
*ALL is one entity, never expanded against the catalogue
User → role
F95921
Effective and expiration dates, never-expires flag, sequence, default-role flag. Expired grants are dropped
User → environment
F0093
One edge per conferring path: the direct grant and each conferring role separately
Role → environment
F0093
Direct grants only
Role → object
F00950 rows keyed on a role, including *PUBLIC
One edge per object and security type, carrying that type's named privileges together
User → object
resolved through user → role → *PUBLIC
Inherited decisions name the winning role; permitted-by-absence is marked as such
Sign-on state
F98OWSEC, status columns only
Enabled, last sign-on, failed attempts, password change frequency. Never password material
derived from the rows above
One entity per observation, linked to the users, roles, objects and environments it names
derived from the rows above
A 38-rule matrix evaluated on effective access, emitted as one insight per rule per environment
Privileges are named rather than generic: run, install, add, change, delete, view, copy, select, promptForValues and promptForVersion, scoped per security type (action, column, application, row, processing option, tab, exclusive application, external call, Solution Explorer, media object).
No business data is read: no transactions, vouchers, journal entries, payroll, purchase orders or GL.
Insights and Segregation of Duties
An insight is a security observation the agent derives from the data it extracted. Each one is emitted as its own entity and linked to the users, roles, objects and environments it concerns, alongside a severity, a description, suggested mitigations and notes for your instance.
Four of the observations the agent reports:
"Security Workbench (P00950) Accessible Outside CNC"
"Development And Design Tools Runnable In Production"
"Seeded Default Account Enabled"
"Stale Privileged Account"
A Segregation of Duties violation is one kind of insight, raised where a single principal can reach two applications that should be held apart. There are 38 rules, covering Procure-to-Pay, Order-to-Cash, Record-to-Report, HR / Payroll, Inventory, Fixed Assets and ITGC. Two of them:
"Supplier Master + Payment Processing", pairing supplier master maintenance (
P04012) with payment processing (R04570/P04571/P0413M)."Journal Entry + General Ledger Post", pairing journal entry (
P0911) with general ledger post (R09801).
A violation is raised once per rule per environment, so the same person can be clean in Development and in violation in Production. Outside a production environment the severity drops one level. Other insights carry every environment they concern.
Both can be turned off in the security block of the configuration, with disable_insights and disable_sod.
Continue with Requirements and Installation & configuration.
Last updated
Was this helpful?