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 the foundation of UI-level security. A presentation object was a server-side definition of a form or screen, and access to it was binary: you either had permission to view it, or you didn't. Update and delete rights existed, but they were coarse—you granted or denied broad access to the entire screen's data operations.

This approach had limitations:

• One-size-fits-all access: If you granted a user access to the Supplier form, they saw everything the form exposed.
• Limited action control: You couldn't easily allow a user to read supplier data but block create or update operations.
• 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 actions (Create, Read, Update, Delete, and custom methods)
3. Acts as a security checkpoint between the user and the underlying database

Projections are fundamentally more granular. Instead of a binary "access or no access" model, projections support:

• Four access levels: None, Read-Only, Custom, and Full
• Entity action grants: Restrict Create, Update, or Delete for specific entities within a projection
• Projection action grants: Control whether users can invoke custom actions
• Data access control (ACLs): Further restrict data based on business criteria

Key difference: With projections, a user can have Read-Only access to a projection but Full access to create records in a specific entity within it. This level of control is impossible in the old presentation object model.

---

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 user cannot access the projection. It doesn't appear in the navigator; pages using that projection are hidden.

2. Read-Only

The user can read all data sources and invoke all functions (custom actions) of the projection, but cannot Create, Update, or Delete any data. This is useful for auditors, viewers, and report-only roles.

3. Full

The user has complete access: Create, Update, Delete, and all custom actions on all entities within the projection. This is rarely appropriate outside of admin or power-user roles.

4. Custom

This is where surgical security lives. The user has access to the projection, but specific entity actions (Create, Update, Delete) or projection actions are individually granted or denied. You might grant Read and Create, but deny Update and Delete. Or allow a custom action but block deletes.

When you modify action grants, the access level automatically becomes Custom—IFS Cloud tracks which operations are allowed.

---

Part 3: The Anatomy of Projection Grants

Entity Actions

Entity actions are CRUD operations (Create, Read, Update, Delete) performed on the data entities within a projection. Each entity in a projection has four potential actions:

• Create: Insert new records
• Read: Retrieve and view records
• Update: Modify existing records
• Delete: Remove records

By default, when you grant Full access to a projection, all entity actions are permitted. With Custom access, you can restrict these individually.

Example: A user might have:

• Read + Create on the Supplier entity (can view suppliers and add new ones)
• Read-Only on the Address entity (can view but not modify addresses)
• No access to the Supplier.ContactMethod entity (cannot see contact details)

Projection Actions

Projection actions are custom methods exposed by the projection—PL/SQL routines or Java implementations that perform business logic. These might be:

• Bulk operations (approve multiple orders)
• Workflow state changes (submit for approval)
• Custom calculations or exports
• Integration calls

Unlike entity CRUD operations, projection actions are explicitly named and managed. You grant or deny access to each one individually.

Example: A Purchase Order projection might expose:

• Action: "SubmitForApproval" → Granted to department heads
• Action: "ApproveOrder" → Granted to finance managers only
• Action: "CancelOrder" → Denied to all but procurement admin

Data Access Control (ACL)

For advanced scenarios, Access Control Lists (ACLs) can further restrict data based on business context. An ACL might say: "This user can only see records where the company code matches their assigned company."

ACLs apply at the entity level and operate independently of projection grants, providing a second layer of security.

---

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 Actions: Read, Create on POHeaders
│   ├── Entity Actions: Read, Create on POLines
│   ├── Entity Actions: Read-Only on Suppliers
│   └── Projection Actions: SubmitForApproval (Granted), CancelOrder (Denied)
├── 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)
│   ├── Read, Create, Update on Invoices
│   └── Projection Actions: SubmitInvoice

Approver Role:
├── InvoiceApproval (Custom)
│   ├── Read on Invoices
│   └── Projection Actions: ApproveInvoice, RejectInvoice
├── PaymentProcessing (Custom)
│   ├── Read, Create on Payments
│   └── 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) → Read, Create, Update
├── Expenses (Custom) → Read, Create

ManagerRole (grants ContributorRole + additional)
├── Grants: ContributorRole
├── TimeSheets (Custom) → Read, Update (with approval)
├── Expenses (Custom) → Read, Approve, Reject
└── TeamReporting (Full)

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

Pattern 4: Project or Region-Based Isolation

For multi-environment or multi-region scenarios, use ACLs combined with projection grants:

• Grant the projection broadly (e.g., All projects can be viewed)
• Restrict data via ACL (e.g., "Only show records where Project = user's assigned project")

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

In IFS Cloud, navigate to Solution Manager > Security > Permission Sets:

1. Select or create a permission set
2. Go to Projections and Lobby Pages
3. Select projections and choose:
   • Grant Read Only → All projections get Read-Only access
   • Grant Full → All projections get Full access
   • Manage Projection Grants → Customize access per projection

Customizing Individual Projections

For each projection, you can:

1. Manage Grants by Command: Select client commands (UI buttons) and adjust their underlying action access. IFS Cloud maps commands to the actions they invoke.

2. Manage Entity Action Grants: Open a sub-menu to set access (Granted/Not Granted) for Create, Read, Update, and Delete on each entity.

3. Manage Projection Action Grants: Open a sub-menu to grant or deny custom actions exposed by the projection.

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 override Custom settings.

---

Part 6: Why Projections Are More Secure Than Presentation Objects

Granularity

Presentation objects were form-level. Projections are action-level. You can allow reading data without allowing creation, or block a single custom workflow without hiding the entire screen.

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

Projections are audited at the action level. You can see exactly which users invoked which actions and when, not just "user accessed form X."

Business Logic Integration

Projections embed business logic (validations, custom actions, data transformations). This means security decisions can be context-aware. An ACL can check "is this user's company code in the allowed list?" directly in the projection.

Easier Migration Path

IFS Cloud has tools to map Presentation Objects to Projections during migration, helping you transition systematically rather than a big-bang cutover.

---

Part 7: Security Anti-Patterns and Pitfalls

Anti-Pattern 1: Overprivileging for Convenience

Don't: Grant Full access to a projection because one user needs to create records. Instead, customize the projection to allow only the necessary actions.

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

Fix: Use Custom access and grant only Create and Read. Deny Delete and Update.

Anti-Pattern 2: Ignoring Projection Actions

Don't: Grant Read-Only access and assume users can't do anything harmful.

Why: Read-Only doesn't block custom actions. A user might invoke a "BulkApprove" action even with Read-Only entity access.

Fix: Explicitly deny dangerous projection actions. Use the Manage Projection Grants interface to block actions like Delete, Approve, or state-change operations.

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 access to the projection UI, not the underlying data. A user granted full access to the Supplier projection can see all suppliers, even competitors'.

Fix: Layer ACLs on top. Restrict data with row-level or company-level filters.

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: Audit permissions quarterly. Remove orphaned grants. Document SoD controls and verify they still hold.

---

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
• No finance user with IT admin access
• 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 ACLs to restrict personal data to authorized roles
• Audit access logs regularly

ISO 27001 and Access Control

ISO 27001 Annex A.6 requires documented access controls. 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

IFS provides documentation mapping legacy presentation objects to modern projections. Not all PO functionality translates 1:1; some may require custom solutions.

2. Rebuild Permission Sets

You cannot simply import IEE permission sets. Rebuild them, using IFS Cloud's more granular model as an opportunity to tighten security.

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

Run IEE and IFS Cloud in parallel if possible, syncing permissions until you're confident in the new setup.

---

Part 10: Key Takeaways and Best Practices

1. Projections are granular, not binary: Unlike presentation objects, you can control Create, Update, Delete, and custom actions independently.

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

3. Entity actions are the CRUD layer: Manage Create, Read, Update, Delete granularly per entity within a projection.

4. Projection actions are business logic: Custom actions require explicit grants; don't assume Read-Only blocks them.

5. Use ACLs for data context: Combine projection grants with Data Access Control Lists to enforce company-level, project-level, or user-level data restrictions.

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." Audit quarterly, document your SoD controls, and adjust as roles evolve.

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's a layered access model where you control reads, writes, and custom actions independently. Combine that with Data Access Control Lists, build role-based permission sets, and you have an enterprise-grade security architecture that balances 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 Technical Documentation: Permission Sets and Projection Grants
• 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