Furqan Shaikh

A personal portfolio and blog by Furqan Shaikh, featuring technology insights and project showcases.

© 2024. All rights reserved.

Identity Model in IdentityIQ

20 Sep 2024

Discussion on Identity Model

The sources offer a detailed look at the Identity Model within IdentityIQ, a pre-built structure that simplifies how workflows interact with identity data, particularly in forms. Let’s explore its significance, structure, and usage.

Why is the Identity Model important?

Workflows in IdentityIQ often revolve around making changes to identities. Before the Identity Model, managing identity data within workflows, especially when using forms, was cumbersome. Each attribute required separate handling:

  • Defining individual business process variables for each attribute.
  • Passing each variable to and from the approval workflow.
  • Defining each variable as a form argument.

This approach led to complexity and increased the potential for errors.

The Identity Model solves these problems by representing the entire Identity as a single, manageable unit within a workflow. It acts as a container holding all relevant identity data, streamlining how workflows interact with this data, particularly in forms.

How does the Identity Model work?

The Identity Model is essentially a map (a collection of key-value pairs) populated with various identity attributes and related information. You can access this model within workflows through a dedicated library method called getIdentityModel.

What are the key components of the Identity Model?

The Identity Model includes a comprehensive set of entries representing various facets of an identity:

  • Standard and Extended Identity Attributes: This includes all basic identity attributes like first name, last name, email, manager, etc., along with any custom extended attributes defined in your IdentityIQ installation. Most are stored as strings, with multi-valued attributes represented as lists.
  • Role Information: Includes lists for both detectedRoles and assignedRoles, providing insights into the roles associated with the identity.
  • Manager Details: Stores the manager’s name as a string and provides a separate info map with additional manager information, including their ID, name, and display name.
  • Time-Related Data: Includes dates for lastRefresh, lastLogin, and passwordExpiration, offering temporal context to the identity’s activity.
  • Flags and Status Information: Contains boolean flags like isWorkgroup, managerStatus, correlated, and correlatedOverriden, along with information about assigned scopes and transformer options.
  • Object Class Information: Stores the class of the object (sailpoint.object.Identity) and the transformer class (sailpoint.transformer.IdentityTransformer) used for data manipulation.

How do I use the Identity Model in my workflows?

Here’s a step-by-step guide on utilizing the Identity Model:

  1. Define Process Variable: Create a process variable within your workflow (e.g., identityModel) to store the Identity Model.
  2. Initialize and Populate: In an early workflow step, call the getIdentityModel method from the IdentityLibrary to initialize and populate the identityModel variable. You can pass an identity name or ID as an argument to pre-populate the model with existing identity data.
  3. Link to Form: In the approval step containing your form, create an argument (e.g., workItemFormBasePath) and set its value to the identityModel variable. This creates a bridge between the form and the Identity Model, allowing data exchange.
  4. Reference Attributes: Within the form, directly reference attributes from the identityModel as if they were individual variables (e.g., use “firstname” instead of “identityModel.firstname”).
  5. Process Changes: After form submission, utilize the buildPlanFromIdentityModel() method to compare the initial and modified versions of the identityModel, identifying differences and automatically generating a provisioning plan to implement changes.

Example:

Consider a scenario where a workflow form needs to display and allow editing of ten identity attributes. Without the Identity Model, you would manage ten separate variables. The Identity Model simplifies this by storing all attributes within a single identityModel variable. When the form loads, it accesses and displays these attributes. After the user edits and submits the form, the workflow compares the updated identityModel with its original state and provisions any necessary changes to the identity object. This streamlined process reduces complexity and potential errors.

Additional Notes:

  • While the sources focus on the Identity Model’s role in workflows and forms, its utility may extend to other areas where streamlined identity data management is beneficial.

  • The sources provide a basic outline and usage pattern for the Identity Model. Further customization and advanced implementations might require deeper exploration of IdentityIQ’s API documentation and potentially involve custom coding.

By incorporating the Identity Model, IdentityIQ empowers organizations to handle identity data within workflows more efficiently, especially when forms are involved. It reduces the complexity of managing individual attributes, simplifies form interactions, and ultimately leads to a more robust and maintainable identity management system.

Integrating SailPoint with CyberArk Using SCIM Server Without AIM Credential Provider

19 Sep 2024

Introduction

Integrating SailPoint with CyberArk allows for streamlined identity governance and privileged access management (PAM). With CyberArk’s SCIM (System for Cross-domain Identity Management) server, organizations can manage privileged accounts and users in SailPoint without relying on the AIM Credential Provider. This post will walk you through the steps of setting up a SailPoint-CyberArk integration using the SCIM server, enabling you to query, modify, and manage privileged data without the AIM Credential Provider.

Prerequisites

Before starting the integration, ensure the following components are installed:

CyberArk Requirements:

  • CyberArk SCIM Server v1.3.5 or above
  • CyberArk Vault (with PACLI for querying and managing privileged data)

SailPoint Requirements:

  • SailPoint IdentityIQ v7.1 patch 2 or above
  • SailPoint PAM Module

System Requirements:

  • Windows Server 2016 or 2019
  • Java Version 1.8 (64-bit OpenJDK recommended)
  • 8-core Processor, 32 GB RAM

Step-by-Step Guide

1. Download and Set Up SCIM Server

  1. Download the CyberArk SCIM distribution from the CyberArk Marketplace.
  2. Extract the contents from the zip file and move the CyberArk-SCIM folder to your C:\ drive.
  3. Verify that the folder contains essential files:
    • CAScimServer-<version>.jar
    • PACLI
    • Configuration files (e.g., config.yml, globalConfig.yml)

2. Install Java

SCIM server requires Java to function. Follow these steps to install and configure Java:

  1. Download Java 1.8 (64-bit version) from here.
  2. After installing Java, set the %JAVA_HOME% environment variable:
    • Open System Properties > Advanced > Environment Variables.
    • Add C:\Program Files\Java\bin to the system’s path.

3. Pre-installation Configuration

Before proceeding with the SCIM installation, configure the environment variables and ensure system readiness:

  1. Configure PACLI Path:
    • In the system environment variables, append the PACLI path to the system’s Path variable: C:\CyberArk-SCIM\PACLI.
  2. Enable CyberArk Vault Platform:
    • Log in to the CyberArk PVWA as an admin.
    • Navigate to Administration > Platform Management and activate the CyberArk Vault platform.

4. Install and Configure SCIM Server

  1. Open a command prompt as an administrator and navigate to the C:\CyberArk-SCIM directory.
  2. Run the SCIM installation command: 
    SCIMInstaller.exe -SailPoint

    Note: The -SailPoint flag is case-sensitive.

  3. Follow the installation prompts, including entering the necessary Vault and SCIM configuration parameters from your pre-installation checklist.

5. Configure SailPoint to Communicate with SCIM Server

  1. Create a privileged account in the CyberArk Vault for SailPoint integration.
    • This account will be used by SailPoint to authenticate against the CyberArk SCIM server.

  2. Modify the globalConfig.yml in the CyberArk-SCIM folder to reflect the SailPoint-specific configurations.

  3. In SailPoint, configure a new CyberArk application in IdentityIQ using the following information:
    • SCIM Server URL: http://<SCIM_Server_IP>:8080/CyberArk/scim/v2/
    • Authentication: Use basic authentication with the SailPoint-user account created in CyberArk.

6. Testing the SCIM Server

Test the SCIM server by accessing the Swagger UI:

  1. Open a browser and navigate to: 
    http://<SCIM_Server_IP>:8080/swagger

  2. Test basic SCIM operations, such as querying users and groups, to ensure the server is operational and configured correctly.

  3. Alternatively, use the following curl command to test connectivity: 
    curl -u SailPoint-user:<password> http://<SCIM_SERVER_IP>:8080/CyberArk/scim/v2/ResourceTypes

7. Configure OAuth for Secure Authentication (Optional)

If you want to integrate OAuth for additional security, configure it in the globalConfig.yml:

  1. In SailPoint, generate the required client ID and secret for OAuth authentication.
  2. Update the globalConfig.yml with your OAuth provider’s details (e.g., Azure AD or Okta): 
    oauth2:
  jwksURI: "https://login.microsoftonline.com/<tenant-id>/discovery/v2.0/keys"
  issuer: "https://login.microsoftonline.com/<tenant-id>/v2.0"
  usernameField: "preferred_username"
  3. Restart the SCIM server to apply the changes.

Conclusion

By following these steps, you can integrate SailPoint IdentityIQ with CyberArk using the SCIM server without relying on the AIM Credential Provider. This setup allows you to manage privileged accounts and users seamlessly through SailPoint’s PAM module, ensuring secure and efficient access management.

Additional Resources

CyberArk SCIM Server Authentication Using Credential Files

19 Sep 2024

CyberArk SCIM Server Authentication Using Credential Files

The CyberArk SCIM server can authenticate to the CyberArk Vault using credential files, which is CyberArk’s recommended method for enhanced security. This method avoids storing passwords directly and instead uses dynamically rotated credentials retrieved on demand.

Here’s how the process works:

  1. Credential File Creation:
    • First, you need to identify the username associated with the SCIM-account object in the SCIM Config safe. This information is stored in the “UserName” file category property of the SCIM-account object.
    • Next, create a credential file using the CyberArk CreateCredFile utility. The file name should be the same as the username identified in the previous step, with a “.cred” extension. For example, if the username is “SCIM-user”, the credential file should be named “SCIM-user.cred”.
    • The CreateCredFile utility takes several parameters, including the username, password, hostname, and entropy file. The specific command to create the credential file is provided in the sources.
  2. Credential File Placement: Once the credential file is created, it needs to be placed in the c:\CyberArk-SCIM folder along with its associated entropy file.
  3. SCIM Server Authentication: When the SCIM server needs to authenticate to the Vault, it first checks for a credential file with the name “SCIM-user.cred” in the c:\CyberArk-SCIM directory. If this file is found, the SCIM server uses the username from the credential file and the credential itself to authenticate to the Vault. The AIM Credential Provider is not used in this scenario.
  4. Automatic Password Change: When using credential files, the automatic password change feature is enabled. This means that every time the SCIM server logs into the Vault, a new randomized password is generated and updated in both the authentication file and the Vault.

Fallback Mechanism:

If a credential file named “SCIM-user.cred” is not found, the SCIM server will attempt to authenticate using the AIM Credential Provider.

Log Verification:

The sources provide examples of debug and trace logs that can be used to verify whether the SCIM server is using a credential file or the AIM Credential Provider for authentication.

Additional Notes:

  • The sources highlight that using the default authentication method (user-password credentials stored in the vault) can expose the password in Windows Audits if this feature is enabled at the OS level.
  • For existing SCIM server installations (version 1.3.4 and earlier), CyberArk recommends upgrading to version 1.3.5 or later to take advantage of the credential file authentication method.

By using credential files, the CyberArk SCIM server benefits from a more secure authentication method, reducing the risks associated with storing and managing passwords directly.

What are the two internal authentication methods available for the CyberArk SCIM server?

The two internal authentication methods available for the CyberArk SCIM server are:

  • CyberArk Credential Files (Recommended): This method, introduced in SCIM version 1.3.5, enhances security by using dynamically rotated credentials instead of a stored password. CyberArk recommends this method.

    To implement this method, a credential file containing the username from the SCIM-account object must be created and stored in the c:\CyberArk-SCIM folder. When the SCIM server needs to authenticate to the Vault, it will prioritize using this credential file over the AIM Credential Provider.

  • Username-password credentials stored in the vault (default): This method uses the AIM Credential Provider to retrieve the username and password for the SCIM server from the CyberArk Vault. This method is the default but is less secure than using credential files because it requires storing the password in the Vault. The sources note that this method can expose the password in the Windows audit logs if Windows Audits is enabled at the OS level.

The sources recommend using credential files over the AIM Credential Provider and suggest upgrading to SCIM Server version 1.3.5 or later to utilize this authentication method.

Configuring a Private Server for IdentityIQ's Microsoft Teams Service Code

22 Jul 2024

Configuring a Private Server for IdentityIQ’s Microsoft Teams Service Code

The sources provide a detailed explanation of how to configure a private server to host IdentityIQ’s service code for Microsoft Teams integration. Here’s a breakdown of the process and key recommendations:

Server Selection and Setup:

  • Dedicated Server: SailPoint strongly recommends using a separate, private server to run the IdentityIQ service code, distinct from the IdentityIQ application server. This enhances security by preventing direct internet exposure of the IdentityIQ server.
  • Operating System Support: The Microsoft Teams bot is compatible with all currently supported Windows and Linux versions. Choose the operating system that best suits your environment and expertise.

Network Connectivity and Security:

  • Public IP and DNS Resolution: Ensure the private server has a public IP address that’s publicly resolvable via DNS. This allows Microsoft Teams to establish a connection to the service code.
  • HTTPS and Valid Certificate: Enable HTTPS on the private server and install a valid SSL certificate from a Microsoft-trusted Certificate Authority. This establishes a secure communication channel and is essential for Microsoft Teams to trust the service code. Self-signed certificates are not supported.
  • Firewall Configuration: Configure your firewall to allow inbound traffic on the designated HTTPS port for the service code. This ensures Microsoft Teams can reach the service code without any blocks.

Service Code Installation and Configuration:

  1. Download Platform-Specific Package: Download the appropriate service code package for your chosen operating system (Windows or Linux) from Compass.
  2. Extract and Configure Environment File: Extract the downloaded zip file on the private server. Locate the env.template file and create a copy named .env. This file contains environment variables that need configuration.
  3. Configure Essential Parameters: Edit the .env file with the following crucial parameters:
    • PUBLIC_HOSTNAME: Set this to the public DNS hostname of your service code, resolvable to the private server’s IP address.
    • LOCAL_HOSTNAME: Enter the private IP address of the server where the service code runs.
    • PUBLIC_PORT and PRIVATE_PORT: Specify the desired public and private ports for hosting the service code. The default values can be modified as needed.
    • TENANT_ID: Input your Azure tenant ID.
    • APP_ID: Enter the Application (client) ID of your Microsoft Teams app from Azure.
    • APP_NAME: Provide the name of your Microsoft Teams app.
    • SSO_CONNECTION_NAME: Input the name you assigned to the OAuth connection setting while configuring the Azure bot.
    • ENCRYPTION_SECRET: Set an 8-character secret for encrypting sensitive data.
    • IIQ_URL: Enter the full URL of your IdentityIQ installation, including the protocol, hostname, port, and context path. Use the load balancer URL if applicable.
  4. Encrypt and Set App Secret: Start the service code and use the provided encryption endpoint (https://<private IP>:<private port>/util/encrypt) to encrypt your Microsoft Teams app secret. Set the encrypted value as APP_SECRET in the .env file.
  5. Certificate and Key Configuration:
    • Create a dedicated directory (cert) within the service code directory to store the SSL certificate and private key.
    • Obtain the SSL certificate and private key files from your certificate provider.
    • Place the certificate file (e.g., certificate.crt) and private key file (e.g., private.key) inside the cert directory.
    • Encrypt the certificate and private key using the encryption endpoint mentioned in the previous step.
    • Update the .env file with the encrypted certificate and key values:
      • BOT_CERTIFICATE: Encrypted certificate value.
      • BOT_KEY: Encrypted private key value.
  6. Permissions and Ownership:
    • Set strict read and write permissions on the cert directory, granting access only to the owner of the service code process. This enhances the security of your sensitive key material.
  7. Start and Verify Service Code: Start the IdentityIQ service code. You should see log messages indicating a successful start and connection to Azure services. Verify that the bot responds correctly to commands within Microsoft Teams.

Additional Considerations:

  • Microsoft Azure Configuration: The sources emphasize that successful integration requires specific configurations within Microsoft Azure, such as creating an API application, a Microsoft Teams application, and an Azure bot. The provided steps outline the required settings and values to ensure seamless communication between IdentityIQ and Microsoft Teams.
  • Security Best Practices: The sources recommend following security best practices throughout the configuration process. This includes using strong encryption for sensitive data, restricting file permissions, and regularly reviewing security settings.

This comprehensive guide to configuring a private server for IdentityIQ’s Microsoft Teams service code is based entirely on the information available within the provided sources. Remember to consult the Microsoft Teams documentation and your IT security team for any platform-specific or security-related considerations.

Two Main Tasks in Configuring a PAM Application

19 Jul 2024

Two Main Tasks in Configuring a PAM Application

The two main tasks for configuring a Privileged Account Management (PAM) application in IdentityIQ are:

  1. Configuring a PAM Application: This task involves setting up a connection between IdentityIQ and your PAM vendor’s system to aggregate data on PAM accounts, groups, vaults, and permissions.

    • This process utilizes a PAM-specific application (connector) type called “Privileged Account Management”.
    • You need to configure the application to include both a connector and a target collector:
      • The connector is responsible for aggregating users, groups, and containers into IdentityIQ.
      • The target collector reads in permissions users have on containers, and can write permissions back to the target system.
    • The PAM connector, based on IdentityIQ’s SCIM 2.0 connector, requires configuration details like Base URL and authentication methods (OAuth2.0, API Token, or Basic Authentication).

  2. Configuring PAM Global Settings: This task focuses on setting up global options for the PAM module within IdentityIQ.

    • These settings control aspects like how PAM containers can be modified within IdentityIQ.
    • You can define whether to allow adding/removing identities and privileged items in PAM containers, and whether to enable owners to modify PAM containers.
    • Global settings also dictate the business process used for provisioning PAM identities. You can either utilize the standard LCMManage Passwords business process or define a custom workflow of type LCMProvisioning.

These two tasks are essential for setting up the PAM module in IdentityIQ. While these tasks establish the foundation for PAM integration, the sources also highlight additional configurations related to credential cycling, Rapid Setup processes, and task management for aggregation, indexing, and refreshing PAM data.