SSO identification on IFS Cloud API

• IFS Cloud's Authentication Setup: IFS uses its Identity and Access Manager (IAM), which is built on Keycloak (an open-source auth server). All API calls must include a Bearer access token issued by IFS IAM—tokens from external providers like Microsoft Azure AD (Entra ID) aren't directly accepted by the API.
• What's Happening Here:
  • They've configured Azure AD as a brokered external IDP in IFS IAM, which enables SSO delegation (IFS IAM hands off login to Azure AD).
  • But they're authenticating directly with Azure AD in the mobile app, getting an Azure-issued token. This token isn't valid for IFS APIs because:
    • IFS IAM/Keycloak doesn't recognize it natively.
    • Features like "token exchange" (swapping an external Azure token for an internal IFS IAM token) are disabled by default in IFS Cloud's Keycloak setup. This is a known limitation in IFS's managed Keycloak instance—it's not easily configurable in SaaS environments, and community discussions confirm it's often unavailable out-of-the-box.
• The Goal: Use Microsoft SSO (Azure AD) as the primary IDP for a seamless login in the mobile app, then query the projections REST API with a token that preserves the end user's identity and permissions (e.g., row-level security in IFS data).

Is There a Way to Achieve This?

Yes, but not by directly using the Azure token or enabling token exchange (which isn't feasible without custom Keycloak tweaks, potentially unsupported in IFS Cloud SaaS). Instead, use the standard OAuth2 Authorization Code Flow with PKCE, where the mobile app authenticates through IFS IAM (which brokers to Azure AD). This gets you an IFS IAM-issued token that's valid for the API, while leveraging Microsoft SSO without a second login prompt.

Recommended Solution: Authorization Code Flow via IFS IAM

1. Register the Mobile App as an IAM Client in IFS:
   • In IFS Solution Manager > Users and Permissions > Identity and Access Manager > IAM Clients.
   • Create a new client:
     • Type: Public (mobile apps are typically public clients; no client secret needed).
     • Client ID: Something like my-mobile-app.
     • Redirect URIs: Add your app's callback URIs (e.g., myapp://oauth/callback for deep linking in mobile).
     • Grant Type: Authorization Code.
     • Scopes: Include openid, profile, and any custom scopes needed for projections access.
     • Enable PKCE (Proof Key for Code Exchange) for security, as it's required for public clients.
   • This client will be used to initiate auth from the app.
2. Implement the Auth Flow in the Mobile App:
   • Use a library like AppAuth (for iOS/Android) or a similar OAuth2 client to handle the flow.
   • Step 1: Redirect to IFS IAM Authorization Endpoint (not directly to Azure):
     • Endpoint: https://<your-ifs-instance>/auth/realms/ifs/protocol/openid-connect/auth (replace <your-ifs-instance> with your IFS Cloud URL; find exact endpoints in IFS docs or API Explorer).
     • Parameters:
       • client_id: Your IAM client ID (e.g., my-mobile-app).
       • response_type: code.
       • scope: openid profile offline_access (add offline_access if you need refresh tokens for long sessions).
       • redirect_uri: Your app's callback URI.
       • code_challenge: PKCE challenge (generated by the app).
       • code_challenge_method: S256.
       • identity_provider: The alias of your Azure AD IDP (e.g., azure-ad) to force brokering to Microsoft SSO.
     • This redirects the user to Azure AD for login (via browser or in-app web view). After successful SSO, Azure sends the user back to IFS IAM.
   • Step 2: IFS IAM Issues an Authorization Code:
     • The app receives the code via the redirect URI.
   • Step 3: Exchange Code for Tokens:
     • POST to IFS IAM Token Endpoint: https://<your-ifs-instance>/auth/realms/ifs/protocol/openid-connect/token.
     • Body (form-urlencoded):
       • grant_type: authorization_code.
       • code: The auth code.
       • redirect_uri: Same as above.
       • client_id: Your client ID.
       • code_verifier: PKCE verifier (matches the challenge).
     • Response: JSON with access_token, id_token, refresh_token, etc. The access_token is issued by IFS IAM and tied to the end user's identity/permissions.
3. Call the Projections REST API:
   • Use the access_token in the Authorization header: Bearer <access_token>.
   • Example: GET https://<your-ifs-instance>/main/ifsapplications/projection/v1/SomeProjection.svc/Entities.
   • This maintains end-user permissions because the token is issued on behalf of the authenticated user (from Azure SSO).
   • Handle token refresh using the refresh_token if sessions are long-lived.

Why This Works and Alternatives Don't

• Seamless SSO: No second login—the brokering handles it.
• Security: PKCE prevents code interception; user permissions are enforced via IFS IAM.
• Why Not Direct Azure Token? IFS APIs only trust IAM-issued tokens. Direct Azure auth bypasses IAM, so no valid token for APIs.
• Token Exchange? It's a Keycloak feature for swapping tokens, but in IFS Cloud, it's disabled/not exposed (per community threads and docs). Enabling it requires server-side config (e.g., --features=token-exchange on Keycloak startup), which isn't user-accessible in IFS SaaS. If this is an on-prem IFS setup, you could explore it, but it's preview-only and not recommended for production.
• Other Alternatives:
  • Client Credentials Flow: For service-to-service (no user context), create a confidential IAM client and use its credentials to get a token. But this won't maintain end-user permissions—it's for a service account.
  • Resource Owner Password Flow: Involves sending username/password directly (insecure for mobile; doesn't support external IDPs like Azure).
  • API Proxy: If SSO must be fully external, build a custom proxy (e.g., in Azure APIM) that handles token exchange on your side, but this adds complexity and may violate IFS terms.
• Potential Gotchas:
  • Ensure user accounts are synced/mapped between Azure AD and IFS (e.g., via email or custom attributes in IDP config).
  • Test in a dev environment—IFS Cloud versions (e.g., 23R2+) have slight IAM tweaks.
  • If the app is web-based (not mobile), use implicit flow or similar, but mobile prefers code+PKCE.