Topic
  • 5 replies
  • Latest Post - ‏2013-01-25T21:35:56Z by JMW98
hrktech
hrktech
36 Posts

Pinned topic Portal Access Control and Business functional roles

‏2013-01-23T19:55:40Z |
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

Questions:
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.

Thank you.
Updated on 2013-01-25T21:35:56Z at 2013-01-25T21:35:56Z by JMW98
  • JMW98
    JMW98
    1097 Posts

    Re: Portal Access Control and Business functional roles

    ‏2013-01-24T13:30:32Z  
    Generally, 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:

    http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Access_permissions_wp8

    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".
  • hrktech
    hrktech
    36 Posts

    Re: Portal Access Control and Business functional roles

    ‏2013-01-24T16:00:00Z  
    • JMW98
    • ‏2013-01-24T13:30:32Z
    Generally, 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:

    http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Access_permissions_wp8

    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".
    Thanks 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 !!
  • JMW98
    JMW98
    1097 Posts

    Re: Portal Access Control and Business functional roles

    ‏2013-01-24T18:54:22Z  
    • hrktech
    • ‏2013-01-24T16:00:00Z
    Thanks 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 !!
    1. 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:
    http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Roles_wp8
    http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Resources_wp8

    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).
  • hrktech
    hrktech
    36 Posts

    Re: Portal Access Control and Business functional roles

    ‏2013-01-25T12:23:34Z  
    • JMW98
    • ‏2013-01-24T18:54:22Z
    1. 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:
    http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Roles_wp8
    http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Resources_wp8

    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).
    Thank 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)

    Thanks !!
  • JMW98
    JMW98
    1097 Posts

    Re: Portal Access Control and Business functional roles

    ‏2013-01-25T21:35:56Z  
    • hrktech
    • ‏2013-01-25T12:23:34Z
    Thank 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)

    Thanks !!
    Just 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:

    http://www-01.ibm.com/support/docview.wss?uid=swg21243005

    • Yes, you can audit role assignments:

    http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Auditing_wp8

    It sounds like you are mainly interested in audit.roleEvents.enable, but you may want to audit other events as well:

    http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Auditing_Service_wp8