The access & audit layer for IFS Cloud

“HR can only be opened from the HR network.”IFS can’t say that. iWaf can.

IFS authorisation decides what a user may reach. It can’t decide from where, when, or how much. iWaf understands every IFS screen, module and endpoint — so you can finally write the rules that were impossible until now. It listens first, and enforces only once it has been measured on your own traffic.

See the rules → Book a walkthrough
Zero changes to IFS Rules by screen · module · endpoint SaaS or on-prem
iWaf · live gate measuring
    Illustrative stream · identities anonymised
    0lines of IFS code, tables or permissions changed
    5,000+IFS screens understood by name, in your own language
    Day 1who did what, on which screen, on which record
    1 commandto install — and to remove without a trace
    The missing question

    Most risk in an ERP
    doesn’t look like an attack.

    It comes from authenticated, legitimate users. The question is rarely whether a request is malformed. It is whether this user should be doing this, from here, at this time, at this volume. A generic WAF can’t answer that. Neither can IFS authorisation.

    The question Generic WAFKnows attack patterns, not your application IFS authorisationKnows what, not where, when or how much iWafKnows IFS. Asks the whole question.
    Who is it?A named person, not a shared technical accountNoYesYes
    Which screen, which record?In the words your users seeNoPer objectScreen, module, endpoint, record
    From where?Network, site, countryIP only, app-blindNoPer module & screen
    When?Working hours, audit windowsNoNoPer screen
    How much?Records leaving in one operationRaw request rateNoPer operation
    Person or AI agent?Acting on a user’s behalfNoNoDetected & recorded
    Keeps IFS working?Legitimate IFS queries pass untouchedOften breaks the UINativeIFS-aware inspection

    A generic, signature-based WAF inspects requests without knowing what IFS does — worse, it tends to mistake IFS’s own queries for SQL injection and break the interface. iWaf is built for IFS alone. That is the whole point.

    Rules you couldn’t write before

    It knows which screen you’re on.
    So it can guard it.

    An authorisation system says “this person may see HR”. iWaf goes one step further and binds that module to a network, a time window and a volume — without handing out, or taking away, a single IFS permission.

    A brass-framed stone gate lets glowing data cubes from a lit inner corridor pass, while cubes from the dark outer corridor stop before a lowered portcullis under a watching lensEndpoint & network
    Endpoint exposure

    Only one service faces the internet. Everything else stays inside.

    Open a supplier portal, e-invoicing or a single integration endpoint to the outside world, and you have usually opened all of IFS with it. iWaf decides, endpoint by endpoint, what is visible from outside and what exists only on the internal network.

    exposeSupplier invoice servicefrominterneteverything elseinternal only
    Network

    Human Resources opens only from the HR network.

    Even with the right permission, a personnel file can’t be opened from home or the guest Wi-Fi. The rule covers the whole module — no screen-by-screen permission juggling.

    A great brass astronomical clock built into the stone gate points into a night sector; a clockwork bolt keeps the golden portcullis lockedTime
    Time

    Payroll screens can’t be opened after hours.

    A midnight visit to the salary screen is stopped — even when the user is fully authorised — and lands in the audit trail with the screen, the person and the attempt.

    The same mechanism makes chosen modules read-only during a closing or audit window, without touching a single IFS role. When the window ends, the rule lifts.

    screenPayroll › Salary CalculationoutsideMon–Fri 08:00–19:00deny + record
    A river of hundreds of glowing cubes pools behind a brass valve that lets only a small measured stream through the gateVolume
    Volume limit

    No single operation takes more than 500 customer records.

    An authorised user can technically pull your entire customer base in one request. It is also exactly what a stolen session, a careless script or an over-eager AI agent would do. iWaf puts a ceiling on it — per screen, per operation.

    screenSales › Customersmax per operation500 recordsblock above
    Person + source

    Supplier bank details: two people, their own network.

    An IBAN change followed by a payment run is the classic fraud pattern. Bind the screen to named people, a defined network and a second approver.

    Supplier › Payment AddressFinance LAN2 approvers
    Geography

    No module opens from abroad.

    A leaked password is no longer a session. Exceptions are precise: this user, this country, this period — and then they expire.

    All moduleshome countrytime-boxed exceptions
    Account type

    Integration credentials can’t drive human screens.

    Integration accounts are powerful and rarely rotated. Keep them on their own endpoint — segregation of duties, actually enforced.

    Integration accountsown endpoint onlyno UI
    Audit window

    Read-only while the auditors are in.

    Freeze selected modules for writes during a close or an audit, and release them afterwards. No role changes, no side effects in IFS.

    Finance modules1–10 Janread-only
    ◆ Built for the agent era

    Person,
    or an agent acting for one?

    AI assistants and autonomous agents are starting to work inside ERPs on their users’ behalf. iWaf is purpose-built to tell them apart from genuine human sessions — and to record the difference.

    01
    Non-browser client signaturesTraffic that claims a person but carries the fingerprint of a program.
    02
    A pace no human keepsRequest rhythms that are too fast, too regular, too tireless.
    03
    Integration credentials on human screensA machine account clicking through forms that were built for people.
    04
    Abnormal single-pass volumeWhole datasets read in one sweep, the way only software reads.

    Session rhythm · same user, same screen

    user-A · in personirregular · 11 actions / 4 min
    agent acting for user-Ametronomic · 240 actions / 4 min
    “Who changed this record?” finally has an honest answer.
    14:02:11  user-A  updated Customer Order 10482
    14:06:40  agent → user-A  read 2,318 Customer records
    14:06:41  agent → user-A  blocked · volume limit

    Agent access can be confined to defined screens and volumes — so you can say yes to AI in the ERP without saying yes to everything.

    It reads IFS the way your people do

    Every request, resolved to
    a person, a screen and a record.

    Screen context is already present in every IFS request. iWaf resolves it against your own IFS menu tree, so rules and reports use the screen names your users actually see — in your own language. Nothing is installed on clients. Nothing is injected into the browser.

    what iWaf sees → what iWaf records
    — raw request to IFS ————————————————————————
PATCH SubContractValuation.svc/SubvalValuations(
      SubConNo='•••',ValuationNo=7)
screen  SubContractValuation/Form;path=0.1531…
status  200

— iWaf audit record —————————————————————————
✓ 12:23:41  user-A  · in person
  Subcontract Valuation · SubConNo=•••, No=7
  record updated
  [Contract Management › Subcontract Valuation]

    IFS-aware inspection

    Legitimate IFS queries pass. Real injection is caught.

    Query filterGeneric WAFiWaf
    Identity eq 'A' or Identity eq 'B' and contains(Description,'or 1')blockspasses
    State eq 'Planned' and year(DueDate) eq 2026blockspasses
    Identity eq 'x' union select null from information_schema.tables--blockscatches
    Identity eq 'x' and 1=1 /* */ waitfor delay '0:0:5'blockscatches
    Reads as well as writesNot only who changed a record, but who looked at it — by default, not object by object.
    A person, not a poolThe database sees one technical account. iWaf sees the human behind every request.
    Your menu, your wordsBuilt at install time from your own IFS navigator — customisations included.
    A great round glass lens set in a brass gear ring watches a steady flow of glowing cubes pass under an open golden gate
    Listen first

    A security control should never become an availability incident.

    Every rule starts life in monitoring mode. You see what it would have done on your real traffic before it is allowed to do anything.

    Rule · Payroll after hours30 days on your traffic
    0Triggered
    0Confirmed
    0False alarm

    Status: proposed for enforcement — awaiting your approval.

    The console

    See what happened
    before you write a single rule.

    iWaf · Audit consoleMEASURING · NOTHING BLOCKED
    Between 09:00 and 13:42, 1,200 business actions passed through; 669 of them changed data. The rule engine raised 5 high or critical findings — in measuring mode, none were blocked. Busiest screen: Instant Invoice.
    Actions1,200from 17,082 raw requests
    Data changes669create · update · delete
    Open findings75 high / critical
    Sessions151 agent-driven
    Screens seen430resolved to menu path
    SeverityFindingWhat to doWho / whereTriage
    ◆ CriticalInjection attempt in query filterunion select · information_schemaCheck source and user. Enforcement would block this.11:39:02 · user-Cexternal address
    reviewedclosefalse alarm
    ◆ AgentAgent session on human screens240 actions / 4 min · CustomersConfirm the assistant is sanctioned; limit screens and volume.14:06:40 · agent → user-Aoffice network
    reviewedclosefalse alarm
    ▲ HighPersonnel file opened outside HR networkHR › Employee FileCandidate for the HR-network rule.12:10:55 · user-Fguest Wi-Fi
    reviewedclosefalse alarm
    ▲ HighRepeated unauthorised access12 attempts in 3 minPossible scanning — review at network level.11:44:34 · —external address
    reviewedclosefalse alarm
    ● MediumOversized listing9,999 rows in one call · Customer InvoicesDoes the process need a list this large? Consider a volume cap.11:41:39 · user-Boffice network
    reviewedclosefalse alarm

    Illustrative data modelled on a live IFS Cloud environment. Identities anonymised.

    Governance

    Run like a control.
    Not bolted on like a tool.

    An explicit rule set

    Rules are defined together with you, from your exposure requirements and internal policy, and documented as a rule set your auditors can read.

    Change management built in

    Every rule change follows change management and is recorded: what changed, when, by whom and why.

    Separated administration

    iWaf has its own identity store. The audit layer can’t be silently switched off from inside the system it audits — and stays reachable when IFS is down.

    Tamper-evident trail

    Each audit record is chained to the one before it. Altering or deleting history becomes detectable, not deniable.

    SIEM-ready

    Blocked and flagged events are logged, reportable, and can be forwarded to your SIEM alongside the rest of your security telemetry.

    Complements your perimeter

    It works alongside perimeter firewalls, encryption in transit and your authentication controls — covering the layer they can’t see.

    Deployment

    Two delivery models.
    One product.

    On-prem

    Inside your walls.

    iWaf runs in your own network. The audit trail and the console stay within your boundary — no data leaves.

    • Your infrastructure, your retention policy
    • Fits regulated and data-residency constraints
    • Operated by DBO or by your team
    SaaS

    Operated for you.

    DBO runs iWaf. You connect to the console; installation, upgrades and maintenance are ours.

    • Live in days, not projects
    • Rule set curated by people who run IFS daily
    • Continuous tuning included

    The rule engine, the menu dictionary and the console are identical in both — moving between them needs no reinstallation.

    Impact on IFSZeroNot a line of code, a table or a permission. Uninstalls with one command.
    LatencyNot measurableRecording is asynchronous. If it ever falls behind, a record drops — never a request.
    CoverageReads + writesWho looked at what, not only who changed it.
    IdentityIsolatedConsole sign-in is independent of IFS — segregation of duties preserved.
    QuestionClassic system logsiWaf
    Which person opened this record?Person, screen and record are rarely in one reliable place.User, screen and record key on the same line.
    From which screen?Not recorded.Menu path, in your organisation’s own language.
    Are reads recorded?Enabled object by object — so in practice, rarely.Reads are recorded by default.
    Person or AI agent?Indistinguishable.Distinguished and recorded.
    How invasive is setup?Configuration and per-object enablement inside the system.Zero touch on IFS.
    Risk of false positives?—Nothing is enforced before it is measured on your traffic.
    Built by operators

    Made by the people who keep IFS running.

    iWaf comes from DBO — a database and IFS operations company whose engineers look after large Oracle and IFS production estates every day. We built the control we kept wishing our customers had.

    2004operating since
    120+customers served
    500+environments managed
    24/7operations
    FAQ

    Questions we get asked.

    Does iWaf change anything inside IFS?

    No. Not a line of IFS code, not a table, not a permission. iWaf installs and uninstalls with a single command and leaves no trace in IFS.

    Will it slow IFS down?

    In listening and measuring modes, recording is asynchronous and IFS traffic never waits for iWaf. If recording ever falls behind, a record is dropped — the user’s request is not.

    What happens if iWaf itself has a problem?

    While listening and measuring, IFS doesn’t depend on iWaf at all. How enforcing rules behave in a failure is agreed with you, rule by rule, as part of the documented rule set.

    Can it really tell an AI agent from a person?

    Yes. It combines non-browser client signatures, request pacing that isn’t human, integration credentials used on human-facing screens and abnormal single-pass volumes. The result is recorded — “user-A” versus “an agent acting for user-A” — and agent access can be limited to defined screens and volumes.

    Does it replace our firewall or WAF?

    It complements them. Perimeter firewalls, encryption in transit and authentication stay where they are. iWaf covers what they can’t see: which IFS screen, which person, from where, when and how much.

    Which IFS versions does it support?

    iWaf is built for IFS Cloud and has been measured on live IFS Cloud 24R2 environments. Talk to us about your version and landscape.

    Who writes and maintains the rules?

    We define them with you, based on your exposure requirements and internal policy. DBO operates and maintains the rule set; every change goes through change management and is recorded with what, when, by whom and why.

    Where does our audit data live?

    On-prem, it never leaves your network. As SaaS, it is operated by DBO. Both models run the same engine and console, and you can move between them without reinstalling.

    Get started

    See it on your own traffic.

    Installation doesn’t touch IFS and is reversed with one command. By the end of the first day you’ll have your own users’ actions on your own screens — and a shadow rule report. Moving to enforcement is your decision.

    Emailinfo@dbo.com.tr
    Phone+90 216 545 96 96
    OfficeKoşuyolu, Salih Omurtak Sk. No:78
    Kadıköy, İstanbul