Two instances of SAP concur post merger

[abhijitswo]

Hello folks,

We have a situation where we have two companies merging and both of them have their own instances of SAP Concur which are federated with Azure AD. We tried modifying the SAML endpoints but it does not seems to have done the job, the users from company A are migrated to company B and their emails have been updated , we wanted to keep the two instances till the merger is formally complete. 

We plan to have SAP IAS in between now to override any confusion. Can someone guide us, how to achieve this ?

[PoojaKumatkar · Accepted solution]

Hi @abhijitswo ,

Regarding your 1st issue:

Please note that, In SAP Concur, each employee’s login ID (typically the email address) must be globally unique across all Concur instances. 

Right now what is happening:

Two SAP Concur Instances (Company A & B)

• Both federated with Microsoft Entra ID
• Users migrated → emails changed → identities overlap

The core issue:

SAML relies heavily on unique identifiers (usually NameID/email).

After migration:

• Same user now exists in a new instance
• But Concur instances + Azure AD still have conflicting identity mappings

Result: Wrong routing / failed authentication / user mismatch

Based on your issue description, it appears that the same login ID/email address is being used in both Company A and Company B, which may be causing the conflict and resulting in the issue.

For testing purposes, could you please try the following approach and verify whether it works for Company B?

Note - Assume here, we have migrated company A employee into company B and going forward user will not login to company A Concur instance. 

• In company A Concur instance - Update login id/email address of test user as below. 
• Example. 
• Original Valid Email:  pooja.kumatkar@domain.com
• Updated Email: pooja.kumatkar@test.com

• In company B Concur instance - Keep login id/email address as original valid email.
• Example.
• Original Valid Email:  pooja.kumatkar@domain.com

Now test the connection with company B Concur instance. This time user should be able to login with SSO in company B. 

Note - With the above change, we are attempting to make the Login ID/Email address unique across both Concur instances. However, after this change, users may not be able to log in to Company A, as the updated Login ID/Email might not be maintained or synchronized in the IdP system.

Regarding your 2nd Q:

This is not my core area of expertise; however, I did some research and found the information below. You may review and validate whether it is feasible in your scenario. I am also sharing the standard SAP Concur documentation for your reference.

https://help.sap.com/docs/SAP_CONCUR/8b1fb4bc53c843c080bcfc4b965366a1/39a497e06d184d89b93bff91d5fb8f...

Why SAP IAS is the right move

SAP Identity Authentication Service can act as a:

• Proxy IdP (identity broker)
• Routing layer
• Identity transformer

Instead of:

Azure AD → Concur A / Concur B

You move to:

Azure AD → IAS → Concur A / Concur B

Recommended Architecture
1. Set IAS as the central IdP for both Concur tenants

• Configure both Concur A & B to trust IAS (not Azure AD directly)

2. Configure Azure AD as upstream IdP in IAS

In IAS:

• Add Microsoft Entra ID as a corporate IdP
• Use SAML or OpenID Connect

3. Implement routing logic in IAS

This is the key step.

Use IAS features like:

• Conditional Authentication
• Identity Provider routing rules
• Application-specific mappings

Example routing strategies:

• Based on email domain:

@companya.com → Concur A
@companyb.com → Concur B

Based on user attribute:

companyCode = A → Concur A
companyCode = B → Concur B

• Based on group membership from Azure AD

5. Transform the NameID (VERY IMPORTANT)

Avoid collisions by making NameID unique per tenant.

Example:

Instead of:

user@company.com

Use:

user@company.com#A → Concur A
user@company.com#B → Concur B

IAS allows:

• Assertion attribute mapping
• NameID transformation rules

5. Maintain dual identities temporarily

In IAS:

Same user can map to:

• Concur A identity
• Concur B identity

This avoids breaking historical data access.

6. Update Concur configuration

For both tenants:

• Change IdP → IAS metadata
• Ensure:
  • Entity ID is unique per tenant
  • ACS URLs are correct
  • NameID format matches IAS output

Suggested phased rollout
Phase 1: Parallel federation

• Keep Azure AD → IAS → Concur A
• Keep Azure AD → IAS → Concur B

Phase 2: Pilot group

• Route a small user set via IAS rules
• Validate:
  • Login success
  • Correct tenant routing
  • No duplication

Phase 3: Full cutover

• Disable direct federation
• Enforce IAS for all users

Pro tip (important for mergers)

Introduce a Global Unique Identifier (GUID strategy):

• Store in Azure AD (extension attribute)
• Pass via IAS
• Use as:
  • NameID
  • Or secondary identifier in Concur

This prevents future conflicts during full merge.

Hope this helps or lead you to the solution. 🙂

If this answers your query, then please mark solution as accepted