I have set up IIQ in local Environment , how i can find dummy files to set up application onboarding?

Which IIQ version are you inquiring about?

*8.4

  • Hi, I am new to SailPoint IIQ, recently I have set up IIQ 8.4 in my local machine, can you please suggest resources to set up authoritative sources, account aggregation so i can practice creating workflows and rules?

You can use delimited files as well as MySQL application to give a try. Youtube how to onboard them

Hi @utsav1998 ,

You can find some useful resources in below link -

https://community.sailpoint.com/t5/Technical-White-Papers/IdentityIQ-Technical-White-Papers/ta-p/169455

https://community.sailpoint.com/t5/IdentityIQ-Forum/What-Is-an-Authoritative-Application/m-p/203814

1 Like

Hi @utsav1998, you can refer this guide.8.4 IdentityIQ Application Configuration Guide - Compass
It walks you through setting up applications, configuring authoritative sources, performing account aggregation.

1 Like

Hello @utsav1998

You can create your own resources, It’s your own local instance – your game, your rules. If you need a structured approach to follow, I’d recommend you to follow the SailPoint given course in Identity University.

IdentityIQ Essentials

1 Like

Honestly , if you really want to Integrate think big.
Download this DataSet.
sailpoint-iiq-docker/iiq-build/sql/employees.zip at 2e1546f1634f36c8bfc172c3b2052c18b36c9704 · drosenbauer/sailpoint-iiq-docker

unzip it and run the sql command to create an HR Application.

echo “=> Importing example company data for HR”
cd /opt/sql
unzip -q employees.zip
mysql -uroot -p${MYSQL_ROOT_PASSWORD} -h${MYSQL_HOST} < /opt/sql/employees.sql

This data closely resembles a real world database.

Procedurally generated HR Data

By default, a demonstration set of HR data is imported into the MySQL database to hr.hr_people. SELECT access to this table is granted to the identityiq user. In the Compose and Swarm modes, this database is accessible as db.

All data is procedurally generated by a program developed at IDW. No record is intended to resemble any real-life individuals.

Description of the data

This data represents an imaginary medium-sized grocery store corporation.

The data has these properties:

  • There are around 8,500 full-time and part-time employees.
  • There are two affiliate companies (Primary Grocers Inc and Affiliate Grocers Inc) which have separate manager hierarchies and locations.
  • A few people may have a record at more than one company. For example, Jim worked as a cashier at Affiliate, then quit, then later took a job at Primary.
  • Rehire practices are perfect. Identities will have no more than one record per company.
  • The manager hierarchy is a consistent tree with multiple layers of managers depending on department size. Managers are mapped by employee number.
  • The full assortment of employment situations is represented: hired but not started, current employee, future end dates, terminated, rehired.
  • A small subset of users are current employees on leave (status L).

The employee_number field is intended as the unique ID.

Fake SSNs

The dataset includes an ssn field with SSN-formatted randomly generated values. These values begin with 9xx so are not valid SSNs. This field is intended for demonstrating or practicing PII management.

Additional datasets are available!

Arbitrarily larger or smaller randomly-generated HR data sets are available on request.

We also have generated higher ed identity datasets. These feature common higher-ed situations like:

  • Users coming from multiple simultaneous data sources (applicants, students, faculty, staff, alumni, contractors)
  • Users having different lifecycles per affiliation
  • Class and degree history
  • Decades of alumni
  • Affiliated hospital staff who may also be professors
  • Corrupted or mistaken data from some sources

University data sets can be as small as 4,000 identities or as large as several million.

Target database

A pair of provisioning target tables are also created in the MySQL database under the database target. These tables are defined in iiq-build/sql/target.sql. They are:

  • users: A table containing user details, such as username, first name, and last name. The table is pre-populated with a system administrator user called admin.
  • roles: A table containing roles, intended for use as entitlements. The roles are all pre-populated.
  • roles_users: A table joining users to the roles they are assigned.
  • roles_permissions: Associates roles (by name) with permissions. Each role can have more than one permission. The permissions are pre-populated. These can be used for playing with SOD policies.

Full CRUD access to these tables is granted to the identityiq user.

1 Like

Thank you everyone for the prompt reply, I am going to follow Identity IQ essentials to learn and replicate the demo, if possible,

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.

@SuryenduB I am glad that you found my co-worker @drosenbauer’s project and Employee Data Set helpful. It is a good way to get started testing JDBC Connectors, or as the basis of your own home grown connector. Here at Instrumental Identity, we have used it to develop test Web Services.

In the future, it would be good if you could link back to the configuration code you copied (Found here: sailpoint-iiq-docker/iiq-build/entrypoint.sh at d0043ea09c90448cfb60d23bd7ebc620b75d2132 · drosenbauer/sailpoint-iiq-docker · GitHub) and the documentation (Found here: sailpoint-iiq-docker/HRDATA.md at d0043ea09c90448cfb60d23bd7ebc620b75d2132 · drosenbauer/sailpoint-iiq-docker · GitHub) rather than copying it verbatim without acknowledging where you obtained it from. This will allow this topic to always have the latest information, as he does update it from time to time. It will also allow others to know where to ask questions, or how to request the alternate data sets that are mentioned as available.