<----- HighLights ----->

• SAILPOINT IdentityIQ integrates provisioning and compliance features into a single solution. Thus this IDM product is able to address all the needs related to Identity and Access Management such as Access Certifications, Policy Enforcement, Account Provisioning, and User Life-Cycle Management. 

Sailpoint Architecture

Organizations should be able to use their identity solution to enable clear and comprehensive controls on access to data and applications, allow for proper access requests, and timely provisioning of access rights, with the number of new vendors, staff, and other people come on board. 

The Architecture of SailPoint IdentityIQ  consists of four major components as follows

1) Compliance Manager

2) Lifecycle Manager

3) Governance platform 

4) User provisioning 

Advantages of Automated Identity Lifecycle Management

1) Minimizing the risk

 Users have access to the right tools for the right purposes due to Lifecycle Manager. using IdentityIQ Compliance Manager to conduct routine certification campaigns, and access checks, and provide a complete audit trail  giving  a better understanding of who has access to whom and when and where the access was given.

2) Minimizing the IT Helpdesk Load and Costs

End users should handle their own authorization requests, which relieves IT organizations of any of their workload. Business users can request full self-service access through IdentityIQ, 

3) Improve Efficiencies

automatic provisioning controls the business processes of authorizing, changing, and revoking access. Changes in user access can be provisioned 

4) Automate Policy Management

 IdentityIQ Lifecycle Manager in combination with IdentityIQ Compliance Manager to identify separation of duties (SoD) policies and other policy concepts that provide controls 

SailPoint UI (User Interface )

• Concept of Identity Cubes and Identity Attributes:

1. SailPoint IdentityIQ represents users by Identity Cubes.
2. “Cubes” are built through a discovery process from authoritative sources i.e. by bringing in user account data from Authoritative Applications and are refreshed dynamically or by running a Identity Refresh Task
3. Example of Identity attributes are Name,Email,department etc.

Identity Cubes :  Stores  all information known about an identity -: Single  Identity Cube per Person   

1. Application Account Exists inside Identity Cube     
2. Identity Attributes
3. Entitlements/Roles
4. Risk Score
5. Policy Violations
6. User Rights ( Capabilities/Scoping )

Information on the cube is : Discovered , Requested , Assigned , Calculated

Hibernate Files -  IdentityIQ allows you to customize extended and searchable attributes by editing various .hbm.xml files such as :

• IdentityExtended.hbm.xml 
• LinkExtended.hbm.xml

Identity Mapping :

Identity Attribute Page 

• Gear Icon -> Global Settings -> Identity Mapping 

• Edit and View of Identity Attributes 

• These attributes are used throughout in IIQ for searches, certification, collect and correlate identity Data 

• IdentityIQ also supports the use of Robotic Process Automation (RPA) or bot identities. A bot is an application that can perform automated tasks, especially simple, repetitive tasks such as requesting access and managing identities. 

Default Identity Attributes 

• First Name 

• Last Name 

• Email 

• Inactive 

• Manager 

• DisplayName bot Governance - Application to perform repetitive automated tasks 

• Type: Employee, Contractor, Service Accounts 

• Software Version: Software versions bot is using 

• Administrator: Owner of bot - used to certify the bots 

Additional Attributes

• Attribute Name: camelCase 

• Display Name: Readable Text 

• Attribute Type: String, Identity 

• Edit Mode: 

        – Read only: attributes cannot be edited from Identity Pages

        – Temporary: editable from UI, Attributes will overwrite through refresh task 

       – Permanent: editable from UI and Attributes will not overwrite during refresh task

Identity Attribute: Searchable 

• Searchable: Filtering and Searching through IdentityIQ 

   • All non searchable attributes are store in Database as CLOB(character large Object) 

 • Searchable attributes: stored on seperate column of Database hence easy to search from DB 

    – extended column 

    – named column 

             • Searchable attributes can be used directly in Filters and Advanced Intelligence 

Identity Attribute: Non Searchable 

Identity Attribute: Searchable 

• Stored in Separate Column 

• Pre configured searchable Attributes: 10 

• Pre configured searchable Attributes: extended upto 20 

    – database column will be: extendedXX 

        – XX can be next available number between 1-20 

• named searchable attribute (for more than 20) 

Identity Attributes 

• Multi-valued: for attributes for which multiple values might returned in aggregation – stored as a list

 • Group Factory: This can be used to create groups 

         – you think that attribute can used for anlytical purpose 

         – default attribute: manager 

Value Change Rule and Workflow 

• Runs everytime a change is detected on the attribute during aggregation 

• senario: if you want to send a notification • old value and new value is present implicitly 

• business Process to run when a change is detected in aggregation 

Source Mapping :-

 • Application - attribute pair 

• list of application - attribute pair 

• priority: Top to bottom 

Target Mapping :- Target Mapping is used to synchronize the attributes from SailPoint to Target applications.

Target Attribute Syncronization  :-

• Not all connector supports 

• Edit of an identity attribute will sync data to target application attribute. 

Refresh task must have this option checked, you will see provisioning requests in your Refresh Task result.

 

• NOTE: 

• do not set source and target mapping of same application-attribute pair, it creates circular references where value continuously changes with every attribute sync

• Provision All Accounts: Incase if user has more than 1 account in your Target application, then SailPoint doesn’t know in which account it needs to update. So you select that checkbox, so that it will update in all the accounts under same target application for that user.

• Transformation Rule: As the name indicates, if you need to transform the value.
  For example, if Job title is Senior Analyst but your target system would like to have the value as Sr. Analyst, then you need to write some script to change the value accordingly.

Work Item :-

• Native Change Detection : 
                                       
Native change detection is a mechanism in IdentityIQ's application connectors that can detect changes made in account information outside of IdentityIQ's control. The native change detection can detect newly created accounts, deleted accounts or modified accounts. The changes are detected on aggregation by comparing stored information with newly read information. If any changes are detected, actions can be taken to respond to these changes. These actions include automatic re-certification, approval, notifications or even automatically reverting the changes.


           NCD occurs in an application that means if any changes like ( creation / modify / deletion ) on application attributes that clearly tells directly on  target application attributes , then those changes reflects in IdentityIQ during aggregation or refresh task. 
           So it clears that how NCD and the associated Lifecycle Event works.

• Delta Aggregation

A delta aggregation on a source only loads the accounts that have been created, changed, or deleted since the most recent aggregation. For example, if one of your users changes their phone number in Active Directory, you can aggregate only that user instead of all of the accounts. This can speed up the process of loading changes from your source.

IdentityIQ will ask the source system to return records which have changed since the last aggregation is the functionality of delta aggregation.

For delta aggregation, it is not IdentityIQ that makes the decision, it is the source system that does that.

How this works depend on the source system or connector:

• For directories connectors (for e.g. LDAP, AD), there could be a change log or last modification timestamp that is used to figure out what has changed,
• For database a special table needs to be created to keep track of added, updated and removed records and a trigger to fill this table. The JDBC connector will check the table for changes (like a change log in LDAP) and then get the relevant records one by one.

NOTE: Not all connectors support delta aggregation. For e.g. a delimited file does not have any information about changes, thus the connector does not and cannot support delta aggregation.

Managed attribute :

• A ManagedAttribute is essentially an entry within the entitlement catalog.  
• If the attribute is "managed" and you select 'promote managed attribute' in aggregation, then this will look at each account it is processing and determine whether the entitlement(s) on that account already exist in IdentityIQ's database or not, and if it does not exist, it will create the entitlement in the entitlement catalog. So, if you set the attribute as "managed" it can be promoted to entitlement catalog. 
• In  schema definition, there is a property that can be set on every attribute that indicates 'managed'.  Another property 'entitlement' is what tags it as an entitlement.  If it checks entitlement, managed is automatically checked. 
• The main difference is that managed entitlements would show up in places like certifications/etc., whereas managed attributes (not marked entitlement) won't.
• "multi-valued" check on a schema attribute make that attribute a "managed attribute" or not, the answer is "No".
• For Multi-valued, attributes flagged as multi-valued are stored as a list. Even objects that have a single value for a multi-value attribute are stored as a single-item list. Multi-valued attributes are used for queries throughout the IdentityIQ. Before multi-valued attributes are available for use in searches, they must be mapped on the Edit Account Attribute page. 
• For Managed, specify attributes to promoted to a first-class object in the IdentityIQ database so that they can be associated with other objects with that value, for example a description or an owner. Any attribute can become managed: department, location, title, but the most common attribute to be managed is the one holding group memberships. Managed attributes can be viewed and managed from the Entitlement Catalog page.

• Orphan Accounts :          Every account always becomes part of an identity. So if a newly read account cannot be  "correlated " to an existing identity , a new identity is formulated or can say is created.    If the application from which the account is coming is not marked as " authoritative " the account or identity is considered " unauthoritative " or " orphaned " so when run aggregation process on authoritative application , accounts those are not correlated successfully goes into " Orphan Accounts ".                                                                                                                                                                                 
• CDATA :

typing lists is not supported in Beanshell.

"&lt;" isn't the equivalent of "<," that would just be "<" whereas "&" is the equivalent of "&"

So, what you have (&lt;) means "<" which the Beanshell interpreter.

Best to avoid such issues by using the CDATA

• AuditConfiguration :

• QUICKLINK :

QuickLinks objects are used in IdentityIQ to provide one-click access to areas of IdentityIQ functionality.  
Custom QuickLinks are most typically used to launch workflows, link directly to other pages in the IdentityIQ user interface, and launch external web links.

These custom QuickLinks can do any of these things:

1.  Launch a custom workflow
2.  Launch an external web link
3.  Directly link to other pages in the IdentityIQ UI

The most popular use case for custom QuickLinks is using them to launch workflows. 

Note : To restrict quick-link need to configure DynamicScopes as : 

• DynamicScopes :

DynamicScopes  indicates who could see and use the QuickLinks; now they also specify the set of target users and objects the QuickLink can operate on , means for each QuickLink associated to a DynamicScope to allow set of users to see and use the link.

Example 1: Exclusions

By combining allowAll and an Exclusions list, this DynamicScope can grant access to all users except the specifically named identities.

Example 2: Match List IdentitySelector: Capabilities

This DynamicScope’s IdentitySelector is constructed as a MatchExpression which is examining each Identity’s Capabilities list.  Any Identity with the “ApplicationAdministrator” capability will see its associated QuickLinks.

                                                                       

• IdentityIQ  Internal Terms : 

Integrating SailPoint AI Services - to integrate AI Services with IdentityIQ i.e. implementation of SailPoint AI Services in IdentityIQ by importing the AI Services init-ai.xml file into IdentityIQ:

• browse to the following directory:
  identityiq_home\WEB-INF\config
  where identityiq_home is the directory in which you extracted the identityiq.war file during the IdentityIQ installation procedure.

• Select the init-ai.xml file and click Import.

Note: -

• Plugins must be enabled in IdentityIQ for AI Services to be installed. Ensure that plugins.enabled=true in the identityiq_home/WEB-INF/classes/iiq.properties file of your installation.
• Integrating AI Services with IdentityIQ helps your organization determine who should have access to what. AI Services uses peer group analysis and identity attributes to recommend access to your users, and to help certifiers decide when user access should be approved or denied. AI Services can also identify user access patterns to determine potential roles that accurately align with what users actually do in an organization                                                                           

1.                           Decision Recommendations 
2.                          Access Request Recommendations  
3.                          Automatic Approvals

IdentityIQ Plugins

The SailPoint Plugin Framework is an extension framework model for IdentityIQ. It enables third parties to develop rich application and service-level enhancements to the core SailPoint platform. It enables plugins to extend the standard user interface, deliver custom REST endpoints, and to deliver custom background services.

A plugin can be a simple REST service or a full page application on top of IdentityIQ. A plugin can include one or all of the following:

• A client side front end

• REST web services

• ServiceDefinition, PolicyDefinitions, and TaskDefinition implementations

• Java classes available for scripting

• Custom plugin configuration

• Database tables

During your initial installation, IdentityIQ is set up to work with plugins. A separate plugin table, identityiqPlugin, is created as part of the database schema creation scripts and the plugins.runSqlScripts, plugins.importObjects, and plugins.enabled properties are set to true in the iiq.properties file.

Working with Plugins in IdentityIQ

The plugin feature must be enabled in IdentityIQ and you must have the proper access, such as System Administrator or Plugin Administrator capabilities, before this page can be displayed.

The Installed Plugins page displays and enables you to manage your plugins from within IdentityIQ. Open the page by selecting Plugins from the list under the gear icon.

From the Installed Plugins page you can install, uninstall, enable, disable, and configure your plugins.

• Install – click New and either drag and drop a zip file onto the page, or navigate to the directory containing the plugins.

• Enable/Disable – click the power button icon to enable or disable plugins. You will be asked to confirm your decision.

• Uninstall – click the X icon to uninstall a plugin.

Developing Plugins

IdentityIQ stores the .zip archive file of the Plugin in the IdentityIQ database in a data LONGBLOB in the spt_file_bucket table. The data in the spt_file_bucket table is referenced ID to an entry in the spt_persisted_file table.

Plugins are loaded from this .zip file after installation or after an application server restart. The .zip file is extracted, and all important files are cached for later use. There are several accessor methods to reference the cached files, but they can also be referenced by the url prefix /identityiq/plugin/pluginName followed by the path found in the build structure. Compiled java classes are loaded and cached from the .zip archive using the PluginClassLoader class.

SSL certificate 

SSL certificates are what enable websites to use HTTPS, which is more secure than HTTP. An SSL certificate is a data file hosted in a website's origin server. SSL certificates make SSL/TLS encryption possible, and they contain the website's public key and the website's identity, along with related information.