Hi everyone,

is it possible to have SSO (ADFS OIDC) for ICCSAP with FNCM Standalone in Kubernetes?

SAP Viewer works fine with BasicAuth, but not with SSO.

Hi,

What Idp are you using?

Hi everyone,

is it possible to have SSO (ADFS OIDC) for ICCSAP with FNCM Standalone in Kubernetes?

SAP Viewer works fine with BasicAuth, but not with SSO.

Hi Olivier,

ADFS 2016.

Hi,

What Idp are you using?

Hi everyone,

is it possible to have SSO (ADFS OIDC) for ICCSAP with FNCM Standalone in Kubernetes?

SAP Viewer works fine with BasicAuth, but not with SSO.

Hello Audrey,

Did you see this article from Leonardo, where he explains how to configure SSO via OIDC for FileNet running on Kubernetes with Keycloak?
https://community.ibm.com/community/user/blogs/leonardo-modeo/2023/07/17/a-sample-oidc-sso-fncm-container

Even though his example uses Keycloak as the Identity Provider, the overall approach is the same if we use ADFS (or any other OIDC-compliant IdP). Here is how it translates in our context.

The blog describes a working sample of LTPA/OAuth/OIDC SSO for FileNet Content Manager on containers, with CPE, ICN and GraphQL running on Kubernetes/OpenShift. The IdP is responsible for issuing OIDC tokens, which are then consumed by ICN and GraphQL, while CPE can still be accessed with basic auth for admin tasks.

Key points that apply with ADFS:

• Scope of the configuration:

  • OIDC/OAuth-based SSO for ICN 

  • Basic authentication can still be used for CPE admin (ACCE) against a local or external LDAP.

  • The container pattern remains identical whether the IdP is Keycloak, ADFS, or another OIDC provider.

• On the IdP side (ADFS in our case)

  • Create an OIDC application (client) in ADFS, with:

    • A client ID and client secret.

    • The proper redirect URIs for:

      • ICN

      • CPE (if required)

  • Configure the claims so that the token contains a stable user identifier (typically email or upn) that will map to the user in the LDAP used by FileNet.

• On the Kubernetes / FNCM CR side

  • Create:

    • A secret holding the ADFS client secret.

    • A TLS secret with the ADFS signing certificate, referenced in the FNCM CR under trusted_certificate_list.

  • Configure the open_id_connect_providers section of the FNCM CR with:

    • issuer_identifier (ADFS OIDC issuer URL)

    • authorization_endpoint_url, token_endpoint_url, and optionally discovery_endpoint_url

    • Mapping fields like user_identifier, unique_user_identifier, user_identity_to_create_subject to the chosen claim (e.g. email or upn).

• Authentication flows:

  • ICN: browser-based OIDC flow

    1. User accesses ICN.

    2. ICN redirects to ADFS for authentication.

    3. ADFS authenticates the user (AD, MFA, etc.) and returns an OIDC token.

    4. ICN validates the token and propagates the identity to CPE via LTPA.

Best regards,

Hi Olivier,

ADFS 2016.

Hi,

What Idp are you using?

Hi everyone,

is it possible to have SSO (ADFS OIDC) for ICCSAP with FNCM Standalone in Kubernetes?

SAP Viewer works fine with BasicAuth, but not with SSO.

Yes, I saw that. Have you tried it yourself with ICCSAP?

Hello Audrey,

Did you see this article from Leonardo, where he explains how to configure SSO via OIDC for FileNet running on Kubernetes with Keycloak?
https://community.ibm.com/community/user/blogs/leonardo-modeo/2023/07/17/a-sample-oidc-sso-fncm-container

Even though his example uses Keycloak as the Identity Provider, the overall approach is the same if we use ADFS (or any other OIDC-compliant IdP). Here is how it translates in our context.

The blog describes a working sample of LTPA/OAuth/OIDC SSO for FileNet Content Manager on containers, with CPE, ICN and GraphQL running on Kubernetes/OpenShift. The IdP is responsible for issuing OIDC tokens, which are then consumed by ICN and GraphQL, while CPE can still be accessed with basic auth for admin tasks.

Key points that apply with ADFS:

• Scope of the configuration:

  • OIDC/OAuth-based SSO for ICN 

  • Basic authentication can still be used for CPE admin (ACCE) against a local or external LDAP.

  • The container pattern remains identical whether the IdP is Keycloak, ADFS, or another OIDC provider.

• On the IdP side (ADFS in our case)

  • Create an OIDC application (client) in ADFS, with:

    • A client ID and client secret.

    • The proper redirect URIs for:

      • ICN

      • CPE (if required)

  • Configure the claims so that the token contains a stable user identifier (typically email or upn) that will map to the user in the LDAP used by FileNet.

• On the Kubernetes / FNCM CR side

  • Create:

    • A secret holding the ADFS client secret.

    • A TLS secret with the ADFS signing certificate, referenced in the FNCM CR under trusted_certificate_list.

  • Configure the open_id_connect_providers section of the FNCM CR with:

    • issuer_identifier (ADFS OIDC issuer URL)

    • authorization_endpoint_url, token_endpoint_url, and optionally discovery_endpoint_url

    • Mapping fields like user_identifier, unique_user_identifier, user_identity_to_create_subject to the chosen claim (e.g. email or upn).

• Authentication flows:

  • ICN: browser-based OIDC flow

    1. User accesses ICN.

    2. ICN redirects to ADFS for authentication.

    3. ADFS authenticates the user (AD, MFA, etc.) and returns an OIDC token.

    4. ICN validates the token and propagates the identity to CPE via LTPA.

Best regards,

Hi Olivier,

ADFS 2016.

Hi,

What Idp are you using?

Hi everyone,

is it possible to have SSO (ADFS OIDC) for ICCSAP with FNCM Standalone in Kubernetes?

SAP Viewer works fine with BasicAuth, but not with SSO.