Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How to load roles for the CUA child clients into CUP (GRC5.3)?

Former Member
0 Kudos

We have some questions about this:

1) Do we have to do this load? CUP cannot work without CUA existing?

2) Because our CUA has so many child systems, is it possible to load in a short period?

3) Once any role in the child system is changed, the change will automatically show in CUP

without manually re-load the changed role?

Thanks!

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi,

Please go through this, whether your question are answer below please let me know,

CUA and Compliant User Provisioning work well together, so it is not necessary to choose

between the two. There are reasons to use the CUA and reasons to use Compliant User

Provisioning.

􀁸 CUA manages users and their access in the child systems.

􀁸 Compliant User Provisioning provides the access request ability, audit trails for the

approvers on the requests, and provisions the approved roles to the CUA.

When a request is provisioned in Compliant User Provisioning and the CUA is used,

Compliant User Provisioning provisions the requested roles to the CUA. The CUA pushes

those roles down to the child systems. Compliant User Provisioning allows the CUA to

manage the access in the child systems.

You must create connectors and install the appropriate RTAs on those systems for the CUA

parent system, as well as each of the CUA client systems.

Compliant User Provisioning performs all inquiries and searches against the child client itself;

it only completes provisioning with the CUA parent. Requestors and approvers request and

approve the access to the individual applications (child system clients), but you provision the

access with the CUA.

The CUA system setting can be a global setting in Compliant User Provisioning, or it can be

set by each individual system connector. Therefore, some of your systems can be connected

to a CUA and others not connected, but both can be provisioned through Compliant User

Provisioning.

Since most of the activity between the requestor and approver occurs directly within the

application itself, the only difference is that a CUA client is where the user and roles are

provisioned. If it is a CUA child system, provisioning happens on the CUA parent, whereas a

non-CUA system provisions to itself.

You must load roles for the CUA child clients into Compliant User Provisioning to make them

available for the requestor to select them through the Select Roles functionality. Do not load

CUA child system roles assigned to the CUA parent system into Compliant User

Provisioning; load them only to the child systems.

Thanks,

Sudip.

8 REPLIES 8

Former Member
0 Kudos

Hi,

Please go through this, whether your question are answer below please let me know,

CUA and Compliant User Provisioning work well together, so it is not necessary to choose

between the two. There are reasons to use the CUA and reasons to use Compliant User

Provisioning.

􀁸 CUA manages users and their access in the child systems.

􀁸 Compliant User Provisioning provides the access request ability, audit trails for the

approvers on the requests, and provisions the approved roles to the CUA.

When a request is provisioned in Compliant User Provisioning and the CUA is used,

Compliant User Provisioning provisions the requested roles to the CUA. The CUA pushes

those roles down to the child systems. Compliant User Provisioning allows the CUA to

manage the access in the child systems.

You must create connectors and install the appropriate RTAs on those systems for the CUA

parent system, as well as each of the CUA client systems.

Compliant User Provisioning performs all inquiries and searches against the child client itself;

it only completes provisioning with the CUA parent. Requestors and approvers request and

approve the access to the individual applications (child system clients), but you provision the

access with the CUA.

The CUA system setting can be a global setting in Compliant User Provisioning, or it can be

set by each individual system connector. Therefore, some of your systems can be connected

to a CUA and others not connected, but both can be provisioned through Compliant User

Provisioning.

Since most of the activity between the requestor and approver occurs directly within the

application itself, the only difference is that a CUA client is where the user and roles are

provisioned. If it is a CUA child system, provisioning happens on the CUA parent, whereas a

non-CUA system provisions to itself.

You must load roles for the CUA child clients into Compliant User Provisioning to make them

available for the requestor to select them through the Select Roles functionality. Do not load

CUA child system roles assigned to the CUA parent system into Compliant User

Provisioning; load them only to the child systems.

Thanks,

Sudip.

0 Kudos

I read what you quoted before.

However this quotation does not answer my questions. Please help more.

Thanks!

0 Kudos

Hi,

Please tell me whether you are using ERM in GRC AC?

Regards,

Sudip.

0 Kudos

Sudip:

Yes we use ERM.

Thanks for the upload info.

From what I've gothered here is that GRC must go with CUA?

The manual role upload would be overwhelming since we have so many systems here and the roles

are modified constantly.

So what is a basis person's responsibilty GRC because seems there are a lot of security related issues.

Please advise. Thanks!

0 Kudos

Yes, we use ERM here.

So GRC5.3 must be used with CUA?

Thanks!

0 Kudos

Hi Ashley,

I hope you got your first and second question's answer?

Now to answer your third question, CUP contails only role name and role description like which system & approver it belongs, type of role(single or composite), Business and Sub-business process etc etc. But, it has not contain any tcode and authorization object in CUP.

So if you change any role in child systems it is not required to re-load the same role into CUP again.

Regards,

Sudip.

0 Kudos

Hi Ashley,

I hope you got your first and second question's answer?

Now to answer your third question, CUP contails only role name and role description like which system & approver it belongs, type of role(single or composite), Business and Sub-business process etc etc. But, it has not contain any tcode and authorization object in CUP.

So if you change any role in child systems it is not required to re-load the same role into CUP again.

Regards,

Sudip.

former_member196034
Participant
0 Kudos

If you don't upload/import roles, you will not be able to provision any roles to users from CUP. The CUP tool allows a requestor to search for roles available by system. This search is performed against the GRC tables which have been updated with role data uploaded or imported in CUP.

I find the quickest, simplest way is to fill in the Role Import File (Template is provided in CUP), you can also perform a role search in CUP and export the results. The same export file can be used to upload back into CUP as an import file providing replace the role data with the new roles. The good thing about this is that you can also list any role approvers instead of going one by one into each role in CUP and updating it that way.

Any new roles in child systems will need to be reloaded into CUP.

The role load can be performed using the Role Import screen or by using the Role Import File. So for example, if you have created two new roles in a child system, add the role details in the import file and upload into CUA. Done.