Study guide
3.3 Configuring End-User Access
SailPoint Certified IdentityIQ Engineer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: The IdentityIQ Engineer Exam
1.1 Exam Format, Official Blueprint, and Study Strategy
2 Chapter 2: Infrastructure, Installation, and Extended Attributes
2.1 IdentityIQ Infrastructure Components 2.2 Installation Steps and Procedures 2.3 Creating Extended Attributes and the Objects That Support Them
3 Chapter 3: Build, Deployment, Patching, Access, and Email
3.1 Ongoing Build and Deployment 3.2 Installing Patches and Performing Upgrades 3.3 Configuring End-User Access 3.4 Email Server Settings and Email Redirection
4 Chapter 4: Lifecycle Manager Configuration, Provisioning Policies, and Workflows
4.1 Configuring Lifecycle Manager 4.2 Identity Provisioning Policies 4.3 Configuring LCM Workflows
5 Chapter 5: Lifecycle Events, QuickLinks, Batch Requests, and Rapid Setup
5.1 Lifecycle Events and Their Workflows 5.2 QuickLinks and QuickLink Populations 5.3 Configuring and Using Batch Requests 5.4 Rapid Setup in Lifecycle Events and Identity Operations
6 Chapter 6: Certification Campaigns and Certification Rules
6.1 Configuring and Scheduling Certification Campaigns 6.2 The Purpose of Common Certification Rules
7 Chapter 7: Policies and Policy Violations
7.1 Configuring and Leveraging Policies 7.2 Responding to Policy Violations
8 Chapter 8: Reporting, Advanced Analytics, and Auditing
8.1 Executing and Leveraging Reports 8.2 Leveraging Advanced Analytics 8.3 Configuring and Using Auditing
9 Chapter 9: Rules, Rule Libraries, and the SailPoint API
9.1 The Purpose and Use of Rule Libraries 9.2 Rule Input and Output Arguments 9.3 Common SailPoint API Objects and Methods
10 Chapter 10: Workflow Development
10.1 Workflow Variables, Transitions, and Step Conditions 10.2 Workflow Steps That Generate Work Items 10.3 The Different Workflow Step Usages 10.4 Leveraging Sub-Workflows
11 Chapter 11: Email Templates, Branding, and Localization
11.1 Customizing and Using Email Templates 11.2 Branding the SailPoint User Interface 11.3 Localizing the SailPoint UI
12 Chapter 12: Application Definitions, Connector Settings, and Rapid Setup Aggregation
12.1 Configuring Application Definitions 12.2 Configuring Common Connector Settings 12.3 Configuring Rapid Setup Aggregation Settings
13 Chapter 13: Data-Loading Tasks and Application and Connector Rules
13.1 Scheduling Tasks for Data Loading and Processing 13.2 Common Application Rule Types 13.3 Common Connector Rule Types
14 Chapter 14: Debugging with log4j, Syslog, and the IdentityIQ Console
14.1 Configuring and Leveraging log4j 14.2 Configuring and Leveraging Syslog 14.3 Leveraging the IdentityIQ Console for Debugging
15 Chapter 15: Debug Pages and the Administrator Console
15.1 Leveraging the Debug Pages for Debugging 15.2 Leveraging the Administrator Console for Debugging
16 Chapter 16: Role Model and Identity Attribute Mappings
16.1 Default Role Models and Role Types 16.2 Configuring Roles and Role Options 16.3 Configuring Identity Attribute Mappings
17 Chapter 17: Data Objects, Relationships, and Group Types
17.1 Common IdentityIQ Data Objects 17.2 Relationships Between Common Data Object Models 17.3 The Difference Between Group Types
3.3 Configuring End-User Access
Key Takeaways Explain This Topic AI
IdentityIQ tries authentication methods in order: single sign-on (rule-based or SAML), then pass-through authentication, then internal IdentityIQ authentication.
Pass-through authentication checks users against an application such as Active Directory; an auto-create user rule can build an identity on first login.
Capabilities group SPRights; they can be assigned directly or inherited from workgroup membership.
Scopes limit which objects a user can see: assigned scope is where an object lives, and controlled scope is what a user may administer.
Multi-factor authentication runs through MultiFactorAuthentication workflows (Duo or RSA examples) enabled for selected QuickLink populations.
Last updated: September 2026
Configuring End-User Access
Objective 1.6, understand the configuration of end user access , asks how people get into IdentityIQ and what they can do once there. Think in three layers: authentication (who you are), authorization (what features you can use), and visibility (which objects and actions appear for you).
Layer 1: Authentication
Authentication is configured under gear icon > Global Settings > Login Configuration , which has tabs for Login Settings , User Reset , Multi-Factor Authentication , and SSO Configuration .
IdentityIQ tries every enabled method before it reports a failed login, in this fixed order :
- Single sign-on , rule-based or SAML
- Pass-through authentication
- Internal IdentityIQ authentication
If multi-factor authentication is configured, it runs after whichever method succeeded. IdentityIQ's internal passwords are always a fallback , even when other methods are in use. They are governed by the IdentityIQ password policy.
Pass-Through Authentication
On the Login Settings tab, Pass through application names an application, usually Active Directory or LDAP, that verifies each user's credentials. For this to work, the application's Authentication Search Attributes must list the account schema attributes that hold the username users type in.
Other Login Settings options:
Auto create user rule – creates an IdentityIQ identity the first time a user authenticates through the pass-through application, based on the rule's logic.
Login error style – Simple hides what was wrong, while Detailed says, for example, "Invalid password for user admin."
Enable Authorization Lockout – locks a user out of IdentityIQ's own password after a set number of failed attempts, for a set number of minutes. It does not apply to the pass-through application.
Enable Protected User Lockout – by default, only spadmin is protected and exempt from lockout. You can protect others by setting protected="true" on their Identity object.
Single Sign-On
Rule-based SSO – an upstream component, such as a web access manager, authenticates the user and passes a token in the HTTP header. The SSOAuthentication rule maps it to an identity. An optional SSOValidation rule runs on every request. It returns null when the session is valid and an error string when it is not.
SAML SSO – IdentityIQ is the service provider. You configure the identity provider's SSO login URL, public X.509 certificate, and issuer, plus IdentityIQ's entity ID, Assertion Consumer Service URL, binding (HTTP POST or Redirect), Name ID format, and a SAML correlation rule that matches the assertion to an identity.
If both are enabled, the ssoAuthenticators entry in SystemConfiguration sets the order. Without it, SAML is tried first. Administrators can reach the normal login page with .../login.jsf?prompt=true .
Multi-Factor Authentication and User Reset
MFA is delivered through workflows of type MultiFactorAuthentication . SailPoint ships Duo and RSA examples ( workflow_MultiFactor_DUO.xml , workflow_MultiFactor_RSA.xml ) that are not installed by default. You import one, set its process variables, and then, on the MFA tab, enable it for one or more QuickLink populations . The User Reset tab turns on Forgot Password and Account Unlock , verified by security questions or SMS through Twilio. Forgot Password resets apply to the pass-through application's password.
Layer 2: Authorization with Capabilities and Rights
IdentityIQ's security model is built on SPRights , granular rights that switch menus, pages, tabs, and actions on or off. Capabilities bundle rights by job function so that you assign one capability instead of dozens of rights. Capabilities reach a user in two ways:
Directly , on the User Rights tab of the identity (Identities > Identity Warehouse).
Through a workgroup , where members inherit the capabilities assigned to the workgroup (Setup > Groups > Workgroups).
Capabilities can also be certified, and QuickLink population membership can depend on them. The rights inside a capability are visible in the Debug pages under the Capability object's <RightRefs> . System Administrator is the all-powerful capability, and the Debug pages require it, apart from the read-only debug access added in 8.4.
Layer 3: Visibility with Scopes and QuickLink Populations
Capabilities decide which pages a user can open. Scopes decide which objects appear on those pages.
Term Meaning
Assigned scope The scope an object or identity belongs to, set manually, by rule, or through aggregation and correlation
Controlled scope The scopes a user may see and manage. They are hierarchical, so controlling a parent includes its children.
Scoping is configured under Global Settings > Scopes . Turn on Enable Scoping , choose a Scope Identity Attribute (a scope is created for each value) or a Scope Correlation Rule , and add a Scope Selection Rule for identities that match more than one scope. Scope changes appear only after an identity refresh with the refresh-scope option .
QuickLink populations control the Home-page cards and QuickLink menu entries a group of users receives. For Lifecycle Manager, they also control for whom members can request and what they can request or remove. Section 5.2 covers them in depth. The default population is Everyone , and LCM adds Help Desk , Manager , and Self Service .
Putting It Together
Requirement Configure
Users log in with their AD password Login Settings > Pass through application, plus Authentication Search Attributes on the AD application
Corporate IdP handles login SSO Configuration > SAML (IdP URL, certificate, correlation rule)
Helpdesk staff can request access for anyone QuickLink population Help Desk with "Who can members request for?" set to Everyone
Regional admins see only their region Scopes based on a region identity attribute, plus controlled scopes on the admins