Hi all,

I would love to have your feedback for the following IBM FileNet CPE scenario:

1. Clients call a GraphQL API through an API Gateway / API Management layer. The Gateway validates incoming OIDC access tokens against two distinct IdPs:

   1. Microsoft Entra ID (Azure AD)

   2. Salesforce

2. After validation, the Gateway forwards the request to the GraphQL API and injects the end-user identifier (e.g., Employee ID) as a header/metadata.

3. The GraphQL API then calls IBM FileNet Content Platform Engine (CPE) using a technical service account to execute operations.

The requirements would be as follow:

1. FileNet ACLs must be evaluated as if the call was executed by the end-user (not the service account).

2. FileNet audit/traceability must reflect the end-user (or at least provide a reliable correlation between FileNet audit events and the end-user identity).

So the question is, if CPE is accessed with a service account, is there any supported way for CPE to enforce ACLs based on the end-user identity provided as a header or metadata? 

Thanks in advance for any insights.

Olivier,

we had this requirement every now and then (especially when customers thought they could reduce the licensed user amount by using a service user) over the last two decades and always gave up on it. It just wasn't possible with the technology then, especially with all possible access paths.

Remember authentication is done in the application server with container managed security ( I assume WAS), so MAYBE (and I'm a complete WAS illiterate) it is possible to write a WAS authentication plugin that extracts the user from the header and passes this user to the CPE, but I'm totally speculating here, no serious advice.

But IF this works your requirements would be fulfilled.

Sorry to have no better advice,

Gerold

Hi all,

I would love to have your feedback for the following IBM FileNet CPE scenario:

1. Clients call a GraphQL API through an API Gateway / API Management layer. The Gateway validates incoming OIDC access tokens against two distinct IdPs:

   1. Microsoft Entra ID (Azure AD)

   2. Salesforce

2. After validation, the Gateway forwards the request to the GraphQL API and injects the end-user identifier (e.g., Employee ID) as a header/metadata.

3. The GraphQL API then calls IBM FileNet Content Platform Engine (CPE) using a technical service account to execute operations.

The requirements would be as follow:

1. FileNet ACLs must be evaluated as if the call was executed by the end-user (not the service account).

2. FileNet audit/traceability must reflect the end-user (or at least provide a reliable correlation between FileNet audit events and the end-user identity).

So the question is, if CPE is accessed with a service account, is there any supported way for CPE to enforce ACLs based on the end-user identity provided as a header or metadata? 

Thanks in advance for any insights.

Olivier,

we had this requirement every now and then (especially when customers thought they could reduce the licensed user amount by using a service user) over the last two decades and always gave up on it. It just wasn't possible with the technology then, especially with all possible access paths.

Remember authentication is done in the application server with container managed security ( I assume WAS), so MAYBE (and I'm a complete WAS illiterate) it is possible to write a WAS authentication plugin that extracts the user from the header and passes this user to the CPE, but I'm totally speculating here, no serious advice.

But IF this works your requirements would be fulfilled.

Sorry to have no better advice,

Gerold

------------------------------
Gerold Krommer
Managing Director
The Document Content Profesionals, G.m.bH
Wien
+436602408515

Original Message:
Sent: Fri January 02, 2026 07:30 AM
From: Olivier Baltus
Subject: FileNet CPE: End-user ACL + audit traceability when API Gateway validates multi-IdP OIDC tokens and backend uses a service account

Hi all,

I would love to have your feedback for the following IBM FileNet CPE scenario:

1. Clients call a GraphQL API through an API Gateway / API Management layer. The Gateway validates incoming OIDC access tokens against two distinct IdPs:

   1. Microsoft Entra ID (Azure AD)

   2. Salesforce

2. After validation, the Gateway forwards the request to the GraphQL API and injects the end-user identifier (e.g., Employee ID) as a header/metadata.

3. The GraphQL API then calls IBM FileNet Content Platform Engine (CPE) using a technical service account to execute operations.

The requirements would be as follow:

1. FileNet ACLs must be evaluated as if the call was executed by the end-user (not the service account).

2. FileNet audit/traceability must reflect the end-user (or at least provide a reliable correlation between FileNet audit events and the end-user identity).

So the question is, if CPE is accessed with a service account, is there any supported way for CPE to enforce ACLs based on the end-user identity provided as a header or metadata? 

Thanks in advance for any insights.

------------------------------
Olivier Baltus
NSI Luxembourg
------------------------------

Merci Gerold, that matches what we suspected.

To be clear, our goal here is not to bypass licensing by using a service user; the customer requirement is mainly about end-user ACL evaluation and end-user auditability/traceability across the different access paths (ICN, APIs, custom GraphQL, etc.). Using a service account is only being discussed as an architectural shortcut, but we understand it likely breaks the security model.

Your point about container-managed security in WAS is also important: even if one could technically extract a user from a header and "impersonate" it, it would be fragile and hard to make consistent for all access paths and likely not something IBM would support without a documented mechanism.

The alternative is to introduce a broker like Keycloak so CPE trusts one issuer, while Keycloak handles multi-IdP federation, and use SCIM for groups. 

However, in that alternative, there is an additional concern: Keycloak does not provide SCIM as a built-in server capability in the standard distribution, so enabling SCIM typically requires an external SCIM plugin (https://scim-for-keycloak.de/). But there is an issue with this approach as this plugin is maintained by a single individual, which raises a continuity risk for the customer. The customer also challenges why this approach is being presented as "recommended", since it relies on a non-IBM, non-Red Hat component that is not part of the core product.

------------------------------
Olivier Baltus
NSI Luxembourg

Original Message:
Sent: Mon January 05, 2026 09:49 AM
From: Gerold Krommer
Subject: FileNet CPE: End-user ACL + audit traceability when API Gateway validates multi-IdP OIDC tokens and backend uses a service account

Olivier,

we had this requirement every now and then (especially when customers thought they could reduce the licensed user amount by using a service user) over the last two decades and always gave up on it. It just wasn't possible with the technology then, especially with all possible access paths.

Remember authentication is done in the application server with container managed security ( I assume WAS), so MAYBE (and I'm a complete WAS illiterate) it is possible to write a WAS authentication plugin that extracts the user from the header and passes this user to the CPE, but I'm totally speculating here, no serious advice.

But IF this works your requirements would be fulfilled.

Sorry to have no better advice,

Gerold

------------------------------
Gerold Krommer
Managing Director
The Document Content Profesionals, G.m.bH
Wien
+436602408515

Original Message:
Sent: Fri January 02, 2026 07:30 AM
From: Olivier Baltus
Subject: FileNet CPE: End-user ACL + audit traceability when API Gateway validates multi-IdP OIDC tokens and backend uses a service account

Hi all,

I would love to have your feedback for the following IBM FileNet CPE scenario:

1. Clients call a GraphQL API through an API Gateway / API Management layer. The Gateway validates incoming OIDC access tokens against two distinct IdPs:

   1. Microsoft Entra ID (Azure AD)

   2. Salesforce

2. After validation, the Gateway forwards the request to the GraphQL API and injects the end-user identifier (e.g., Employee ID) as a header/metadata.

3. The GraphQL API then calls IBM FileNet Content Platform Engine (CPE) using a technical service account to execute operations.

The requirements would be as follow:

1. FileNet ACLs must be evaluated as if the call was executed by the end-user (not the service account).

2. FileNet audit/traceability must reflect the end-user (or at least provide a reliable correlation between FileNet audit events and the end-user identity).

So the question is, if CPE is accessed with a service account, is there any supported way for CPE to enforce ACLs based on the end-user identity provided as a header or metadata? 

Thanks in advance for any insights.

------------------------------
Olivier Baltus
NSI Luxembourg
------------------------------

Regarding Keycloak, there is now an official SCIM server extension.  Just search for it in the Keycloak extensions page here: https://www.keycloak.org/extensions

Here's the direct link: https://github.com/Metatavu/keycloak-scim-server

------------------------------
ROGER Bacalzo

Original Message:
Sent: Tue January 06, 2026 02:07 AM
From: Olivier Baltus
Subject: FileNet CPE: End-user ACL + audit traceability when API Gateway validates multi-IdP OIDC tokens and backend uses a service account

Merci Gerold, that matches what we suspected.

To be clear, our goal here is not to bypass licensing by using a service user; the customer requirement is mainly about end-user ACL evaluation and end-user auditability/traceability across the different access paths (ICN, APIs, custom GraphQL, etc.). Using a service account is only being discussed as an architectural shortcut, but we understand it likely breaks the security model.

Your point about container-managed security in WAS is also important: even if one could technically extract a user from a header and "impersonate" it, it would be fragile and hard to make consistent for all access paths and likely not something IBM would support without a documented mechanism.

The alternative is to introduce a broker like Keycloak so CPE trusts one issuer, while Keycloak handles multi-IdP federation, and use SCIM for groups. 

However, in that alternative, there is an additional concern: Keycloak does not provide SCIM as a built-in server capability in the standard distribution, so enabling SCIM typically requires an external SCIM plugin (https://scim-for-keycloak.de/). But there is an issue with this approach as this plugin is maintained by a single individual, which raises a continuity risk for the customer. The customer also challenges why this approach is being presented as "recommended", since it relies on a non-IBM, non-Red Hat component that is not part of the core product.

------------------------------
Olivier Baltus
NSI Luxembourg

Original Message:
Sent: Mon January 05, 2026 09:49 AM
From: Gerold Krommer
Subject: FileNet CPE: End-user ACL + audit traceability when API Gateway validates multi-IdP OIDC tokens and backend uses a service account

Olivier,

we had this requirement every now and then (especially when customers thought they could reduce the licensed user amount by using a service user) over the last two decades and always gave up on it. It just wasn't possible with the technology then, especially with all possible access paths.

Remember authentication is done in the application server with container managed security ( I assume WAS), so MAYBE (and I'm a complete WAS illiterate) it is possible to write a WAS authentication plugin that extracts the user from the header and passes this user to the CPE, but I'm totally speculating here, no serious advice.

But IF this works your requirements would be fulfilled.

Sorry to have no better advice,

Gerold

------------------------------
Gerold Krommer
Managing Director
The Document Content Profesionals, G.m.bH
Wien
+436602408515

Original Message:
Sent: Fri January 02, 2026 07:30 AM
From: Olivier Baltus
Subject: FileNet CPE: End-user ACL + audit traceability when API Gateway validates multi-IdP OIDC tokens and backend uses a service account

Hi all,

I would love to have your feedback for the following IBM FileNet CPE scenario:

1. Clients call a GraphQL API through an API Gateway / API Management layer. The Gateway validates incoming OIDC access tokens against two distinct IdPs:

   1. Microsoft Entra ID (Azure AD)

   2. Salesforce

2. After validation, the Gateway forwards the request to the GraphQL API and injects the end-user identifier (e.g., Employee ID) as a header/metadata.

3. The GraphQL API then calls IBM FileNet Content Platform Engine (CPE) using a technical service account to execute operations.

The requirements would be as follow:

1. FileNet ACLs must be evaluated as if the call was executed by the end-user (not the service account).

2. FileNet audit/traceability must reflect the end-user (or at least provide a reliable correlation between FileNet audit events and the end-user identity).

So the question is, if CPE is accessed with a service account, is there any supported way for CPE to enforce ACLs based on the end-user identity provided as a header or metadata? 

Thanks in advance for any insights.

------------------------------
Olivier Baltus
NSI Luxembourg
------------------------------