Creating a Closed User Group

Sök
Experience Manager 6.2 Sites Användarhandbok för att administrera
Gäller för: Experience Manager 6.2 Sites

某些 Creative Cloud 应用程序、服务和功能在中国不可用。

Du visar hjälpinnehåll för version:

Closed User Groups (CUGs) are used to limit access to specific pages that reside within a published internet site. Such pages require the assigned members to login and provide security credentials.

To configure such a area within your website you:

Viktigt:

Closed user groups (CUGs) should always be created with performance in mind.

Although the number of users and groups in a CUG is not limited, a high number of CUGs on a page may slow down rendering performance.

The impact of CUGs should always be considered when doing performance testing.

Creating The User Group To Be Used

To create a closed user group:

  1. Navigate to the Security console of CQ.

    Obs!

    See Managing Users and Groups for full information on creating and configuring users and groups.

  2. Create your new group; for example, cug_access.

  3. Assign the required users to this group.

  4. Activate any users that you have assigned to your CUG; in this case, all members of cug_access.

  5. Activate the closed user group so that it is available in the publish environment; in this example, cug_access.

Applying Your Closed User Group To Content Pages

To apply the CUG to a page:

  1. Navigate to the root page of the restricted section you want to assign to your CUG.

  2. Open the Page Properties (from the Page tab in the Sidekick).

  3. Open the Advanced tab.

  4. Expand the Closed User Group pane.

  5. Click Enabled to define that this page (and any child pages) belong to a CUG.

  6. Specify the Login Page that members of the group will use; for example:
        /content/geometrixx/en/toolbar/login.html
    This is optional, if left blank the standard login page will be used.

  7. Add the Admitted Groups. Use + to add groups or - to remove. Only members of these groups will be allowed to log in and access the pages.

  8. Assign a Realm (a name for the groups of pages) if required. Leave empty to use the page title.

  9. Click OK to save the specification.

See Identity Management for information about profiles in the publish environment and providing forms for logging in and out.

Linking To The Realm

Since the target of any links to the CUG Realm are not visible to the anonymous user, the linkchecker will remove such links.

To avoid this, it is advisable to create non-protected redirect pages that point to pages within the CUG Realm. The navigation entries are then rendered without causing the linkchecker any problems. Only when actually accessing the redirect page will the user be redirected inside the CUG Realm - after successfully providing their login credentials.

Configuring the Referrer Filter

You need to configure the Sling Referrer Filter with all hostnames that may be used to access AEM; for example, via CDN, Load Balancer, and any others.

If the referrer filter is not configured, then the following error is seen when a user tries to log in to a CUG site:

31.01.2017 13:49:42.321 *INFO* [qtp1263731568-346] org.apache.sling.security.impl.ReferrerFilter Rejected referrer header for POST request to /libs/granite/core/content/login.html/j_security_check : http://hostname/libs/granite/core/content/login.html?resource=%2Fcontent%2Fgeometrixx%2Fen%2Ftest-site%2Ftest-page.html&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown

Configure Dispatcher for CUGs

If you are using Dispatcher, you need to define a Dispatcher farm with the following properties:

  • virtualhosts: Matches the path to the pages that the CUG applies to.
  • \sessionmanagement: see below.
  • cache: A cache directory that is dedicated to the files that the CUG applies to.

Configuring Dispatcher Session Management for CUGs

Configure session management in the dispatcher.any file for the CUG. The authentication handler that is used when access is requested for CUG pages determines how you configure session management. 

For example, the default CRX login module uses token-based authentication, and sets a cookie named login-token. In this case, the /sessionmanagement configuration section requires aheader parameter that identifies the cookie:

/sessionmanagement
    ...
    /header "Cookie:login-token" 
    ...

Obs!

When a Dispatcher farm has session-management enabled, all pages that the farm handles are not cached. To cache pages that are outside of CUG, create a second farm in dispatcher.any
that handles the non-CUG pages.

  1. Configure /sessionmanagement by defining /directory; for example:

    /sessionmanagement
  {
  /directory "/usr/local/apache/.sessions"
  ...
  }

  2. Set /allowAuthorized to 0.