05-15-2009 4:24 PM
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!
05-15-2009 4:52 PM
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.
05-15-2009 4:52 PM
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.
05-15-2009 9:48 PM
I read what you quoted before.
However this quotation does not answer my questions. Please help more.
Thanks!
05-16-2009 4:10 AM
05-18-2009 3:32 PM
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!
05-18-2009 9:25 PM
05-19-2009 8:41 AM
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.
05-19-2009 8:49 AM
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.
05-16-2009 2:59 PM
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.