This is a typical requirement many customers ask for and would request suggestions from this Portal forum:
The customer has multiple business functional roles for users of Portal. These are the company's finance user, logistics user, or purchasing department user and logs into a unified Portal interface.
The customer wants, that their Support reps (CSR) to manage access rights on specific pages/portlets/or/areas of Portal through a custom CSR Administrator console. and not the Portal administrators
1. What are design options for such requirement ? Do we maintain these functional roles in LDAP ? or keep them in Custom DB ?
2. How do we map the Portal roles to functional roles ?
3. The functional portlets may cut across departments such as finance and purchasing ?
Requesting suggestions / recommendations.
This topic has been locked.
5 replies Latest Post - 2013-01-25T21:35:56Z by JMW98
Pinned topic Portal Access Control and Business functional roles
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-01-25T21:35:56Z at 2013-01-25T21:35:56Z by JMW98
Re: Portal Access Control and Business functional roles2013-01-24T13:30:32Z in response to hrktechGenerally, you would have an LDAP group for each functional role (financegrp, logisticsgrp, etc.). If you could not or prefer not to create these on LDAP, you could implement application groups and store these in a VMM DB. You can assign roles on Portal resources to these groups through various administrative portlets (primarily Resource Permissions, but also Manage Pages, Manage Portlets, etc.).
You could define a CSR group and create a page with just the administrative portlets needed for assigning access to pages and portlets. Or your could give them access to just certain Portal's Administration pages and portlets. For the access rights that these CSRs would require, reference "Access permissions for Access Control Administration" here:
It sounds like you're mainly interested in "Creating or deleting a role assignment for user or group U created from role RT on resource R".
Re: Portal Access Control and Business functional roles2013-01-24T16:00:00Z in response to JMW98Thanks much for your response.
We would create a CSRGroup and give them access to only the ACCESS Submenu in Portal Administration and its relevant administrative Portlets.
However in this scenario listing a few points and requesting additional suggestions:
1. Since the CSRGroup User will have the ability to make changes using administrative portlets like giving permissions to pages/portlets in Production environment, what would be its implications ?
2. I presume this will have mismatch in the XML config between Production and lower environments.
What steps or process needs to put in place for iterative portal builds ?
3. Are there any other risks involved in giving such access to CSR users in Production. ? (although we may ensure the CSR team would be sufficiently trained to use those 3-4 admin portlets and will use only the Admin GUI).
4. Has anyone done this, and could share experiences.
Thanks again !!
Re: Portal Access Control and Business functional roles2013-01-24T18:54:22Z in response to hrktech1. Members of CSRGroup could only assign roles up to and including their on role assignments on any given resource. This is the RT@R aspect of the required roles. Reference the role hierarchy and resource hierarchy here:
2. Please clarify what mismatches you anticipate. If just that users may differ, you will get warnings (not errors) on any XMLAccess imports where the DN in the role assignment must be found. If anything more than that, then you need to plan how you are managing the two systems. i.e. Will you stage to production, use Release Builder, etc.?
3. Just that they could assign any other user/group to which they had access (Delegator@U) any role up to and including their own.
4. This approach is common, though it might be easier to use Manage Pages and Manage Portlets if those are the only resources to which CSRGroup will assign access. You could put those two on their own page, then assign CSRGroup at least the User role on that page, those portlets, plus the Resource Permissions portlet (called when assigning roles from the other two admin portlets).
Re: Portal Access Control and Business functional roles2013-01-25T12:23:34Z in response to JMW98Thank you and Appreciate detailed response.
On Point no 2. : Since the CSR User will make changes directly on production, these changes needs to be retained in successive builds. I presume , the Staging will need periodic update/sync backwards from Production environment with following steps before each new deployment:
1. Full export from Production
2. Update Staging to be in sync with Production.
3. Update staging with newly developed artifacts <Pages, Portlets>
4. Run ReleaseBuilder between Prod & staging.
5. Update Production with Release Builder output.
Requesting thoughts and feedback on this.
On Point 3 : Understanding this risk , Does Portal create a log of activity done through Admin Console GUI. ?
If that is possible we can generate report by CSR User. (could be re-validation tool)
Re: Portal Access Control and Business functional roles2013-01-25T21:35:56Z in response to hrktechJust a couple of notes:
- Generally the production server's configuration would not be edited manually if ReleaseBuilder were being used to maintain it. I don't think that just tweaking role assignments will cause any problems, but you should test to make sure. I also assume that the staging and production servers have the same user repository. The thing you'd want to be careful about would be unintentionally adding/removing any role assignments when importing a release. Having the same user repository and keeping staging's role assignments in sync should avoid problems.
- For (4), you should always run ReleaseBuilder against an old & new release from the same system. Reference:
- Yes, you can audit role assignments:
It sounds like you are mainly interested in audit.roleEvents.enable, but you may want to audit other events as well: