IFS Projection Security: Locking Down What You Expose

Introduction

IFS Cloud has fundamentally changed how enterprise security works compared to the legacy IEE (IFS Enterprise Explorer) model. Where Enterprise Explorer relied on presentation objects for access control, IFS Cloud uses a more granular, projection-based security architecture. This shift matters—a lot.

If you're migrating from IEE to Aurena (IFS Cloud's web interface) or building permission sets in a new IFS Cloud environment, you need to understand projections and how to lock them down. Misconfigured projections expose sensitive data, allow unauthorized actions, and create audit nightmares. Get it right, and you have surgical control over who can do what.

This guide walks through IFS Cloud's projection security model, the permission set structure that governs it, and practical design patterns that enforce the principle of least privilege—without choking your users.

---

Part 1: What Changed—IEE to Aurena Security Model

The Old Way: Presentation Objects in Enterprise Explorer

Enterprise Explorer used presentation objects as a foundation of UI-level security. Presentation objects grouped the form with database methods and related objects, and could carry more than a simple view/no-view grant. The model was nevertheless organised around the legacy client rather than a projection service contract, so operation-level analysis was different and often coarser.

This approach had limitations:

• Client-oriented grouping: A form's presentation object could pull together a broad set of methods and related objects.
• Different operation model: Read/write behaviour was granted through presentation objects/database methods rather than Cloud projection entity/action grants.
• No entity-level granularity: Restricting specific fields or sub-objects was difficult without custom code.

The New Way: Projections in Aurena (IFS Cloud)

Aurena (the IFS Cloud web interface) replaced presentation objects with projections. A projection is a business-logic layer that:

1. Exposes data sources (entities and query objects) to the UI
2. Defines available entity operations and named functions/actions
3. Acts as a security checkpoint between the user and the underlying database

Projections provide a different, often finer-grained operation model. Instead of a binary "access or no access" model, projections support:

• Four access levels: None, Read-Only, Custom, and Full
• Entity data-source grants: Grant query access or the combined Create/Update/Delete (CUD) write capability for specific entities within a projection
• Named action grants: Control entity-bound and projection-level actions separately from entity data access
• Business data-access controls: Company, site, project, Data Access Control, ACL, or domain-specific rules where the entity participates in them

Key difference: Cloud permission sets can be tailored at projection, entity-data-source, and named-action level. In current IFS Cloud metadata the ordinary entity write grant is CUD as a bundle, not three independent Create, Update, and Delete switches. Inspect the target release and the user's effective grants rather than reasoning only from a page button.

---

Part 2: Permission Sets and Projection Access Levels

What Is a Permission Set?

A permission set is a collection of access grants assigned to objects and privileges that define what a user can and cannot do in IFS Cloud. Permission sets control access to:

• Projections (the main UI entry point)
• Reports and Quick Reports
• Lobby pages (dashboards)
• Workflows and Database Tasks
• Task Chains
• System Privileges (administrative functions)

Users are assigned one or more permission sets; a permission set can also grant another permission set, allowing layered, role-based access patterns.

Projection Access Levels: The Four-Level Model

When you grant a projection within a permission set, that projection has one of four access levels:

1. None

The permission set grants no access to the projection. Page/navigator visibility also depends on the applicable client/page grants and release behaviour; do not use visibility alone as the access test.

2. Read-Only

The permission set grants query access to the projection's entities, but not entity CUD or named state-changing actions. Projection functions are read-only by definition; state-changing actions are separate grants and are not added by the Read-Only shortcut.

3. Full

The permission set receives query and CUD access for writable entities plus the projection's named entity and projection actions. An entity modelled as read-only remains read-only. Review named actions and sensitive entities rather than assuming the label is a safe business role; broad access is rarely appropriate outside tightly controlled roles.

4. Custom

This is where surgical security lives. The permission set can grant selected entities as query-only or CUD and grant selected named entity/projection actions. IFS records positive grants: revoking an item removes it from that permission set; it is not an explicit deny that overrides a grant inherited from another permission set.

When the detailed grants are neither the complete Read-Only set nor the complete Full set, the displayed access level becomes Custom.

---

Part 3: The Anatomy of Projection Grants

Entity Data-Source Access and Entity-Bound Actions

For each published entity, projection security distinguishes:

• Query access: Retrieve the entity through the projection
• CUD access: Use the entity's supported Create, Update, and Delete operations as one write grant
• Named entity actions: Invoke state changes or other operations bound to that entity

Full grants all supported access; Read-Only grants query access; Custom can mix query-only entities, CUD-enabled entities, and selected named actions. If a role genuinely needs “create but never update or delete”, do not claim that an entity CUD grant provides it. Use a purpose-built, server-authorised action or another documented business control and test the result.

Example: A user might have:

• Query + CUD on a supplier-maintenance entity
• Query-only access to an address entity
• No grant in this role to the contact-method entity

Projection Actions

Projection actions are named state-changing operations exposed by the projection and implemented through the supported server layer. These might be:

• Bulk operations (approve multiple orders)
• Workflow state changes (submit for approval)
• Exports or operations which create server-side output
• Integration calls

Unlike entity data-source access, projection actions are explicitly named and managed. You grant or revoke each one in the permission set. Always review the user's other permission sets because effective access is additive.

Example: A Purchase Order projection might expose:

• Action: "SubmitForApproval" → Granted to department heads
• Action: "ApproveOrder" → Granted to finance managers only
• Action: "CancelOrder" → Granted only through the procurement-admin role

Data Access Control (ACL)

IFS Cloud includes several business-data access frameworks. Depending on the object and release, this may be company/site access, project access, Data Access Control, an Access Control List capability, or another domain-specific rule. These controls are distinct from the ability to call a projection operation. Identify the framework the target entity actually participates in and test it with an out-of-scope user; there is no generic ACL automatically attached to every projection entity.

An entity query grant is also not general field-level masking. Hiding a field in the page is a user-experience change, not a security boundary. If a role must not receive a sensitive attribute, use a supported server-side data contract or business-data control that actually excludes it, and verify the projection response—not only the page.

---

Part 4: Practical Permission Set Design Patterns

Pattern 1: Role-Based, Least Privilege

Start by mapping real business roles to permission sets. For each role, grant:

• Only projections necessary for that role's job function
• For each projection, the minimum access level (usually Read-Only or Custom)
• For Custom access, enable only the specific entity actions and projection actions needed

Example: Buyer Role

Permission Set: BuyerRole
├── PurchaseOrders (Custom)
│   ├── Entity Access: Query + CUD on POHeaders
│   ├── Entity Access: Query + CUD on POLines
│   ├── Entity Access: Query-only on Suppliers
│   └── Projection Actions: SubmitForApproval (granted); CancelOrder (not granted here)
├── ReceiveGoods (Read-Only)
└── SupplierMaster (Read-Only)

Pattern 2: Enforcing Segregation of Duties (SoD)

One of the highest-value uses of projection security is preventing fraud through segregation of duties. Ensure no single user can:

• Create and approve their own transactions
• Authorize payments they initiated
• Both record and verify data

Example: AP (Accounts Payable) Segregation

Invoicer Role:
├── InvoiceEntry (Custom)
│   ├── Query + CUD on Invoices (where general maintenance is required)
│   └── Projection Actions: SubmitInvoice

Approver Role:
├── InvoiceApproval (Custom)
│   ├── Query-only on Invoices
│   └── Projection Actions: ApproveInvoice, RejectInvoice
├── PaymentProcessing (Custom)
│   ├── Query + CUD on Payments (where general maintenance is required)
│   └── Projection Actions: ProcessPayment

Assign the Invoicer role and Approver role to different users. Now, one person cannot approve their own invoices.

Pattern 3: Tiered Access (Viewer → Contributor → Approver)

Build a permission set hierarchy where each tier inherits and extends the previous:

ViewerRole (Base)
├── ProjectTracking (Read-Only)
├── TimeSheets (Read-Only)
└── Reports (Read-Only)

ContributorRole (grants ViewerRole + additional)
├── Grants: ViewerRole
├── TimeSheets (Custom) → Query + CUD and required named actions
├── Expenses (Custom) → Query + CUD and submission action

ManagerRole (grants ContributorRole + additional)
├── Grants: ContributorRole
├── TimeSheets (Custom) → Query plus approval actions
├── Expenses (Custom) → Query, Approve, Reject
└── TeamReporting (Full)

Each role builds on the previous, reducing duplication and simplifying audits.

Pattern 4: Project or Region-Based Isolation

For project or regional isolation, combine projection grants with the data-access model supported by the target business object:

• Grant the projection broadly (e.g., All projects can be viewed)
• Restrict data through project/company/site/Data Access Control or another documented domain rule

This is especially powerful for field teams or regional managers who should only see their own data.

---

Part 5: Managing Projection Grants in IFS Cloud

The Permission Set User Interface

Open the Permission Sets administration page. Navigation and command labels vary between IFS Cloud releases:

1. Select or create a permission set
2. Go to Projections and Lobby Pages
3. Select projections and choose:
   • Grant Read Only → The selected or currently granted projections receive query-only access, depending on the command used
   • Grant Full → The selected or currently granted projections receive full supported access
   • Manage Projection Grants → Customize access per projection

Customizing Individual Projections

For each projection, you can:

1. Manage Grants by Command: Select client commands and apply the projection grants those commands require. Treat this as a grant-building assistant, then inspect the resulting entity and named-action grants.

2. Manage Entity Access: Set entity query access and, where the model permits writes, the combined CUD capability.

3. Manage Named Action Grants: Grant or revoke entity-bound and projection-level actions exposed by the projection.

The Manage by Page assistant can also identify projections used by selected pages. It is a useful starting point, not proof of least privilege: background actions, integrations, reports, system privileges, and data-access rules still need review.

Global Commands

Two global commands simplify bulk changes:

• Grant Read Only (All): Sets all projections in the permission set to Read-Only
• Grant Full (All): Sets all projections to Full access

Use these cautiously; they replace Custom detail for the affected projections. A user's effective permissions remain the union of every permission set granted directly or indirectly.

---

Part 6: Where Projection Security Adds Granularity

Granularity

Presentation objects were client-oriented groupings. Projections separate entity query/CUD access from named actions. You can allow reading without direct entity writes, or omit a sensitive workflow action without removing every read path.

Scalability

IFS Cloud's projection model scales from small deployments to large managed-cloud and remote-deployment estates. Presentation objects were tied to the legacy monolithic architecture.

Audit Trail

Projection grants make operations identifiable, but IFS does not automatically retain a complete business audit of every read and action invocation merely because it passed through a projection. Configure IFS Audit Trail/security logging and business-history requirements deliberately for the target entity and release.

Business Logic Integration

Projections expose validated business operations rather than database shortcuts. Context-sensitive authority belongs in the supported business/data-access layer behind the projection; there is no universal inline projection ACL expression. Confirm the relevant company/site/project/access framework and enforce any additional customer rule on the server.

Easier Migration Path

IFS migration/permission analysis can help relate legacy presentation objects to Cloud pages/projections in supported upgrade paths. Treat the result as an inventory: changed processes, named actions, system privileges, and data-access rules still require role-owner testing.

---

Part 7: Security Anti-Patterns and Pitfalls

Anti-Pattern 1: Overprivileging for Convenience

Don't: Grant Full access to a projection because one role needs a single workflow action or one writable data source.

Why: A single compromised account with Full access becomes a breach vector for all data in that projection.

Fix: Use Custom access: grant query access, only the necessary named actions, and CUD only on entities that genuinely require direct maintenance. Because CUD is grouped, use a purpose-built action when the requirement is narrower than general write access.

Anti-Pattern 2: Ignoring Projection Actions

Don't: Review only entity access and ignore named actions or grants inherited through another permission set.

Why: The Read-Only shortcut itself does not grant state-changing actions, but a Custom/Full grant elsewhere can make a "BulkApprove" action effective for the same user.

Fix: Review effective access across the permission-set hierarchy and revoke unnecessary action grants from every source role. Remember that a revoke in one permission set does not cancel a grant from another.

Anti-Pattern 3: One Permission Set Per User

Don't: Create a custom permission set for every user, tweaking each individually.

Why: This becomes a maintenance nightmare. One permission set change requires updates to multiple sets.

Fix: Create role-based permission sets (Buyer, Approver, Admin) and assign users to roles. Role changes happen once, not per user.

Anti-Pattern 4: Forgetting Data Access Control

Don't: Rely solely on projection grants if you have multi-company or multi-region data.

Why: Projection grants control which service operations can be called, not which business rows are in scope. Without the applicable data-access control, a broad grant can expose records outside the intended company, site, project, or organisational boundary.

Fix: Apply the standard data-access mechanism used by that business object and test it. Do not invent a projection where clause as a substitute for supported security.

Anti-Pattern 5: Never Reviewing Permissions

Don't: Set up permissions during implementation and forget about them.

Why: Users change roles. Permission sets accumulate legacy grants. Audit requirements shift.

Fix: Review permissions on a risk-based cadence and after role, process, or release changes. Remove orphaned grants, document SoD controls, and verify effective access.

---

Part 8: Aligning with Audit and Compliance

SOX and Financial Controls

If you're under SOX, segregation of duties is non-negotiable. Use projection security to enforce:

• Different users for create vs. approve workflows
• Incompatible finance and privileged-administration access separated according to the customer's SoD policy
• Transaction approval chains built into projection actions

GDPR and Data Minimization

Principle of least privilege (grant only what's needed) aligns perfectly with GDPR's data minimization principle.

• Use Read-Only access for users who only view data
• Use the entity's supported data-access controls to restrict personal data to authorised roles
• Audit access logs regularly

ISO 27001 and Access Control

In ISO/IEC 27001:2022, access control is addressed in Annex A control 5.15 alongside related identity, authentication, and access-right controls. Map the customer's chosen controls and Statement of Applicability rather than treating one IFS setting as certification evidence. Document:

• Each permission set's purpose and assigned roles
• Which projections are granted and at what access level
• SoD controls and how they're enforced
• Quarterly access reviews

---

Part 9: Migration from Enterprise Explorer

If you're moving from IEE to IFS Cloud:

1. Map Presentation Objects to Projections

Use IFS migration/permission analysis supplied for the upgrade path to build a presentation-object-to-page/projection inventory. It is not a guaranteed one-to-one mapping and does not prove every legacy grant should be retained.

2. Rebuild Permission Sets

Do not assume an imported or converted Apps 10 permission set is complete or least-privileged. Reconcile it to Cloud pages, projections, actions, system privileges, reports, tasks, and data-access rules using the supported tooling for the target path.

3. Test Extensively

Set up a test environment. Assign pilot users to custom permission sets and verify they can do their jobs—nothing more, nothing less.

4. Plan for Custom Actions

Custom actions exposed in projections often don't have IEE equivalents. Review projection configurations to understand what custom actions are available and grant accordingly.

5. Plan Parallel Runs

Where the programme has an approved parallel-validation window, compare role outcomes in isolated Apps 10 and Cloud environments. Do not keep two permission stores synchronised indefinitely; establish Cloud role ownership and a controlled cutover.

---

Part 10: Key Takeaways and Best Practices

1. Projections are granular, not binary: Unlike presentation objects, you can separate entity query/CUD access from named actions.

2. Four access levels for flexibility: Use None, Read-Only, Full, and Custom (selective entity and named-action grants) to match your security posture to business needs.

3. Entity writes are bundled: In current IFS Cloud projection grants, query access is separate and Create/Update/Delete are granted together as CUD per writable entity.

4. Named actions are separate: Read-Only does not grant state-changing actions, while Custom and Full access can. Review effective grants from every permission set.

5. Use the entity's supported data-access model: Combine operation grants with applicable company/site, Data Access Control, ACL, or domain-specific rules.

6. Segregation of duties is your best defense against fraud: Separate create from approve, initiate from authorize, and record from verify—enforced via permission sets.

7. Start with least privilege, add as needed: Begin restrictive. Users who lack access will ask for it; you'll have clear business justification to expand it.

8. Document and audit regularly: Permission sets are not "set and forget." Use a risk-based cadence and revalidate after material role, process, or release changes.

9. Role-based permission sets scale: Create permission sets for job functions, not individuals. Assign users to roles; change permissions once, not per user.

10. Test before deploying: Misconfigured permissions expose data or block users. Use a test environment to validate each permission set.

---

Conclusion

IFS Cloud's projection-based security is a significant step forward from the presentation object model. It gives you surgical control over access—allowing you to implement principle of least privilege at scale, enforce segregation of duties, and maintain audit-ready compliance.

The key is thinking at the right level of granularity. A projection is not a simple on/off; it is an operation-grant model that separates query access, an entity's supported CUD capability, and named actions. Combine that with the business object's supported data-access controls and role-based permission sets to balance user productivity with data protection.

Whether you're migrating from IEE, implementing IFS Cloud for the first time, or auditing an existing setup, these patterns and practices will help you lock down what you expose—and sleep better knowing your data is protected.

---

References and Further Reading

• IFS Cloud projection permission documentation
• IFS Cloud segregation-of-duties analysis
• IFS Community Forums: Permission Sets, Apps 10 and IFS Cloud
• IFS Cloud Best Practices: Authentication and Access Control
• NIST Cybersecurity Framework: Access Control Principles
• Principle of Least Privilege (PLoP) in Enterprise Security