Application Changes¶

This section outlines the essential steps and changes required for application builders to migrate applications from IH IAM to Xcelerator IAM. The focus is on refactoring applications to ensure seamless integration with Xcelerator IAM.

Overall Implementation Process for Application Builders¶

The Migration Assistant helps track application readiness and tenant migration status in one place. For more information, refer to Migration Approach.

Changes in Application¶

The following points summarize the application-level changes required to support migration from IH IAM to Xcelerator IAM.

1. Dual Token Awareness
2. Data Access Changes - Token Manager/Technical User
3. SDK for Data Services
4. Subtenancy Impact
5. Tenant Mapping Layer (Optional)

Dual Token Awareness¶

Applications must handle tokens from both IH gateway and the Xcelerator gateway. Token formats differ, and applications need to correctly identify and process each type. The tenant ID claim varies between token types.

Data Access Changes: Token Manager/Technical User¶

The process for applications to access tenant data using Technical Token Manager (TTM) credentials remains largely unchanged. Existing IH application credentials continue to be supported.

Technical user credentials need to be recreated through the settings app available at siemens.app.

User impersonation using the email field is not supported in the Xcelerator platform.

SDK for Data Services¶

SDKs are available for Python, Java, and NodeJS at Industrial IoT SDK. A common SDK supports both IH and Xcelerator environments; separate SDKs are not required.

To enable interaction with both environments, identify the issuer (iss) in the token claims. Based on the issuer, initialize the SDK with the corresponding credentials.

Subtenancy Impact¶

Subtenancy continues to be supported, but the implementation has changed. Instead of direct token claims, subtenancy now uses user groups. Users belong to multiple groups, and relevant groups have access to subtenants.

IH IAM used to provide the subtenant information in the JWT token:

`"cat": "user-token:v1",`
`"subtenant": "subtenant12345"`

{
  "user_groups": [
    "companyAdmin",
    "TestEngineer",
    "mdspiam:subtenant:subtenant12345"
  ]
}

Applications are expected to iterate over the list of user_groups, identify a user group that starts with the prefix mdspiam:subtenant:, and extract the subtenant ID from the pattern mdspiam:subtenant:<subtenant-id>.

The existing subtenant information (associated group details) is migrated from IH IAM to Xcelerator IAM. For subtenants created after Xcelerator IAM adoption, the same subtenant identification logic applies.

The subtenant impersonation capability described in Developing Subtenancy-Aware Applications is not supported in Xcelerator IAM; APIs providing this behavior will be deprecated. Application teams using subtenant impersonation are expected to adapt their business logic to regular tenant impersonation and apply resource-level control in the application layer.

Tenant Mapping Layer (Optional)¶

A tenant mapping layer is required only if your application:

• Stores tenant IDs in the database.
• Chooses tenant ID mapping instead of in-place replacement.

The tenant mapping layer bridges IH tenant IDs and Xcelerator tenant IDs. The workflow is:

1. Identify the IAM provider from the token
2. Extract the tenant ID
3. Use the mapping to resolve the corresponding tenant ID in your application database

IH tenant identifiers are 8-character strings (For example, triadiot). Xcelerator tenant IDs are 10-digit numbers (For example, 1234567890). The recommended approach is to maintain a mapping table rather than replacing stored IDs, enabling safe rollback at any point.

No further action is required at this time beyond the steps outlined above. We appreciate your continued partnership and trust.

Except where otherwise noted, content on this site is licensed under the Development License Agreement.