3.3 Configuring End-User Access
Key Takeaways
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.
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
spadminis protected and exempt from lockout. You can protect others by settingprotected="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
ssoAuthenticatorsentry 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 |
| Contractors must use Duo | Import the Duo MFA workflow and enable it for a contractor population |
SAML single sign-on, pass-through authentication, and internal passwords are all enabled. In what order does IdentityIQ try them when a user signs in?
Internal IdentityIQ authentication, then pass-through, then single sign-on
Pass-through, then single sign-on, then internal IdentityIQ authentication
Single sign-on, then pass-through, then internal IdentityIQ authentication
The order is random for each login attempt
Users can sign in to IdentityIQ with their Active Directory passwords, but after a lockout on the IdentityIQ login page, some users still get in. Which setting explains this?
Authorization lockout applies only to IdentityIQ's internal password, not to the pass-through authentication application.
Pass-through authentication disables all lockout settings.
Protected users are always locked out first.
The SSOValidation rule unlocks accounts on every request.
A group of reviewers should all receive the Certification Administrator capability and lose it automatically when they leave the team. What is the most maintainable way to grant it?
Add the capability to each reviewer's identity by editing XML in the Debug pages.
Put the reviewers in a scope named Certification.
Assign the capability to a workgroup and manage the reviewers as workgroup members.
Create a QuickLink population named Certification Administrator.
Scoping is enabled with region as the Scope Identity Attribute, but regional administrators still see identities from every region. What step is most likely missing?
Restarting the IQService
Importing init-lcm.xml
Enabling Protected User Lockout
Running an identity refresh with the scope refresh option so identities receive their assigned scopes
Sections you finish are checked off in the contents.