IdentityIQ Essentials Training

All data in IIQ is stored as Java Objects

Tasks are batch jobs that act on objects (no user interaction)

Business processes are repeatable sets of executable steps that act on objects (often interact
with users)

Rapid Setup: First available in 8.1. Allows a broad team to participate in deployment, common
scenarios configured.

IdentityIQ Installation Process:

1. Deploy war file
2. Add custom attributes to hbm files (identity, managedattribute, role, etc)
3. Generate schema for DB
4. Create IIQ DB
5. Configure iiq.properties
6. Initialize default system objects (import init.xml, import init-lcm.xml)
7. Apply patches

Objects that can be extended:

● Applications
● Roles
● Certification Items
● Identities
● Accounts (Link)
● Entitlements (ManagedAttributes)

Identity Attributes Made Through GUI

Searchable
● Stored in own column
● Efficient searching
● Allows for ad hoc querying
Non Searchable
● Stored in a CLOB
● Efficient loading and storage

Searchable Attribute Types:

1. Standard: Predefined (user_name, manager…)
2. Named: User defined, named columns
3. Placeholder Extended: User defined, column space

There is a maximum of 20 placeholders per object type (extended1, extended2, …)

 ● Modify the hbm files i.e. /WEB-INF/classes/sailpoint/object/Application.hbm.xml

Once hbm.xml files have been modified, /WEB-INF/bin/iiq schema will create the db scripts in
/WEB-INF/database

If the DB table already exists and you would like to add more attributes, instead of running the
“schema” command in the iiq console, run the “extendedSchema”:
● Modify the hbm file
● WEB-INF/bin/iiq extendedSchema
● New ddl files will exist in WEB-INF/database
● Use ddl to update the existing db

Modifying IdentityIQ Properties

● Modify /WEB-INF/classes/iiq.properties
● Encrypt the db password (dataSource.password) with iiq console encrypt
● dataSource.url= the db url

To initialize the default iiq objects

● /WEB-INF/bin/iiq console import init.xml
● Import init-lcm.xml

Identity Cube: All information we have about the identity (accounts, attributes, access, policy
violations, risk scores). Information on cube can be:
● Discovered
● Requested
● Assigned
● Calculated

Account Schema: Represents the application account, and defines which attributes are read. It
is required for each application.

Rapid Setup Flow:

1. Define application
2. Configure application behavior with rapid setup

Rapid Setup Allows you to:

1. Correlate account to identity
2. Correlate manager
3. Set active / inactive
4. Specify identity type

Identity Attributes: Used to drive processes in IIQ. There are standard attributes that are
searchable, and extended attributes (as many as you want) defined by user
Standard Attribute List:
 ● Administrator (only applies to service account / bot)
● Display Name
● Email
● First Name
● Inactive
● Last Name
● Manager
● Software Version (only applies to service account / bot)
● Type

Can configure the source of Identity attributes to be an application attribute or a rule

Using Identity Data:

Searchable
● Correlation
● Analytics
Multivalued
Group Factory
● Dynamically create groups (maybe region is a group factory)
● Groups can be used to filter identities included in actions

Identity Datatype:
● Supports one to many identity relationship
● Identity can only have 5 other identities as attributes (manager is 1, so 4 others)

Manager correlation defines which application attribute maps to user’s manager (can be
specified either in the app definition or rapid setup)

Identity Refresh Task (all these are optional checkboxes):

● Mark manager status for each identity
● Promote account attributes to identity attributes
● Promote entitlements so they are certifiable
● Promote role assignments/detection
● Process lifecycle events
● Look for policy violations

Refresh Task Best Practice: Have multiple identity refresh tasks which allows you to execute
various options as needed in a just-in-time manner

IdentityIQ Authentication Options:

● Native IIQ Auth
● Pass Through (AD / LDAP)
● SSO (Rule based passed in header and rule validates), SAML
● MFA (RSA/Duo)
Capabilities + Scope define what users can do and see inside iiq

Default capability is home page, quicklinks and my work

Scoping: Dividing data into logical groups and granting access based on those groups.
Controls the object user can see and act on.

Workgroup: Group of identities treated as a single IIQ identity. Can assign both capabilities and
scopes.

Populations: Identity search that finds a common set of attributes. Example population could
be Managers in North America (looks at both position attribute and location). Can be used to
filter for tasks, certifications, reports, etc

You can Intelligence >> Advanced Analytics >> Search for identities and save the result as a
population

Groups: Defined automatically based off a single identity attribute

● Need to mark the identity attribute as a group factory, any identity attribute can be a
group factory (if location is a group factory, groups could be “paris”, “rome”, and “mexico
city”, and members belong if their location matches that)

Creating Groups:
● Set name
● Enabled / Disabled
● Scope
● Owner Rule

“Refresh Groups” task creates sub groups for each value found (i.e. if group factory is location,
sub groups may be Boston, Austin, and Richmond)

Once “Refresh Group” ran, group list is static and needs to be ran again to refresh. Group
membership is identified when the group is used (dynamically).

Both groups and populations only store the criteria, and determine membership dynamically

Non-Authoritative App Correlation:

● Account schemas and entitlements
● Group schemas
● Classification
● Correlation
● Provisioning (esp birthright)
You can designate certain account attributes as managed and entitlements
Managed: Created in the entitlement catalog, request through LCM, policy and risk
Entitlement: Included in certifications and role mining

Group Schema is for groups managed in the entitlement catalog

An account attribute’s type can be the type of group in the group schema

Requestable Best Practice: Infrastructure apps (AD, LDAP, DB servers) with lots of
entitlements not requestable. Business Apps with fewer entitlements requestable.

Data classification: Locked / disabled accounts, service accounts and bots

If account doesn’t match authoritative app, identity cube is created as a non-authoritative cube.

Account Correlation Precedence:

1. Rule
2. Correlation config
3. Default logic

Rapid setup provides convenient ui, 1 application attribute matches to 1 identity attribute

Correlation wizard allows for ordered set of correlations

Uncorrelated Accounts: Can manually correlate them and the correlation is permanently
maintained (and “merge” identities)

Move Account: If an account is incorrectly correlated, it can be moved to existing or new

identity

Resolve Unsuccessful Correlation:

● Fix correlation logic manually
● Run “Prune Identities” task

Consistent Connector Config:

● Account and group schema
● Resource obj representation
● Application level rules

Varies Per Connector:

● Group schema - 1 or multiple?
● Connectivity details
● Connector specific rules
IdentityIQ Loopback Connector: Treats identity cubes as accounts and
workgroups/capabilities as entitlements

SQL Loader Connector: Treats delimited files as sql table

Useful IIQ Console Connector Debugging Commands:

● connectorDebug <Application> iterate account
● connectorDebug <Application> iterate group
● connectorDebug <Application> test (test connection)
● connectorDebug <Application> auth <u> <p> (pass through auth)

You can save Advanced Analytics Searches as Reports

Aggregation Performance Strategies:

● IIQ Optimization (optimization of unchanged accounts)
● Custom Delta processing (detect deleted = false)
● Connector Based Delta (time stamps considered and static account ignored)
● Partitioning (ldap / ad / delimited files) - limit to max of 250 partitions
● Multithreading

Identity Refresh Best Practices:

● Split into separate pieces (attribute refresh, role refresh, entitlement processing, etc)
● Delta refresh identities
● Divide and conquer w/ multithreading and partitioning

IIQ Maintenance Tasks:

● Perform Maintenance: Certification phases, background processes
● Check expired mitigations: Scans for policy / certification mitigations that have expired
● Check sunset requests: Controls timing of email notifications and sunset reminders of
expiring items
● Check expired work items: Scans for incomplete work items
● Perform Identity Request Maintenance: Checks for provisioning completeness

Admin Console:
● Tasks: Stack trace, terminate, status
● Environment: Statistics, status of apps, status of extensions
● Provisioning: Status of writing to other systems

Logging Options:
● Standard Out (System.out.println()) - never use in prod
● Java application logging (log4j)
● Email redirection
● Audit configuration
● Syslog logging
WEB-INF/classes/log4j2.properties you can specify log levels, and turn individual logs on and
off

Debug -> Logging -> Reload logging configuration

Email Logging: Forced redirection emails to a file. Useful for testing purposes

Auditing: Appears in the audit log (Advanced Search). Gear >> Global Settings >> Audit
Configuration to change settings

Syslog: Logs errors that occur. Gear >> Global Settings >> IIQ Configuration >> Miscellaneous
to configure syslog deletion

IIQ Console requires auth unless spadmin / admin is the u/p

Useful IIQ Console commands:

● Get: retrieve xml of object
● Checkout / Export: Retrieve xml object
● Import: Import xml object
● rule <name> to run rule
● list taskdefinition: All tasks and reports in the system (reports are just a fancy type of
task)
● run <taskname>: run a task
● tasks: lists all scheduled tasks
● source: load and execute command file

Debug Pages:
● Only available to sysadmin
● Hidden url
● Can view, edit, create, delete objects
● Memory usage / garbage collection

Policy Definition: Access related business policies of enterprise. Prevent users from violating
policies, and detect existing violations.
● Detective: Find existing policy violations and have a revocation / allow it. Identity refresh
detect violations
● Preventative: In LCM process, discover a policy violation will occur and alert the
requester / approver

Certifications: Helps maintain compliance. Provides a review of access employees have. Often
there are legal/business requirements for regular certifications
Certification Lifecycle:
1. Generation
2. Staging (Optional)
3. Active
4. Challenge (Optional)
5. Revocation (Optional)

Certification Triggers:
● Manual
● Scheduled
● Data changed (triggering certification)

Role: Object that encapsulates a set of access (can be on different systems)

2 Tier Role Model:

Business Role: Assigned automatically / requested, job title people expect
IT Role: Define groups/entitlements, detected on identities

Often, a business role has a required IT role(s). So the business role is assigned, and then on
the back end the IT role also becomes assigned (and IT role has required entitlements, so the
entitlements become provisioned).

Permitted Roles are IT roles that can be requested once you have the business role.

On the identity refresh task, assignment rules and detection is processed. Provision
assignments / disable deprovisioning can also be selected.

Rapid Setup Birthright Roles:

● Single tier model
● Only assigned during joiner event
● Not requestable

Birthright roles are always single tier - do not need to be rapid setup (can use assignment rules
directly on role).

Provisioning: Adding, modifying, or deleting user / access data

Provisioning Fulfillment:
● Direct connectors
● 3rd party integration
● Manually assigned work items

Provisioning Process:
● Expansion (what is being requested roles / entitlements)
 ● Filtering (what do you already have)
● Channel selection (direct write / manual work item)

Provisioning Policies: Values for creating/updated/deleting accounts for connected apps.

Values can either be manually entered or automatically generated (either statically or
dynamically in the provisioning plan)

For JDBC, you will need to write a provisioning rule

Provisioning can be dependent (maybe you need AD account prior to account on this system)

Provisioning Transaction Page: Override automated transaction and make manual work item
instead, retry to force next attempt for retry-enabled apps

Global Settings >> IIQ Config >> Miscellaneous to configure how long to keep provisioning
transactions

WokflowCase: Object created whenever a workflow is kicked off. Contains the details for
running a workflow process. It is deleted upon the workflows completion however

WorkItem: Created by workflow to obtain input from a person (approval, policy violation, manual
provisioning, request for data, access review…)

LifeCycle Events: Normal activities which occur during the course of employment
(joiner/mover/leaver)

Rapid Setup Joiner: Account creation, birthright role assignment

Rapid Setup Mover: Certification, preprocess joiner
Rapid Setup Leaver: Disable/delete/move account, remove entitlements, scramble password,
immediate or time delayed

Prior to doing the rapid setup joiner, need to have defined the applications and birthright roles
you want assigned. Then, set up actions on a per application basis

Usually you only have new accounts in authoritative apps capable of kicking off joiner

For rapid setup joiner, you configure:

● Enable joiner
● Approval requirements (if any)
● Business process
● Email notification (email templates / manager notification)
● Post joiner rule

For rapid setup mover, configure:

 ● Trigger (manager changes, department changes, job changes, all three change, etc)
● From there trigger can have manager review all access, retrigger the joiner process, or
other business processes / rules

For rapid setup leaver, configure:

● Trigger (identity changes to inactive)
● Then, assigned roles can be removed, owned artifacts can be reassigned (maybe
ownership of an IIQ Role), approvals moved, notifications sent out, business
process/leaver rule ran
● Per application: accounts can be deleted / disabled, passwords scrambled, entitlements
removed, comments / directory moved

You can set up lifecycle events for very niche things through the UI, i.e. if employee department
changes from “x” to anything else, do this
Lifecycle Events can be tracked in “Track My Requests”

Advanced Analytics >> Lifecycle Events will also display what occurred in the lifecycle event

Access Request Overview:

1. Request for self/others
2. Filter (what do they have access to request? What do they filter on (applications/roles))
3. Select Access
4. Submit Request
5. Workflow (expand data / roles, evaluate policies, obtain approvals, provision)

Manage Access Quicklinks:

● Manage User Access: Add/remove entitlements
● Manage Accounts: Request, delete, modify accounts
● Manage Passwords: Change passwords on systems managed by iiq

There are default workflows for requesting access (LCM Provisioning, LCM Manage Passwords)
that can be modified and have logic added

Quicklink Populations: Flexible method to control who can request what. Who can request
access? Who can they request access for? What can be requested?

The default populations are help desk, manager, and self-service

There are configurations for what specific quicklinks populations have access to (manage user
access, manage accounts, etc)

Only requestable entitlements, assignable roles, and permissible roles can be requested for
Population Statistics: If the requester can see population statistics, they can filter for things
like region. I.e. Region = North America, I see 20% of users in this region have the Accounting
entitlements

Once Access request is submitted, Business Process starts

By default, just the object owner approves access, but that can be customized (i.e. maybe
object owner and manager need to approve).

Attachments
● Who can access? Requester, requestee, approver, sysadmin
● Configurable: File type, is attachment required
● Limits: 20 MB size, single user request, 10 attachments per request

A sunrise and sunset date can be added, for the role to be activated on one date, and disabled
on another. (Global Settings >> IdentityIQ COnfig >> Roles)

Roles can be schedules for activation and deactivation too

IdentityAI: Advice for approvers. Will recommend access is approved or not, and provide a
justification why.

Manage Accounts, Manage Passwords, Create/Edit/View Identity can all only act on one
requestee at a time

In Global Settings >> Lifecycle Manager you can configure which applications accept account
only requests. Then, you can request an account for people with those accounts.

Creating Identities Manually:

● Create identity quicklink (default form is shown)
● New user registration (LCM Create Identity option, disabled by default)

Identity Attributes can be edited, but only if the identity attribute is configured to not be
“permanent”

Target Mappings: Makes Attribute Synchronization easy. On the identity attribute, just like there
is source mappings, you can also set up target mappings to “provision downstream”. When
Identity Refresh with “Synchronize Attributes” is ran, it is provisioned to the target.

If identity is edited, target mappings are immediately invoked as well.

Identity Forwarding: Sending approvals to another user

Manage Accounts Quicklink: Allows you to enable, disable, unlock, delete, or request new
account
● Under the lifecycle manager settings you configure the applications that can have
accounts requested for them

Create Identity Options:

● Create Identity Quicklink: Requester has an identity
● New User Registration Link: (login page), requester has no identity

Use UIConfig to change which Identity Attributes are shown

Password Interceptor: Client runs on other apps, and if password changes, it captures it and
sends it to IIQ to sync it to other apps (Business Process in IIQ to specify)

Unexpected/undesired native changes (changes in data at app level) can trigger certifications or
emails. Configure applications to look out for native changes, and then kick off a native change
lifecycle event.

Identity Refresh with “Process Events” will trigger Native Change lifecycle events. (Best
Practice: aggregate all accounts w/o native change detection, then turn on).

Account Group Management in LCM can allow for workflows to be kicked off when something in
Entitlement Catalog changes (i.e. I update the description, update it at the app too).

Create Group: At the application, when you set up a “Create Group” provisioning policy, if
someone makes a group for that app in the entitlement catalog it will write the group to the
application.

Batch Requests: Mass updates to identities / whatever via a file being updated (enable,
disable, update, add, remove, etc)

You can terminate an employee through IIQ (immediate or delayed) -> can do a termination
request via lcm

Load balancer has Session Affinity / Sticky Sessions for the UI servers.

Task and Request service definitions define which hosts are UI and which are task (only task
processes request and task)

3ms latency needed from app server to db (do not push db across WAN).

Typical Environment Types:

● Sandbox: Running as VM, limited memory, just one developer
● Dev: A couple developers, smaller representative data
 ● UAT: Similar size as production, can be stress tested
● Prod: Maybe redundancy / failover

SSB: Created by SailPoint professional services. Automates packaging of custom objects.

Apache Ant builds the code. Can use directly or as a model

IIQ Associate Study Guide:

● For Certifications, is the Revocation phase options?
● Can groups be assigned the owner of an application?
● Can populations be assigned the owner of an application?
● How is group membership updated?
● Where in IIQ is a population defined?
● What checkbox on an account schema attribute will make an entitlement appear in the
Entitlement Catalog?
● What checkbox on an account schema attribute will make an entitlement appear under
the Entitlements section on an identity?
● What is the purpose of “multi valued” account schema attributes?
● When is attribute synch provisioned to target applications?
● Do tasks often take input from users?
● Do workflows run against identity objects?
● Do workflows take often take input from users?
● What is the definition of a workflow?
● Can tasks be scheduled?
● Can workflows be scheduled?
● In the Entitlement Catalog, is a user friendly “Display Name” stored?
● In the Entitlement Catalog, is a description of the entitlement stored?
● In the Entitlement Catalog, is there a revoker stored, so if access needs to be manually
removed it can be assigned to them?
● During the revocation phase of a Certification, does IIQ to watch to ensure that access is
removed from the identity?
● During the revocation phase of a Certification, can a user dispute removed access?
● Under the “Manage Accounts” Quicklink, can users request multiple accounts (for
applications that allow that)?
● What is the purpose of Quicklink Populations?
● Can QuickLink Populations provide access on connected applications?
● What is the purpose of Rapid Setup?
● Does the Rapid Setup Task run Rapid Setup Lifecycle Events?
● Can a change in data trigger a workflow?
● Can a change in data trigger a task?
● Does aggregating in new data trigger a lifecycle event?
● Does refresh identity with “process events” selected trigger a lifecycle event?
● Will IIQ make an identity cube if it does not correlate to an authoritative source?
● What is the purpose of the “Prune Identity Cubes” task?
● Is SailPoint’s default behavior to ignore Application Accounts that do not correlate?
● Can the default correlation config be disabled?
● Does an Application’s “Connector” determine the Application name?
● Does the Application definition contain metadata about the application like owner and
connection details?
● Does the implementer always need to manually define the application schema?
● Do the configuration parameters available for the connector (user, pass, etc) change
based on the application type?
● If the application type is flat file, does that mean the provisioning will write to that file?
● Do quicklinks run tasks?
● Do quicklinks run workflows?
● Are tasks stored in a file server external from IIQ?
● Are workflows stored in a file server external from IIQ?
● Do identity attributes generally get derived from application account attributes?
● Can identity attributes be changed via the UI?
● Can managers be correlated manually?
● Can uncorrelated accounts be correlated manually?
● Does running advanced analytics trigger a workflow?
● Can populations and groups be filtered on when running reports?
● Is the account schema required for applications?
● Can the identity refresh task take a filter to control which subset of identities are
refreshed?
● If provisioning Attribute Synch of an identity attribute to a target application and the
provisioning fails, does that mean the identity attribute will be reverted to its previous
value?
● Does LCM allow you to configure multiple approvers?
● Does LCM allow you to configure no approvers?