5.2 QuickLinks and QuickLink Populations

QuickLinks and QuickLink Populations

Objective 2.5 asks you to create and manage QuickLinks and QuickLink populations. QuickLinks are how users start work in IdentityIQ. They appear as cards on the Home page, which users can add or remove, and as entries in the QuickLink menu available on every page. Examples are Request Access, Manage Accounts, Create Identity, Access Reviews, Approvals, and Work Items.

The Three Objects Behind a QuickLink

Key facts from the documentation:

• You cannot add QuickLinks inside IdentityIQ. They are defined when IdentityIQ is deployed, usually by importing QuickLink XML. On the population's QuickLinks tab, you enable existing links for that population.
• When you create a population on Global Settings > QuickLink Populations and enable links for it, IdentityIQ creates the QuickLinkOptions objects.
• The DynamicScope decides who can see and run the link. It does not define the identities the link acts on after it is clicked. That is the population's request-authority setting.
• Only System Administrators can see a QuickLink that has no population.
• A top-level QuickLink is treated as a non-LCM action that does not operate on a target identity, so no user-selection options are shown.

Default Populations

• Everyone exists by default. It is a DynamicScope with allowAll="true". Access Reviews, Approvals, Signoffs, Work Items, and Policy Violations are linked to it by default.
• With Lifecycle Manager, you also get Help Desk, Manager, and Self Service.

Configuring a Population

Membership

Included Identities always belong, and Excluded Identities never do. For example, you might exclude the Administrator.

Who Can Members Request For?

• Everyone, or
• Specific Users, matching all or any of these criteria:
  • Share attributes with the requester, such as the same department
  • Report to the requester, meaning direct reports or all subordinates, with a maximum hierarchical depth
  • Match custom criteria, a filter parsed as a Velocity template with a requester parameter, for example manager.name == "$requester.manager.name"
  • Match filter rule, an IdentityFilterGenerator rule that returns a Filter (creating one requires the ManageRules SPRight)
• Ignore scoping disregards IdentityIQ scopes for this purpose.

What Can Members Request or Remove?

Rules can limit the roles, applications, and entitlements members may request. A matching set of rules limits what they may remove. Sync with Request copies the request settings to the remove settings.

QuickLinks Tab

Enable the QuickLinks this population receives. For links that support it, use Configure to set options such as whether the link can be used for oneself.

What a Population Looks Like in XML

The documentation's example shows a DynamicScope that makes a link visible to anyone in the IT department or anyone with the Help Desk capability, and always to one named identity:

<DynamicScope name="MyDynamicScope">
  <Inclusions>
    <Reference class="sailpoint.object.Identity" name="Barbara.Wilson"/>
  </Inclusions>
  <PopulationRequestAuthority allowAll="true"/>
  <Selector>
    <IdentitySelector>
      <MatchExpression>
        <MatchTerm name="capabilities" value="Help Desk Personnel"/>
        <MatchTerm name="Department" value="IT"/>
      </MatchExpression>
    </IdentitySelector>
  </Selector>
</DynamicScope>

Read it piece by piece:

• Inclusions is the UI's Included Identities list. Barbara Wilson sees the link whatever her department or capabilities.
• Selector / IdentitySelector is the Membership rule. Here it is a Match List of a capability and an identity attribute.
• PopulationRequestAuthority is Who can members request for? allowAll="true" means everyone.

The matching QuickLinkOptions object is what attaches this DynamicScope to a specific QuickLink, for example Access Reviews. Editing a population in the UI updates these objects for you. Seeing the XML helps when you promote populations between environments (section 3.1) or diagnose them in the Debug pages.

Design Examples

The last row reflects a documented tip. When a population is used to enable multi-factor authentication (section 3.3), create a separate population with "No one" as request authority, so MFA membership does not accidentally grant request rights.

Exam Traps

• A population controls visibility and request authority. It does not grant SPRights. Capabilities still control administrative pages.
• If a user can see Request Access but the target list is empty, check Who can members request for?
• If a new custom QuickLink is invisible to everyone except administrators, it has no population attached.