cancel
Showing results for 
Search instead for 
Did you mean: 

CUA restrictions versus SAP IdM 7.1

Former Member
0 Kudos

We are in the planning phase of implementing SAP Identity Management 7.1.

There are 2 restrictions in the existing SAP Central User Administration (CUA) functionality that, if the restrictions also apply to SAP IdM, will fundamentally affect our rollout strategy for SAP IdM.

1. In CUA once a SAP client becomes a Child of a CUA Master client, user-ids in the Child client are only able to be created via the CUA Master client. Some local user settings can still be maintained in the CUA Child client, but as a general rule, all User master data maintenance must be performed via the CUA Master Client.

QUESTION: Is there a similar parallel with SAP IdM? In other words, once we configure SAP IdM to provision to a particular child SAP client, are there any restrictions imposed by SAP in relation to maintaining user master data directly in the child SAP client? Alternatively, can all user-id creations & user master data maintenance be performed from SAP IdM as well as directly in the child SAP client?

2. In CUA, once a SAP client becomes a Child of a CUA Master client, then it cannot become a child client of another CUA Master client.

QUESTION: Is there a similar parallel with SAP IdM? This question impacts how we provision access to our non-Production SAP systems using SAP IdM (e.g. dev, test, etc). Ideally, we would like to have the capability of connecting 2 SAP IdM systems to selected dev/test systems:

a. A productive SAP IdM system for provisioning access in Dev/Test systems to "real" employees involved in development of our SAP systems.

b. A development SAP IdM system, for configuring/testing our IdM system. This system would also need to provision to Dev/Test systems for the purposes of testing provisioning procedures. In these scenarios, we would probably only provision to a range of test user-ids to avoid affecting the access of "real" Dev/Test system users.

Regards,

Richard Cooper.

Accepted Solutions (1)

Accepted Solutions (1)

Frank_Buchholz
Advisor
Advisor
0 Kudos

IdM does not add any restriction to a target system (in opposite to the CUA).

That means you

- can still manage users locally

- mulipe IdM servers can be connect to the same target system

It's your responibility to avoid any data inconsistencies if you try any of this.

You have to ensure that local changes do not interfere with changes send by IdM. Usually you restrict the authorithations to avoid local changes. You can set up some reconciliation jobs in IdM to catch local changes, too.

Kind regards

Frank

Former Member
0 Kudos

Thanks Frank for your clear & concise answer.

Regards,

Richard Cooper.

Answers (1)

Answers (1)

Former Member
0 Kudos

QUESTION: Is there a similar parallel with SAP IdM? In other words, once we configure SAP IdM to provision to a particular child SAP client, are there any restrictions imposed by SAP in relation to maintaining user master data directly in the child SAP client? Alternatively, can all user-id creations & user master data maintenance be performed from SAP IdM as well as directly in the child SAP client?

Nope, that's what IdM is there for, the provisioning of data into SAP and enterprise systems from an authoritative source (In a SAP oriented system this is usually HCM/ESS/MSS populating the NW IdM Identity Store database. It's perfectly set for all CrUD (Create Update Delete operations)

QUESTION: Is there a similar parallel with SAP IdM? This question impacts how we provision access to our non-Production SAP systems using SAP IdM (e.g. dev, test, etc). Ideally, we would like to have the capability of connecting 2 SAP IdM systems to selected dev/test systems:

Sounds like the way to go, see below.

a. A productive SAP IdM system for provisioning access in Dev/Test systems to "real" employees involved in development of our SAP systems.

b. A development SAP IdM system, for configuring/testing our IdM system. This system would also need to provision to Dev/Test systems for the purposes of testing provisioning procedures. In these scenarios, we would probably only provision to a range of test user-ids to avoid affecting the access of "real" Dev/Test system users.

Best Practice is usually to have one NW IdM setup per environment (one for development, one for production) Given the fact that you are working with passwords, accounts, roles, etc. It's a bad idea to use active production data in Development. Trust me, I've seen bad, bad things happen.

Former Member
0 Kudos

Hi Matthew,

Thank you for your reply.

I have some questions to clarify my understanding.

1. Your answer indicates once you connect IdM to a "child" system/client then all provisioning MUST be via SAP IdM. This is significant for us becasue our user & role assignment is currently performed by different state based teams who are restricted by "user group". I would like to phase the rollout of IdM to each team. However, your answer indicates this will not be possible. All user provisioning to a "child" SAP system MUST swap to IdM at the same time. Have I interpreted your answer correctly?

2. I agree we should have a separate IdM systems for the dev/test systems and another for Production systems. This implies 2 "Productive IdM systems". However, we also want one or 2 IdM systems for DEV/TEST purposes. This is separate to the "productive" system for provisioning "real" users to the SAP dev/test landscape. To support this strategy, then we would need to be able to connect our SAP dev/test systems to 2 IdM systems. One is the "Productive" dev/test IdM system for "real" dev/test users. The second is the DEV/TEST IdM system for testing IDM config/developments. We don't want changes to our IDM system to affect the provisioning process for all our "real" developers/configures. So, technically, can 2 IdM systems connect to the same "child" system?

Regards,

Richard.

Former Member
0 Kudos

1. Your answer indicates once you connect IdM to a "child" system/client then all provisioning MUST be via SAP IdM. This is significant for us becasue our user & role assignment is currently performed by different state based teams who are restricted by "user group". I would like to phase the rollout of IdM to each team. However, your answer indicates this will not be possible. All user provisioning to a "child" SAP system MUST swap to IdM at the same time. Have I interpreted your answer correctly?

Provisioning does not need to be solely from SAP IdM except where I noted about ABAP systems.

2. I agree we should have a separate IdM systems for the dev/test systems and another for Production systems. This implies 2 "Productive IdM systems". However, we also want one or 2 IdM systems for DEV/TEST purposes. This is separate to the "productive" system for provisioning "real" users to the SAP dev/test landscape. To support this strategy, then we would need to be able to connect our SAP dev/test systems to 2 IdM systems. One is the "Productive" dev/test IdM system for "real" dev/test users. The second is the DEV/TEST IdM system for testing IDM config/developments. We don't want changes to our IDM system to affect the provisioning process for all our "real" developers/configures. So, technically, can 2 IdM systems connect to the same "child" system?

Not sure what you're looking to do here. You can use any number of IdM systems you wish. There's no real need for multiple IdM installs per environment save for High Availability.