CUA Landscape

[Former Member]

Does Position Level Security really work with CUA?

I would like to setup two landscapes for CUA.

One CUA for Test/Sandbox and put it on Solution Manager using User Level Security.

One CUA for Prod/QAS using Position Level Security residing on the ECC 6.0 Dev Box.

I realize the HR ORG Model is needed for Indirect Role Assignments or Position Level Security, so I'm told CUA should reside on the same client as the HR ORG Structure.

Our Tech Lead here wants to use one CUA for all of the clients and put it on Solution Manager.

My question to you folks, how much sense does this make to use one CUA and place it on Solution Manager?

[Former Member]

I have used CUA with HR Indirect role assignment many times and it works a treat. A couple of comments on your post:

a) I don't know why basis consultants are so insistent on putting CUA on sol man. It doesn't make sense when you have HR. But then again, they're basis consultants, not security consultants so they wouldn't know.

b) Having CUA on the ECC dev box also doesn't make sense as the dev box isn't where the HR org is maintained

c) Yes, CUA should reside in the same client as your HR org - typically ECC prod.

You can have CUA on a different box, but it is more complicated, less performy, and takes up more disk space as you have to ALE the HR org structure to the CUA system from the HR system. So, if you have CUA on solman, then sol man will have the HR Org structure ALE'd across to it, which doesn't make sense when you can more easily have CUA on ECC and leave the HR data where it is.

My recommendation (this is how I normally do it), is to have CUA in ECC Prod. Create cross-system composite roles in PFCG. These composite roles contain the single roles from the CUA-child systems. Relate the cross-system composite roles to the position. When the whole employee->position->role->user reconciliation thing happens, they are assigned the composite role and CUA then automatically takes over to provision the user and role assignment out to the appropriate child systems.

This in effect means that there is no user-maintenance required. Only role/position maintenance.

[Former Member]

Justin,

One of the main reason Basis prefer to have Solman as the CUA master client is Solman by default has to have RFC connection setup to all systems & clients.

Thanks,

Lye

[Former Member]

Lye,

I understand that this saves a few hours as there is no need to set up RFCs (if they don't already exist) on the system with HR. It's just that this decision is part of the security architecture, not basis architect and should therefore be decided by a security solution architect, not basis. Putting CUA into solman may save a few hours in the project, but may significantly increase the costs of maintenance post-go live. Also, CUA doesn't necessary connect to all systems and clients in the landscape. The location and integration of CUA into the SAP enviornment is based on a design that aims to have the most efficient and effective post go-live maintenance.

[Former Member]

Justin,

Thanks for the very helpful comments on CUA. I recently had our Basis person create CUA and we are still in realization, so it seems that we should undo what we've implemented because we installed CUA in our DEV system, we have the following systems ECD (DEV and QAS) and APO (DEV and QAS) we also have solution manager and it seemed that it would be the place to place CUA simply because it centrally manages the systems for other communications. We are also planning to turn on HR ORG in phase 2 so I your comments on the communication for HR are also relevant to me. I just want to be clear on the issues for running CUA on Solution Manager.

[Former Member]

I meant to say I would put CUA on the ECC prod box just like you said.

Would you maintain two CUA's or one?

One for the test environment, and one for the production environment?

If you have one CUA, do you need to have the same users in all clients?

[Former Member]

1 versus 2 CUAs depends on how strong your security controls are across environments. If they are really strong and consistent, you could even link in the dev and qa access requirements into the cross-system composite role so that if someone is brought into the position of 'sap-developer', then through HR, they would automatically receive ABAP workbench access in dev and display ABAP workbench in prod and QA. That is, HR indirect access provides access to all SAP systems in all environments. This is the single CUA with HR Indirect Assignment (aka the subset functionality position based security) system.

Otherwise, if (like most organisations) your dev and qa environments are a bit of a shambles, then you may want to have one CUA system maintaining prod, and another CUA system maintaining no-prod. That way, for non-prod environments you can assign roles directly to the user in the non-prod CUA, and have HR assign the roles to users in prod via the prod CUA.

CUA will only provision out to user ids that are the same (I'm not sure if that answers your question)? That is, if you have user id ABCDE in CUA, then it will provision out user ABCDE into all of it's child environments. When you are first setting up CUA, you basically import all of the user ids from the child systems during the process for consistency. If you have ABCDE in CUA then it cannot provision out to user FGHIJ.

[Former Member]

I'm not sure what you mean by DEV being a bit of shambles, but I would think if you are provisioning users, you would want to use User Level Security in one CUA and Position Level Security in the other CUA to keep the provisioning methods separate.

Justin, are you using two CUA's?

Did you need to set up a lot of composite roles?

One last question, do you have a list or cookbook on how to set up the composite roles with Indirect user assignments or know where I can find them?

Sounds like you have CUA working really good there!

Your answers have been helpful!

Thanks!

[Former Member]

> I'm not sure what you mean by DEV being a bit of

> shambles, but I would think if you are provisioning

> users, you would want to use User Level Security in

> one CUA and Position Level Security in the other CUA

> to keep the provisioning methods separate.

I just mean that the level of thought and design that goes into a production system, doesn't seem to go into the non-production systems. So, position based security is less feasible due to design. You are right in that if you want user level security in non-prod, then best to use a non-prod CUA for that. Have a prod CUA for the position based security.

> Justin, are you using two CUA's?

I work for many clients, so I have used both 1 CUA system and 2.

>

> Did you need to set up a lot of composite roles?

Not normally. I design top-down. That is, I define 'job' level roles rather than activity level roles. I would normally end up with about 100 roles for a large organisation, which are then derived as per their business units. I would expect no more than 1000 roles for a very large organisation.

>

> One last question, do you have a list or cookbook on

> how to set up the composite roles with Indirect user

> assignments or know where I can find them?

Unfortunately, the information on this in help.sap.com is just impossible to understand. I just re-read it then and it still doesn't make sense to me! If you have CUA set up in a sandbox or something, I would just run PFCG, and there is a menu item called 'read from RFC' or something like that. Run that, and then the single roles from the child systems are available to you to put into your composites.

>

> Sounds like you have CUA working really good there!

>

> Your answers have been helpful!

>

> Thanks!

[Former Member]

Justin, thanks for responding. Your answers have been very helpfull.

[Former Member]

to award points