Connectors

• ⏰ Getting started
• AWS Connector
• AWS Connector
• CSV Connector
• CSV Connector
• Customizable CSV file (CSV Connector type)
• Google Apps Connector
• Google Apps Connector
• JSON REST Web Services Connector
• JSON REST Web Services Connector
• JSON REST Web Services Connector - Properties
• How to configure the Office 365 agent?
• How to configure the Jira Atlassian agent?
• LDAP Connector
• LDAP Connector
• Oracle Connectors
• Oracle Connector
• Oracle EBS Connector
• SAP Connector
• SAP Connector
• SCIM Connector
• SCIM Connector
• Shell Connector
• Shell Connector
• Invoker interface
• SQL Connector
• SQL Connector
• SQL Integration flows - Update user
• Windows Connector
• Windows Connector
• HOWTO SSL access to Active Directory
• Invoker interface for Active Directory
• Active Directory back channel configuration
• AD Integration flows - Update user
• AD Integration flows - Update account
• Zarafa Connector
• Zarafa Connector
• SQL Server
• SQL Server Connector
• Connectors Examples
• Attribute mappings examples
• Outgoing triggers examples
• Incoming triggers examples
• Triggers: Script Tips

⏰ Getting started

Introduction

Soffid provides the connectors needed to provision accounts on the most widely used systems. To set up this connection it is necessary a specific connector addon that you must install and configure in the Soffid console.

First of all, yo must download the specific connector for your system, then install it in the Soffid console, and finally configure an agent in the Soffid console.

Download

The open-source connectors available for Soffid IAM can be found on the project website http://www.soffid.com/download in the Connectors section.

To download enterprise connectors from http://download.soffid.com/download/enterprise/ a Soffid user with authorization is required to access this functionality.

Installation

1. Once the connector is downloaded, please log in to IAM Console.

You need to be an administrator user of the Soffid console or a user with permission to upload addons.

It is recommended to upload the addons to the master, this is the way to maintain updated all, master and tenants if there are.

2. In the Soffid console, please go to:

Main Menu > Administration > Configure Soffid > Global Settings > Plugins

3.  Then, click the add button (+) and pick the file and Soffild will upload the addon file.

4. Finally, when the addon is installed, it will be required to restart the Soffid Sync server.

5. Once the Sync server is restarted, you could check the plugin was uploaded properly on the plugins page:

Main Menu > Administration > Configure Soffid > Global Settings > Plugins

6. Now, you can set up the connector.

Configure Agent

Once the plugin has been uploaded and installed, the next step will be to set up the agent, this is the step where you establish a relation between Soffid and your managed system.

Main Menu > Administration > Configure Soffid > Integration engine > Agents

More information about how to configure agents can be found on the Agents page.

Connector List

Here you will find all the information needed about the available Soffid connectors to integrate external managed systems. If you miss something important, don't mind making suggestions using contact@soffid.com.

1. AWS Connector
2. CSV Connector
   • Customizable CSV file (CSV Connector type)
3. Google Apps Connector
4. JSON REST Web Services Connector
5. LDAP Connector
6. Oracle Connector
7. Oracle EBS Connector
8. SAP Connector
9. SCIM Connector
10. Shell Connector
    • Invoker interface
11. SQL Connector
12. Windows Connector
    • HOWTO SSL access to Active Directory
    • Invoker interface for Active Directory
13. Zarafa Connector
14. SQL Server Connector

AWS Connector

AWS Connector

Introduction

Description

AWS Connector allows to manage the Amazon AWS IAM (Identity and Access Management)

Managed Systems

This connector is specific for integration with the Amazon AWS IAM (Identity and Access Management) through the CLI AWS IAM

For more information to check if your system may be synchronized with this connector, do not hesitate to contact us through our Contact form

Prerequisites

It is needed a AWS IAM user with access and privileges to the required operations.

It cannot detect password changes to be propagated to other systems.

Download and install

This addon is located in the Connectors section and its name is AWS plugin.

For more information about the installation process you can visit the Addons Getting started page.

Agent Configuration

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

To configure this AWS connector you must select "Amazon WS" in the attribute "Type" of the generic parameters section in the agents page configuration.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation:

Attribute mappings

This connector could manage Users and Roles 

Properties

The following properties are defined for each object type:

Attributes

You can customize attribute mappings, you only need to select system objects and the Soffid objects related, manage their attributes, and make either inbound and outbound attribute mappings.

Users

The following attributes can be mapped on User objects

Groups

The following attributes can be mapped on Role (AWS Group) objects:

For more information about how you may configure attribute mapping, see the following link: Soffid Attribute Mapping Reference

Triggers

You can define BeanShell scripts that will be triggered when data is loaded into the target system (outgoing triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation into target objects. 

To view some examples, visit the Outgoing triggers examples page.

Load triggers

You can define BeanShell scripts that will be triggered when data is loaded into Soffid (incoming triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation into Soffid objects.

To view some examples, visit the Incoming triggers examples page.

Account metadata

Agents allow you to create additional data, on the "Account metadata" tab, to customize the accounts created for that agent. This additional information will be loaded with the agent's information, or calculated as defined in the mappings.
The additional data can be used in both mappings and triggers.

The attributes which you define here will be shown when you click on the proper account, on the Accounts Tabs at user page.

Operational

Monitoring

After the agent configuration you could check on the monitoring page if the service is running in the Synchronization Server, please go to:

• Start Menu > Administration > Monitoring and reporting > Syscserver monitoring

Tasks

Authoritative

If you are checked "Authorized identity source", an automatic task to load identities from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will something like "Import authoritative data from <AGENT_NAME>".

Reconcile

If you are configured the "Attribute Mapping" tab with some of our objects: "user or role", an automatic task to synchronize these objects from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will do something like "Reconcile all accounts from <AGENT_NAME>".

Synchronization

Regarding the synchronization of the objects, there are two possible options:

• If you are checked the generic attribute "Read Only" in the "Basics" tab, only the changes in the managed systems will be updated in Soffid. We recommend these options until the global configuration of Soffid will be tested.
• If you are not checked the generic attribute "Read Only" in the "Basics" tab, all the changes in Soffid or the managed system will be updated in the other. Note that this synchronization must be configured in the "Attribute mapping" tab correctly.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

CSV Connector

CSV Connector

Introduction

Description

The CSV Connector provides a way to load authoritative data from fixed record size files.

Managed System

This connector has been performed to charge authoritative data from files with CSV format or other format in other extension files.

For more information to check if your system may be synchronized with this connector you do not hesitate to contact us through our Contact form

Prerequisites

The file must be placed in the same Synchronization Server host.

The file must has the correct permissions to be readed for the Synchronization Server.

Download and Install

This addon is located in the Connectors section and its name is Flat file plugin.

For more information about the installation process you can visit the Addons Getting started page.

Agent Configuration

This connector could only be used as an identity source, no output file could be generated yet.

Usually, this connector is used the first time to charge manually the user information of the identities from the HR applications o database.

As example, this is the flow to shows how the "Customizable fixed-columns file v2.0" works.

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

This addon has 5 available types:

• Customizable fixed-columns file v2.0: it is used to charge a table where each column has a fixed number of characters.
• Customizable CSV file: it is used to charge a standard CSV file (comma-separated values), where all the columns are separated by a comma.
• CSV file test agent.
• Dummy password agent.
• Test.

To configure this CSV plugin, you could select one of the previous agent in the attribute "Type" of the generic parameters section in the agents page configuration.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

The main parameters for this connectors are:

Customizable fixed-columns file v2.0

Customizable CSV file

CSV file test agent

Dummy password agent

Test

Attribute mapping

Only the "Customizable fixed-columns file v2.0" and the "Customizable CSV file" agents have this functionality implemented.

Properties

Customizable fixed-columns file v2.0

This agent requires two properties:

And after that you must specify the number of rows of every row as follow:

For instance for this file:

abernal   Antonio        Bernal         world      YES
jwayne2   John           Wayne          world      YES

These are its properties:

Customizable CSV file

This agent only needs the next properties:

Attributes

Customizable fixed-columns file v2.0

The mapping in only available for USER object.

Now we could map the system attribute defined as property values agains Soffid attributes, for instance:

For instance:

For more information about how you may configure attribute mapping, see the following link: Soffid Attribute Mapping Reference

Customizable CSV file

The mapping in only available for USER object.

The first row of the file must include the name of the attribute.

USER,FIRSTNAME,LASTNAME,GROUPNAME,ACTIVE
abernal,Antonio,Bernal,world,YES
jwayne2,John,Wayne, world,YES

Now we could map the system attribute (file) with the Soffid attributes, for instance:

Load Triggers

You can define BeanShell scripts that will be triggered when data is loaded into Soffid (incoming triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation into Soffid objects.

To view some examples, visit the Incoming triggers examples page.

Account metadata

Accounts are default objects in Soffid. Agents allow you to create additional custom data, on the "Account metadata" tab, to customize the accounts created only for that agent.

The attributes which you define here, will be shown when you click on the proper account, on the Accounts Tabs at user page.

At this tab you could add or delete custom attributes. You can visit the Metadata page for more information about the standard attributes.

Operational

Monitoring

After the agent configuration you could check in the monitoring page if the service is running in the Synchronization Server, please go to: 

• Start Menu > Administration > Monitoring and reporting > Syscserver monitoring

Tasks

Authoritative

If you are checked "Authorized identity source", an automatic task to load identities from the managed system to Soffid is available, please go to 

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will something like "Import authoritative data from <AGENT_NAME>".

Reconcile

If your are configured the "Attribute Mapping" tab with some of our objects: "user", an automatic task to synchronize these objects from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will do something like "Reconcile all accounts from <AGENT_NAME>".

Synchronization

Regarding the synchronization of the objects, there are two possible options:

• If you are checked the generic attribute "Read Only" in the "Basics" tab, only the changes in the managed systems will be updated in Soffid. We recommend these options until the global configuration of Soffid will be tested.
• If you are not checked the generic attribute "Read Only" in the "Basics" tab, all the changes in Soffid or the managed system will be updated in the other. Note that this synchronization must be configured in the "Attribute mapping" tab correctly.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Customizable CSV file (CSV Connector type)

Introduction

Description

The CSV connector type allows users to load a collection of data stored into a plain CSV file.

In the following page, the process to complete the CSV connector setup will be explained.

To begin with,  address to the quick start section. 

Quick start

The core of Customizable CSV file connector is located under the 'Attribute Mapping'  tab.

There are two important sections:

Property

File information related configuration.

 System attribute

Mapping between CSV fields and Soffid objects.

Taking a look to the configuration used, we can see that:

• System objects is the entity to load (user, account, group, role).
• System attributes fields match the columns defined into the 'file.csv'.

To demonstrate Soffid flexibility in terms of agent customization, notice that:

USERNAME, NAME, LASTNAME fields, correspond to default fields from User object.

NDI is a custom field defined into the User object.

"I" is a 'char' literal that indicates the UserType.

• Soffid attributes match Soffid specification model object.

Example

Useful information

Google Apps Connector

Google Apps Connector

Introduction

Description

Google Apps Connector allows you to manage users and groups using the Google Directory API.

Managed System

This connector is specific for integration with the Google domain.

For more information to check if your system may be synchronized with this connector do not hesitate to contact us through our Contact form

Prerequisites

To get a service account and a private key, please follow this link: Creating a service account. You must:

• Register a new project
• Enable AdminSDK API
• Register a new OAuth service account. Store the JSON generated file in a secure place.

Furthermore, you will need to follow this guide to enable the recently created account to use directory API services. The scopes to grant are:

• View and manage the provisioning of groups on your domain: https://www.googleapis.com/auth/admin.directory.group  
• View and manage group subscriptions on your domain: https://www.googleapis.com/auth/admin.directory.group.member 
• View and manage organization units on your domain: https://www.googleapis.com/auth/admin.directory.orgunit  
• View and manage the provisioning of users on your domain: https://www.googleapis.com/auth/admin.directory.user

Download and Install

This addon is located in the Connectors section and its name is Google Apps plugin.

For more information about the installation process you can visit the Addons Getting started page.

Agent Configuration

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

To configure this Google Apps Connector you must select "GoogleApps" in the attribute "Type" of the generic parameters section in the agents page configuration.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation:

Attribute mapping

This connector could manage users and groups.

Properties

Nothing to configure.

Attributes

Users

Users and shared accounts can be customized. The next attributes are required:

To get an extensive list of attributes supported by Google, browse to Google User API

Soffid groups can be mapped as OrgUnits.

Groups

Mails alias will be automatically bound to users without any further configuration.

Roles and Mail Lists will also be created and maintained as Google Apps groups.

For more information about how you may configure attribute mapping, see the following link: Soffid Attribute Mapping Reference

For instance:

Triggers

Nothing to configure. This option is not available to Google apps connector.

Load Triggers

You can define BeanShell scripts that will be triggered when data is loaded into Soffid (incoming triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation into Soffid objects.

To view some examples, visit the Incoming triggers examples page.

Account metadata

Agents allow you to create additional data, on the "Account metadata" tab, to customize the accounts created for that agent. This additional information will be loaded with the agent's information, or calculated as defined in the mappings.
The additional data can be used in both mappings and triggers.

The attributes which you define here will be shown when you click on the proper account, on the Accounts Tabs at user page.

Operational

Monitoring

After the agent configuration you could check in the monitoring page if the service is running in the Synchronization Server, please go to:

• Start Menu > Administration > Monitoring and reporting > Syscserver monitoring

Tasks

Authoritative

If you are checked "Authorized identity source", an automatic task to load identities from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will something like "Import authoritative data from <AGENT_NAME>".

Reconcile

If you are configured the "Attribute Mapping" tab with some of our objects: "user or group", an automatic task to synchronize these objects from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will do something like "Reconcile all accounts from <AGENT_NAME>".

Synchronization

Regarding the synchronization of the objects, there are two possible options:

• If you are checked the generic attribute "Read Only" in the "Basics" tab, only the changes in the managed systems will be updated in Soffid. We recommend these options until the global configuration of Soffid will be tested.
• If you are not checked the generic attribute "Read Only" in the "Basics" tab, all the changes in Soffid or the managed system will be updated in the other. Note that this synchronization must be configured in the "Attribute mapping" tab correctly.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

JSON REST Web Services Connector

JSON REST Web Services Connector

Introduction

Description

This connector allows the integration with any Web Service able to consume and generate JSON documents through REST communication.

Managed System

Every commercial product or custom web application allows REST communication with JSON documents.

There are a lot of products that use this standard, for instance:

• JIRA.
• Oracle Field Service Cloud (OFSC).
• Office 365.
  
• AWS.
• Google Cloud.

If your system is not in the previous list, it's possible to include it easily!

For more information to check if your system may be synchronized with this connector you do not hesitate to contact us through our Contact form

Prerequisites

It is needed a user with access and permissions to the endpoints and operations required in the scope of the integration.

Also, the documentation, specification, or tutorial of the implementation of the JSON REST Web Service is required to apply the mapping configuration.

Download and Install

This addon is located in the Connectors section and its name is REST (json) plugin.

You can visit the Addons Getting started page for more information about the installation process.

Agent Configuration

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

To configure this JSON REST Web Service Connector you must select "JSON Rest Webservice" in the attribute "Type" of the generic parameters section in the agents' page configuration.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation:

Authentication method

None: no authentication is needed. There are no parameters to configure.

Basic: the username and password are sent with each request.

• User Name: user to authenticate.
• Password: the password of the user to authenticate.

Bearer token

• Bearer token: this token is provided by the application to which we are going to connect.

Token: calls the authentication URL with the POST method and with the username and password, and the response will be the token. It is no longer used.

• User Name: user to authenticate.
• Password: the password of the user to authenticate.
• Authentication URL: URL to retrieve the token for the server's authentication (for the "Token" method).

Token oAuth Client Credentials

• Authentication URL: URL to retrieve the token for the server's authentication (for the "Token" method).
• Token attr. output: the value is always access_token.
• Request parameters:
  • Client ID: it is like the user.
  • Client secret:  it is the password.
  • Scope: it is the permissions.

Token oAuth Password Grant

• User Name: user to authenticate.
• Password: the password of the user to authenticate.
• Authentication URL: URL to retrieve the token for the server's authentication (for the "Token" method).
• Token attr. output: the value is always access_token.
• Request parameters:
  • Client ID: it is like the user.
  • Client secret:  it is the password.
  • Scope: it is the permissions.
    

Attribute mapping

This connector can manage users, accounts, roles, groups, and grants.

Note that any changes made to the methods will affect the properties and vice versa.

Methods

This agent allows you to define methods to be called using the defined properties. There are some default methods, but you can customize your own methods.

Default methods:

• load
• delete
• update
• insert
• select

For each method, the properties to set up are as follows:

204 201 200

200,212

400 403

403,405, 400

return links{"next"};

o = response{"paging"};
if (o{"has_next_page"}) {
  nextPage = o{"page_number"} + 1;
  request.put("page", nextPage);
  return true;
} else { 
  return false;
}

Load

Select

Insert

Update

Delete

Properties

In this agent, the configuration of the properties attributes is very important due to they define the functionality of the integration:

This agent has five families of properties:

These families are involved in the following processes:

These are the pictures of the mechanisms used to synchronize objects:

Sync object

Remove object

You can find more information by visiting the Properties attributes page.

Attributes

You can customize attribute mappings, you only need to select system objects and the Soffid objects related, manage their attributes, and make either inbound and outbound attribute mappings.

You may map the attributes of the target system with the Soffid available attributes.

• For the target system attributes is required to be access to its specification.
• For the Soffid attributes, you may follow the next link.

For more information about how you may configure attribute mapping, see the following link: Soffid Attribute Mapping Reference

For instance:

As an example, below is how JSON connector will look like in order to manage JIRA accounts:

Triggers

You can define BeanShell scripts that will be triggered when data is loaded into the target system (outgoing triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation on target objects. 

To view some examples, visit the Outgoing triggers examples page.

JSON REST Web Services Connector - Properties

In this agent, the configuration of the properties attributes is very important due to they define the functionality of the integration:

This agent has five families of properties:

These families are involved in the following processes:

These are the properties attributes grouped by family:

Load

Select

Insert

Update

Delete

How to retrieve data from the response with the *Results properties

a) One level

If the JSON has one level you have to avoid the property
{
    "userName" : "soffid"
}

b) Two level

If the JSON has two levels you have to create the property *Result and put the name of the parent attribute, for example:
{
    "user" : {    
        "userName" : "soffid"
    }
}
And the property must be for example loadResults = user

c) More than two levels

If the JSON has more than two levels you have to create the property *Result and put the atributes in the next pattern

*Results = attribure1{"attribute2"}{"attribute3"}...

For example:
{
	"data" : {
        "user" : {    
            "userName" : {
                "string" : "soffid"
            }
        }
    }
}

And the property must be for example:

loadResults = data{"user"}{"userName"}

How to configure the Office 365 agent?

Office 365 integration

Prerequisites

• You need to install the last version of JSON Rest Connector

Configuration

Configure the Basic data to establish the connection

Then, configure the attribute mappings

Soffid provides you versions of the attribute mappings to import into the agent configuration:

• Basic attribute mappings: agent-config-Office365-Basic.xml
• Attribute mappings with immutable ID and Azure groups: agent-config-Office365-MoreComplex.xml

How to configure the Jira Atlassian agent?

Jira integration

Prerequisites

• You need to install the last version of JSON Rest Connector.

Configuration

Configure the Basic data to establish the connection

Then, configure the attribute mappings

Soffid provides you an XML file with the basic attribute mappings to import into the agent configuration JIRA Soffid agent-config.xml

LDAP Connector

LDAP Connector

Introduction

Description

This connector implements the LDAP standard and it is used to connect the Sync-Server with every server that allows this communication protocol.

Managed System

There are a lot of servers and products that use this standard, for instance, the most known systems are:

• 389 Directory Server.

• Apache Directory Server.

• OpenLDAP.

• OpenDJ.

• Active Directory.

• Oracle Directory Server.

For more information: List of LDAP software.

If your system is not in the previous list, it's possible to include it easily!

For more information to check if your system may be synchronized with this connector you do not hesitate to contact us through our Contact form

Prerequisites

It is needed a user with full administrator access.

Download and Install

This addon is located in the Connectors section and its name is LDAP plugin.

For more information about the installation process you can visit the Addons Getting started page.

Agent Configuration

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

To configure this LDAP Connector you must select "LDAP-Custom (with triggers)" in the attribute "Type" of the generic parameters section in the agent's page configuration.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation:

Attribute mapping

This connector can manage users, accounts, roles, groups, and grants.

As a limitation, it cannot detect password changes to be propagated to other systems.

Properties

Some agents require to configure some custom attributes, you will use the properties section to do that.

If a key value is set, LDAP connector will search for objects based on this LDAP attribute value, rather than its DN. Thus, an index on this attributed is highly recommended.

Renaming

To support object renaming, Soffid needs to store the Soffid account name on a specific LDAP attribute. It's highly recommended to index such a field. To enable it, add the following properties to each object mapping. At any time, object renaming can be disabled by setting the property rename to false.

Attributes

You can customize attribute mappings, you only need to select system objects and the Soffid objects related, manage their attributes, and make either inbound or outbound attribute mappings.

Using a windows connector you can map users, groups, and role objects. Active Directory membership is automatically managed based on user and group mappings.

You can map users, groups, and role objects. User membership must be managed on the role members' attribute expression.

Any object mapping must have the following system attributes:

For more information about how you may configure attribute mapping, see the following link: Soffid Attribute Mapping Reference

For instance:

Triggers

You can define BeanShell scripts that will be triggered when data is loaded into the target system (outgoing triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation on target objects. 

To view some examples, visit the Outgoing triggers examples page.

Oracle Connectors

Oracle Connector

Introduction

Description

Oracle Connector could manage an Oracle database.

Soffid's Oracle connector supports Profiles since version 2.2.6.14

Managed System

This connector is specific for integration with an Oracle database, if you want to connect a generic SQL database, please visit the following page: SQL Connector.

For more information to check if your system may be synchronized with this connector you do not hesitate to contact us through our Contact form

Prerequisites

It is needed a user with sysdba access and permissions.

User management

Criteria:

• Any user or account created will be granted the CREATE SESSION privilege.
• Default tablespace for each user will be the USERS tablespace. It won't be changed for existing users.
• Soffid passwords expiration date will be managed by Soffid. So, Oracle won't be notified about when those passwords need to be expired.
• Roles and groups are automatically created when a user belonging to it is updated.

Exceptions:

• Error SQL: ….There was an error executing an SQL statement.
• Contact with the administrator of the database. It may be a problem of user authorizations, administrator password validity, availability of space in the database, or saturation of it.

Download and Install

This addon is located in the Connectors section and its name is Oracle Connector.

For more information about the installation process you can visit the Addons Getting started page.

Agent Configuration

This connector could manage User and Role objects.

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

To configure this Oracle Connector you must select "OracleAgent" in the attribute "Type" of the generic parameters section in the agents' page configuration.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation:

Load triggers

You can define JavaScript or BeanShell scripts that will be triggered when data is loaded into Soffid (incoming triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation into Soffid objects. 

To view some examples, visit the Incoming triggers examples page.

Access Control

Oracle connector can establish an access control for Oracle Users.

If the access control checkbox is enabled, only the users and applications that are listed on the access control page will be allowed to log in. So, you can restrict the IP address and application a user can connect from.

This restriction does not apply to DBA users.

Check that the user/account is not unmanaged.

When the Enable access control to the database check box is checked, the UpdateAccessControl task will be launched. The following tables will be created on the SQL Server:

• SC_OR_ACCLOG: access log
• SC_OR_CONACC: rule access control
• SC_OR_ROLE: user roles.
• SC_OR_VERSION: connector versions.

When you try to connect to SQL Server, the logon_audit_trigger is launched to check if you have access or not.

You can check the Access Logs page for access controls.

Account metadata

Agents allow you to create additional data, on the "Account metadata" tab, to customize the accounts created for that agent. This additional information will be loaded with the agent's information, or calculated as defined in the mappings.
The additional data can be used in both mappings and triggers.

The attributes that you define here will be shown when you click on the proper account, on the Accounts Tabs at user page.

Operational

Monitoring

After the agent configuration you can check on the monitoring page if the service is running in the Synchronization Server, please go to:

• Start Menu > Administration > Monitoring and reporting > Syscserver monitoring

Tasks

Authoritative

If you checked "Authorized identity source", an automatic task to load identities from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will do something like "Import authoritative data from <AGENT_NAME>".

Reconcile

To manage an automatic task to synchronize user objects from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will do something like "Reconcile all accounts from <AGENT_NAME>".

Synchronization

Regarding the synchronization of the objects, there are two possible options:

• If you check the generic attribute "Read Only" in the "Basics" tab, only the changes in the managed systems will be updated in Soffid. We recommend these options until the global configuration of Soffid is tested.
• If you do not check the generic attribute "Read Only" in the "Basics" tab, all the changes in Soffid or the managed system will be updated in the other. Note that this synchronization must be configured in the "Attribute mapping" tab correctly.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Oracle EBS Connector

Introduction

Description

Oracle Connector could manage an Oracle E-Business Suite.

Managed System

This connector is specific for integration with an Oracle E-Business Suite, if you want to connect a generic SQL database, please visit the following page: SQL Connector.

For more information about the Oracle E-Business Suite, please visit the following page: Oracle E-Business Suite

For more information to check if your system may be synchronized with this connector you do not hesitate to contact us through our Contact form

Prerequisites

It is needed a user with access and permissions to the database.

Download and Install

This addon is located in the Connectors section and its name is Oracle EBS Connector.

For more information about the installation process you can visit the Addons Getting started page.

Agent Configuration

This connector could manage only User objects.

Users created on Soffid will be created on EBS, in the same way disabled users on Soffid will be disabled on EBS.

The responsibilities that exist in EBS can be assigned to the users. They must be created like roles on Soffid System previously, with the same name that the responsibility has on EBS.

For instance: FND_RESP | CSF | CSF_FS_PDA_REP | STANDARD.

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

To configure this Oracle EBS Connector you must select "OracleEBudsinessAgent" in the attribute "Type" of the generic parameters section in the agents' page configuration.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation:

Load triggers

You can define BeanShell scripts that will be triggered when data is loaded into Soffid (incoming triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation into Soffid objects.

To view some examples, visit the Incoming triggers examples page.

Account metadata

Agents allow you to create additional data, on the "Account metadata" tab, to customize the accounts created for that agent. This additional information will be loaded with the agent's information, or calculated as defined in the mappings.
The additional data can be used in both mappings and triggers.

The attributes which you define here will be shown when you click on the proper account, on the Accounts Tabs at user page.

Operational

Monitoring

After the agent configuration you could check on the monitoring page if the service is running in the Synchronization Server, please go to:

• Start Menu > Administration > Monitoring and reporting > Syscserver monitoring

Tasks

Authoritative

If you are checked "Authorized identity source", an automatic task to load identities from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will something like "Import authoritative data from <AGENT_NAME>".

Reconcile

To manage an automatic task to synchronize user objects from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will do something like "Reconcile all accounts from <AGENT_NAME>".

Synchronization

Regarding the synchronization of the objects, there are two possible options:

• If you are checked the generic attribute "Read Only" in the "Basics" tab, only the changes in the managed systems will be updated in Soffid. We recommend these options until the global configuration of Soffid will be tested.
• If you are not checked the generic attribute "Read Only" in the "Basics" tab, all the changes in Soffid or the managed system will be updated in the other. Note that this synchronization must be configured in the "Attribute mapping" tab correctly.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

SAP Connector

SAP Connector

Introduction

Description

SAP Connector could manage an SAP system.

Managed System

This connector is specific for integration with a SAP system through its interface BAPIs under the RFC standard.

For more information about SAP, please visit the following page: SAP

For more information to check if your system may be synchronized with this connector you do not hesitate to contact us through our Contact form

Prerequisites

1. The SAP Java Connector (JCO) must be installed in the host where the syncserver is running.
2. A SAP account must be created with permission to execute user administration BAPIs using RFC. Additionally, the attached SAP Role definition Y_SOFFID.SAP can be used to assign permissions to SOFFID RFC user.
3. The following transport order should be applied in order to synchronize passwords: K953376.de1 R953376.de1

Download and Install

This addon is located in the Connectors section and its name is SAP Connector.

For more information about the installation process you can visit the Addons Getting started page.

Agent Configuration

This connector could manage User, Account and Role objects.

• All active users included in agent configuration will be added to SAP.
• All inactive users on Soffid will be deleted from SAP.
• Roles granted to a user will be added to ACTIVITY GROUPS on SAP.

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

This addon has2 available agents:

• SAP (Complete)
• SAP (Light)
  

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation:

Attribute mappings

The attribute mappings are only available for SAP (Complete) configuration.

Properties

Nothing to configure. There are no properties

Attributes

You can customize attribute mappings, you only need to select system objects and the Soffid objects related, manage their attributes, and make either inbound and outbound attribute mappings.

Using SAP connector you can map users.

For more information about how you may configure attribute mapping, see the following link: Soffid Attribute Mapping Reference

Load triggers

You can define BeanShell scripts that will be triggered when data is loaded into Soffid (incoming triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation into Soffid objects.

To view some examples, visit the Incoming triggers examples page.

Account metadata

Agents allow you to create additional data, on the "Account metadata" tab, to customize the accounts created for that agent. This additional information will be loaded with the agent's information, or calculated as defined in the mappings.
The additional data can be used in both mappings and triggers.

The attributes which you define here will be shown when you click on the proper account, on the Accounts Tabs at user page.

Operational

Monitoring

After the agent configuration you could check in the monitoring page if the service is running in the Synchronization Server, please go to:

• Start Menu > Administration > Monitoring and reporting > Syscserver monitoring

Tasks

Authoritative

If you are checked "Authorized identity source", an automatic task to load identities from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will something like "Import authoritative data from <AGENT_NAME>".

Reconcile

If you are configured the "Attribute Mapping" tab with some of our objects: "user, account or role,", an automatic task to synchronize these objects from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will do something like "Reconcile all accounts from <AGENT_NAME>".

Synchronization

Regarding the synchronization of the objects, there are two possible options:

• If you are checked the generic attribute "Read Only" in the "Basics" tab, only the changes in the managed systems will be updated in Soffid. We recommend these options until the global configuration of Soffid will be tested.
• If you are not checked the generic attribute "Read Only" in the "Basics" tab, all the changes in Soffid or the managed system will be updated in the other. Note that this synchronization must be configured in the "Attribute mapping" tab correctly.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

SCIM Connector

SCIM Connector

Introduction

Description

SCIM connector can manage every target system with a published API that allows the SCIM protocol for communication.

SCIM is basically a REST JSON web service with specific HTTP requests and responses, and also a specific JSON format for attributes and values.

For more information about SCIM protocol you could visit its home page: SCIM protocol, or to visit the introduction page of our SCIM addon: Introduction to SCIM

Managed System

The official web of SCIM shows all the possible target systems that allow SCIM protocol: SCIM implementations

Some of the most popular implementations:

• Soffid IAM
• Active Directory SCIM Provisioning
• Oracle Identity Manager
• WSO2 Charo
• Salesforce
• Trello
• Slack

For more information to check if your system may be synchronized with this connector, you do not hesitate to contact us through our Contact form

Prerequisites

t is needed a user with access and permissions to the endpoints and operations required in the scope of the integration.

Also, the documentation, specification or tutorial of the web service, despite SCIM defining a schema for the objects, most applications or servers use to implement extended or customized versions of it.

Download and Install

This addon is located in the Connectors section and its name is SICM connector.

For more information about the installation process, you can visit the Addons Getting started page.

Agent Configuration

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

To configure this SCIM Connector you must select "SCIM" in the attribute "Type" of the generic parameters section in the agents page configuration.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation:

Attribute mapping

This connector can manage users and groups.

Properties

The following properties are defined for each object type:

Attributes

You may map the attributes of the target system with the Soffid available attributes.

• For the target system attributes are required to be access to its specification
• For the Soffid attributes, you may follow the next link

For more information about how you may configure attribute mapping, see the following link: Soffid Attribute Mapping Reference

If you are trying to connect to WSO2IS server, you must enable the WSO2 workaround setting, in order to bypass some WSO2 buggy implementations. You can get default mappings for WSO2IS here: wso2is-config.xml. Download it and import it into the Soffid agent attribute mappings form.

For example:

Triggers

Load triggers

Account metadata

Agents allow you to create additional data, on the "Account metadata" tab, to customize the accounts created for that agent. This additional information will be loaded with the agent's information, or calculated as defined in the mappings.
The additional data can be used in both mappings and triggers.

The attributes which you define here will be shown when you click on the proper account, on the Accounts Tabs on the users' page.

Operational

Monitoring

After the agent configuration you could check on the monitoring page if the service is running in the Synchronization Server, please go to:

• Start Menu > Administration > Monitoring and reporting > Syscserver monitoring

Tasks

Authoritative

If you are checked "Authorized identity source", an automatic task to load identities from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will something like "Import authoritative data from <AGENT_NAME>".

Reconcile

If you are configured the "Attribute Mapping" tab with some of our objects: "user, account, role, group or grant", an automatic task to synchronize these objects from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will do something like "Reconcile all accounts from <AGENT_NAME>".

Synchronization

Regarding the synchronization of the objects, there are two possible options:

• If you are checked the generic attribute "Read Only" in the "Basics" tab, only the changes in the managed systems will be updated in Soffid. We recommend these options until the global configuration of Soffid will be tested.
• If you are not checked the generic attribute "Read Only" in the "Basics" tab, all the changes in Soffid or the managed system will be updated in the other. Note that this synchronization must be configured in the "Attribute mapping" tab correctly.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Shell Connector

Shell Connector

Introduction

Description

Linux Connector could manage a lot of services running on Linux systems (either 32 or 64 bits).

Managed System

This connector has implemented several ways to communicate with services on Linux, below, the list of those services:

• Shell
• SSH
• Cisco ASA
• Exchange
• Power Shell

If your system is not in the previous list, it's possible to include it easily!

For more information to check if your system may be synchronized with this connector you do not hesitate to contact us through our Contact form

Prerequisites

A Soffid Synchronization Server must be installed on the managed Linux system.

Download and Install

This addon is located in the Connectors section and its name is Shell Connector.

For more information about the installation process you can visit the Addons Getting started page.

Agent Configuration

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

To configure this Shell Connector you could select one agent, from the next list of available agents, in the attribute "Type" of the generic parameters section in the agents' page configuration.

• Shell Agent
• SSH Agent
• Cisco ASA Agent
• Exchange Agent
• Power Shell Agent

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below, there are the specific parameters for each agent implementation.

Shell Agent

SSH Agent

Cisco ASA Agent

Exchange Agent

Power Shell Agent

Attribute mapping

This connector could manage Users, Groups and Roles.

Users

• Any user or account will be created at /etc/passwd file.
• Home directories will be created using default Linux configuration properties.
• If stated, samba users will be mapped for each managed Linux user.
• Soffid passwords expiration date will be managed by Soffid. So, Linux won't be notified about when those passwords need to be expired.

Groups

• Groups will be created and removed as Linux groups.

Roles

• Roles bound to this system will be created as Linux groups.
• Any removed role will trigger the bound Linux group to be removed.

Properties

You can map user, groups and role objects. These are some of the properties to be mapped in those objects:

For the "Cisco ASA Agent" has these attributes:

The "Exchange Agent" has these attributes:

Attributes

You can customize attribute mappings, you only need to select system objects and the Soffid objects related, manage their attributes, and make either inbound and outbound attribute mappings.

You can map user, groups and role objects. These are some of the attributes to be mapped in those objects:

The "Cisco ASA Agent" has these attributes:

For more information about how you may configure attribute mapping, see the following link: Soffid Attribute Mapping Reference

For instance:

Triggers

You can define BeanShell scripts that will be triggered when data is loaded into the target system (outgoing triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation on target objects. 

"Cisco ASA Agent" has not implemented this feature.

To view some examples, visit the Outgoing triggers examples page.

Load triggers

You can define BeanShell scripts that will be triggered when data is loaded into Soffid (incoming triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation into Soffid objects. 

To view some examples, visit the Incoming triggers examples page.

Account metadata

Agents allow you to create additional data, on the "Account metadata" tab, to customize the accounts created for that agent. This additional information will be loaded with the agent's information, or calculated as defined in the mappings.
The additional data can be used in both mappings and triggers.

The attributes which you define here will be shown when you click on the proper account, on the Accounts Tabs at user page.

Operational

Monitoring

After the agent configuration you could check in the monitoring page if the service is running in the Synchronization Server, please go to:

• Start Menu > Administration > Monitoring and reporting > Syscserver monitoring

Tasks

Authoritative

If you are checked "Authorized identity source", an automatic task to load identities from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will something like "Import authoritative data from <AGENT_NAME>".

Reconcile

If you are configured the "Attribute Mapping" tab with some of our objects: "user, account, role, group or grant", an automatic task to synchronize these objects from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will do something like "Reconcile all accounts from <AGENT_NAME>".

Synchronization

Regarding the synchronization of the objects, there are two possible options:

• If you are checked the generic attribute "Read Only" in the "Basics" tab, only the changes in the managed systems will be updated in Soffid. We recommend these options until the global configuration of Soffid will be tested.
• If you are not checked the generic attribute "Read Only" in the "Basics" tab, all the changes in Soffid or the managed system will be updated in the other. Note that this synchronization must be configured in the "Attribute mapping" tab correctly.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Invoker interface

Any agent, trigger or mapping can use the invoker method for the ActiveDirectory agent. The invoker method is available in the dispatcherService class as well as the in the serverService.

The invoker method is not specific of the Shell agent. Many other connectors support this method. The expected arguments are:

• Action
• Object name
• Parameters

Here you have an example of a post-update trigger to create the home server for a user:

map = new HashMap();
map.put("user", source{"accountName"});
// Create folder
dispatcherService.invoke("invoke", "mkdir /home/${user}", map);
dispatcherService.invoke("invoke", "mkdir /home/${user}/Desktop", map);

There is a chance to execute operation across agents. For instance, if the system has an ActiveDirectory agent and an Exchange agent, here is a post-insert trigger to place in the post-insert trigger of the ActiveDirectory agent to execute a command in the Exchange one.

map = new HashMap();
map.put("user", source{"accountName"});
// Create folder
serverService.invoke("Exchange", "invoke", "EnableMailbox ${user}", map);

The list of allowed commands are:

SQL Connector

SQL Connector

Introduction

Description

The SQL connector allows an easy way to configure and manage relational databases.

Managed System

There are a lot of relational databases, currently, these are the supported databases.

• MySQL
• MariaDB
• PostgreSQL
• Oracle
  
• Informix
• IBM DB2/400
• Sybase
• ODBC

For more information: List of relational databases

If your system is not in the previous list, it's possible to include it easily!

For more information to check if your system may be synchronized with this connector you do not hesitate to contact us through our Contact form

Prerequisites

It is needed a user with access and permissions to the schemes and tables required in the scope of the integration.

To configure DB2/400  or Sybase it is mandatory to install the drivers in the lib directory of the Sync Server.

The Java-ODBC bridge is deprecated in Java, and the support will be removed shortly.

Download and Install

The SQL is part of the default connectors, you do not need to install it, but you can upgrade it from the download management section.

You can visit the Connector Getting started page for more information about the installation process.

Agent Configuration

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

To configure this SQL connector you must select "Customizable SQL agent" in the attribute "Type" of the generic parameters section in the agent's page configuration.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation:

jdbc:mariadb://<HOST>/<DATA_BASE>

jdbc:mysql://<HOST>/<DATA_BASE>

jdbc:postgresql://<HOST>/<DATA_BASE>

jdbc:oracle:<drivertype>:@<database>

jdbc:sqlserver://<HOST>;databaseName=<DATA_BASE>

{SHA1}BzE/DjIPIsv6Nc/CIFCOs/9FfH4=

{SHA256}AIEM+LlNb8ucXeSE077EGHYgs+KHblmquQ2FL+Dxj7Y=

Attribute mapping

This connector can manage users, accounts, roles, groups, and grants.

Properties

Some agents require to configure some custom attributes, you will use the properties section to do that.

Any SQL sentence gets its parameters in three step process:

1. The synchronization engine creates the Soffid object.
2. The Soffid object is translated into a managed system object, using the attribute translation rules.
3. Soffid parser looks for any identifier preceded by a colon (:) symbol. For any symbol found, the symbol is replaced by a parameter whose value is the managed system attribute with the replaced identifier.

Once the SQL sentence has been executed, in the case of SELECT clauses, the column names are used to generate a virtual managed system object. The last step is to apply the attribute translation to generate the Soffid object to be populated.

These are the properties required to map every object of the mapping:

SELECT * FROM USERS

SELECT * FROM ROLES

SELECT ID FROM USERS WHERE USER=:USER

SELECT ID FROM ROLES WHERE ROLE=:ROLE

INSERT INTO USERS VALUES (:USER, :FIRST_NAME, :LAST_NAME, :MAIL, :GROUP)

INSERT INTO USER_ROLES (USETNAME, ROLNAME) VALUES (:USERNAME, :ROLNAME)

UPDATE USERS SET FIRST_NAME=:FIRST_NAME, LAST_NAME=:LAST_NAME, MAIL=:MAIL, GROUP=:GROUP WHERE ID=:ID

UPDATE ROLES SET DESCRIPTION=:DESCRIPTION WHERE ROLE=:ROLE

DELETE FROM USERS WHERE ID=:ID

DELETE FROM USER_ROLES WHERE ID=:ID

SELECT * FROM USER_ROLES WHERE USERNAME=:USER

SELECT * FROM ROLES WHERE ROLE=:ROLE

UPDATE USERS SET PASS=:PASS WHERE USER=:USER

SELET 1 FROM USERS WHERE PASS=:PASS AND USER=:USER

Attributes

You can customize attribute mappings, you only need to select system objects and the Soffid objects related, manage their attributes, and make either inbound or outbound attribute mappings.

You may map the attributes of the target system with the Soffid available attributes.

• For the target system attributes are required to be accessible to its specification
• For the Soffid attributes, you may follow the next link

For more information about how you may configure attribute mapping, see the following link: Soffid Attribute Mapping Reference

Example for roles:

Example for accounts:

Triggers

You can define BeanShell scripts that will be triggered when data is loaded into the target system (outgoing triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation on target objects.

To view some examples, visit the Outgoing triggers examples page.

Integration flows

Update User

Visit the Integration flows Update user page for more information

Update Account

Visit the Integration flows Update account page for more information

(*)

https://mariadb.com/kb/en/about-mariadb-connector-j/

https://docs.microsoft.com/es-es/sql/connect/jdbc/building-the-connection-url?view=sql-server-ver16

(**) Soffid provides two synchronization types:

• Full synchronization
• Incremental synchronization

The first type, the full synchronization method, persists the changes made in Soffid, regardless of the possible changes made in the target system.

For the second type, the incremental synchronization method, Soffid has developed a synchronization system, using custom internal attributes, to check what changes have been made to the different attributes of an object. Thus, it tries to avoid losing the changes that have been made in the target system. First, Soffid's changes will be propagated to the target system, and then the changes on the target system will be made in the Soffid system. If the changes are in the same attribute, the Soffid value is the one that will persist.

SQL Integration flows - Update user

Update user

Introduction

Soffid provides a workflow to create, modify, and delete a user in the final system. One can see the steps of the process in the following diagram. 

This process only applies to account type single users.

Diagram

Step by Step

In this document, we will explain the process that Soffid performs to modify a user for the SQL connector.

1. Initial step

First of all, Soffid checks if the user exists in Soffid and then checks the operation to perform, update or delete. 

1.1. If the user does not exist in Soffid, then Soffid asks to delete the user in the target System. 

❓ Warning message

1.1.1. Yes: If the answer is Yes, the process follows through the Yes branch, [3. Delete branch].

1.1.2. No:  If the answer is Yes, the process finishes [10. End]. 

1.2. If the user exists in Soffid, the process continues through [2. User to remove?]. to check if the 

2. User to remove?

2.1. If the user is marked for Deletion, Soffid will ask for user consent to continue with the process or to cancel it. If the answer is Yes, the process follows through the Yes branch, [3. Delete branch].

❓ Warning message

2.2. If the user is marked for Update, it continues with the flow following through the No branch, [4. Insert or Update branch].

3. Delete branch

📊 Diagram

3.1. When the operation to perform is to delete a user, first of all, Soffid has to check if the user exists in the target system. To do this, Soffid executes the property check of the User object. This property executes the SQL command to check if the user exists or not.

3.1.1. If the user does not exist, there are no actions to perform in the target system, so the process finishes [10. End].

3.1.2. If the user exists, the flow continues executing the pre-delete triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user delete, and the result (true or false) determines if the main action will be performed or not.

3.1.2.1. False: if the result is false for one or more of these triggers, the process finishes [10. End].

3.1.2.2.True: if the result is true for all of these triggers, Soffid continues to the next step.

3.1.3. Soffid removes the user. To do that, Soffid executes the property delete of the User object.

3.1.3.  Then Soffid executes the post-delete triggers if any. These triggers can be used to perform a specific action just after performing the remove user operation on the target object.

3.1.3.  Then the process finishes [10. End].

4. Insert or Update branch

4.1. When the operation to perform is to update a user, first of all, Soffid generates the columns values.  That is, Soffid calculates the values of the columns from the original values of Soffid.

4.2.Then Soffid asks if the user exists in the target system to decide the action to execute, this action can be an update or an insert. Soffid executes the property check of the User object.

4.2.1. If the user does not exist in the target system, the process continues through [5. Insert user branch]. 

4.2.2. If the user exists in the target system, the process continues through [6. Update user branch].

5. Insert user branch

📊 Diagram

5.1. Soffid executes the pre-insert triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user create, and the result (true or false) determines if the main action will be performed or not.

5.1.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the user is not created.

5.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

5.2. Soffid creates the user. To do that, Soffid executes the property insert of the User object.

5.3. Then Soffid executes post-insert triggers if any. These triggers can be used to perform a specific action just after performing the create user operation on the target object.

5.4. Then the process continues through [7. Grants].

6. Update user branch

📊 Diagram

6.1. Soffid fetches the current values of the user.  Soffid executes the property selectByAccountName of the User object.

&&TODO&& IMAGEN

6.2. Then compute delta changes, if the property Synchronization method selected is Full Synchronization, then Soffid has to keep the columns values of the last update. If  there was any change in the target system:

• There is no conflict, then Soffid only updates the values of the attributes that have changed in Soffid.
• There is conflict, Soffid values prevail over the target system values, so, Soffid updates all the attributes that have changed in Soffid.

&&TODO&& IMAGEN

6.3. And finally execute the pre-update triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user update, and the result (true or false) determines if the main action will be performed or not.

6.3.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the user is not updated

6.3.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

6.4. Soffid updates the user. To do that, Soffid executes the property update of the or User object.

6.5. Then Soffid executes the post-update triggers if any. These triggers can be used to perform a specific action just after performing the update user operation on the target object.

6.6. Then the process continues through [7. Grants].

7. Grants

At this point, soffid runs the actions relative to the grants

7.1. Once the process arrives at this step, Soffid generates account column values.  That is, Soffid creates a dummy object with only the account name, this object will be used later.

7.2. Then, Soffid fetches the current grants for the user.  Soffid executes the property selectByAccount of the grant object with the values of the previous step

7.3. Finally, Soffid parses grant rows, that is Soffid makes the mappings defined 

7.3. Then the process continues through [8. Grant to add]. 

8. Grant to add

This is a loop while there are grants to add. This grants list comes from the previous step [7. Grants].

📊 Diagram

8.1. If there are No grants to add, the process goes to [9. Grant to Remove].

8.2. Yes, there are grants to add:

8.2.1. Soffid generates grant column values and  Soffid checks if the grant exists in the target system, Soffid executes the property check of the grant object.

8.2.2. Soffid executes the pre-insert triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, a grant create, and the result (true or false) determines if the main action will be performed or not.

8.2.2.1. False: if the response is false for one or more of these triggers, the process goes to [8. Grant to add] and the grant is not created.

8.2.2.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

8.2.3. If the result of the triggers is true, then Soffid creates the grant. To do that, Soffid executes the property insert of the grant object.

8.2.4. Then Soffid executes the post-insert triggers if any. These triggers can be used to perform a specific action just after performing the create grant operation on the target object.

8.2.5.  Then the process continues through  [8. Grant to add].

9. Grant to remove

📊 Diagram

This is a loop while there are grants to remove. This grants list comes from the previous step [7. Grants].

9.1 No: If there are No grants to add, the process goes to [10. End].

9.2. Yes,  there are grants to remove:

9.2.1. Soffid executes the pre-delete triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, a grant delete, and the result (true or false) determines if the main action will be performed or not.

9.2.1.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the grant is not deleted.

9.2.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

9.2.2. If the result of the triggers is true, then Soffid deletes the grant. To do that, Soffid executes the property delete of the grant object. This operation can return a true or false result.

9.2.2.1. False: the delete action could not be performed and the process check for another grant [9. Grant to remove].

9.2.2.2. True: the delete action could be performed properly. Soffid continues to the next step.

9.2.3. Then Soffid executes the post-delete triggers if any. These triggers can be used to perform a specific action just after performing the delete grant operation on the target object.

9.2.4. Then the process continues through [9. Grant to remove].

10. End

The process finishes and the log is displayed, and you can download it by clicking the Download button.

📑 Log detail

Windows Connector

Windows Connector

Introduction

Description

This connector implements the LDAPS protocol and it is used to connect the Sync-Server with every server that allows this communication protocol.

Managed System

This connector has been performed to connect to the Active Directory system, it's a fork of our LDAP Connector with custom features.

For more information to check if your system may be synchronized with this connector you do not hesitate to contact us through our Contact form

Prerequisites

To enable LDAPS in your Active Directory, please read the following guide: SSL access to Active Directory.

It is needed an Active Directory user with full administrator access.

Download and Install

This addon is located in the Connectors section and its name is Windows (including Active Directory).

For more information about the installation process you can visit the Addons Getting started page.

Agent Configuration

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

This addon has 5 available agents:

• Active Directory
• Active Directory Only Passwords
• Simple Windows Agent
  

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation, "Active Directory"

• Host name of the domain controller.
• Active Directory distingished name in X500 format. e.g.: dc=soffid,dc=local
• Administrator principal name in X500 format, relative to A.D name. e.g.: cn=Administrator,cn=Users
• Administrator password

Attribute mapping

Active Directory connector could manage Users and Groups by using LDAPS protocol.

Properties

Some agents require to configure some custom attributes, you will use the properties section to do that.

To enable it, add the following properties to each object mapping:

For instance:

Attributes

You can customize attribute mappings, you only need to select system objects and the Soffid objects related, manage their attributes, and make either inbound or outbound attribute mappings.

Using a windows connector you can map users, groups, and role objects. Active Directory membership is automatically managed based on user and group mappings.

Any object mapping must have the following system attributes:

There is a bunch of AD special attributes that need some special treatment:

if ( attributes {"expirationDate"} == null)
   return 9223372036854775807L;
else
   return attributes{"expirationDate"}.getTime() * 10000L + 116445528000000000L;

if ( lastLogon == null || lastLogon == void) return null;
Long v = Long.decode(lastLogon);
v = v / 10000000L;
v-=11644473600L;
return new Date(v*1000);
=>
lastLogin

For more information about how you may configure attribute mapping, see the following link: Soffid Attribute Mapping Reference

For instance:

Triggers

You can define BeanShell scripts that will be triggered when data is loaded into the target system (outgoing triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation on target objects. 

To view some examples, visit the Outgoing triggers examples page.

Avoid incremental load authoritative

The Customizable Active Directory connector has an incremental load authoritative process. 

When this process is executed, it requests the changes to Active Directory after the uSNChanged. 

The value of this field is saved in Soffid in the parameter soffid.sync.authoritative.change.NAME_OF_THE_AGENT

If you want to launch a complete load authoritative process, remove this parameter first. At the end of the process, the parameter will be generated automatically.

For more information, go to the Soffid Parameters page.

HOWTO SSL access to Active Directory

Table of Contents

• Introduction.
• Installing the Certificate Services.
• Configuring Automatic Certificate Request for Domain Controllers.
• Check for Issued Certificate.
• Import certificate.

Introduction

This howto will show you how to install the Certificate Services in Windows Acive Directory Servers.

Before beginning, make sure the Internet Information Server (IIS) is installed in your server.

Installing the Certificate Services

1. Click Start, select Control Panel and click Add or Remove Programs.

2. In the Add or Remove Programs window, click Add/Remove Windows Components, check the Certificate Services and click Next.

3. Click Next in the CA Type page.

4. Fill up the Common name for this CA and click Next.

5. Click Next in the Certificate Database Settings page.

6. The Certificate Services will now be installed.

7. Click Finish and restart your server.

Configuring Automatic Certificate Request for Domain Controllers

1. Click Start, select Administrative Tools and click Domain Controller Security Policy.

2. In the Default Domain Controller Security Settings window, click the Public Key Policies folder.

3. Right click Automatic Certificate Request Settings, select New and click Automatic Certificate Request.

4. Click Next in the Automatic Certificate Request Setup Wizard

5. Select Domain Controller in the Certificate Template page and click Next

6. Click Finish and reboot your server.

Check for Issued Certificate

1. Click Start, select Administrative Tools and click Certification Authority. This will launch the Certification Authority application.

2. In Certification Authority, click the + sign and check the Issued Certificates folder if your server has been issued a certificate.

Import certificate

1. Select the certificate and open it. Select the "Certification Path" tab and select the root certificate.

2. Click on "View Certificate" button and navigate to "Details" tab.

3. Click on "Copy to File..." button and follow the export steps to obtain the certificate.

4. Open cmd and go to the soffid-iam-sync instalation directory and execute:

jre\bin\keytool -import -file “file” -keystore conf\cacerts -alias AD_CERT

Afterwards, the console will ask you for a password. Type the default password: changeit and press enter.

Invoker interface for Active Directory

Any agent, trigger or mapping can use the invoker method for the ActiveDirectory agent. The invoker method is available in the dispatcherService class.

The invoker method is not specific of the Active Directory agent. Many other connectors support this method. The expected arguments are:

• Action
• Object name
• Parameters

Here you have an example of a post-update trigger to create the home server for a user:

map = new HashMap();
String server = "//"+source{"homeServer"}+"/"+source{"accountName"};
// Create folder
f = dispatcherService.invoke("smb:mkdir", server, map);
   
// Add administrator ACL
map.put("user", "soffid_admin");
map.put("permission", "GENERIC_ALL");
map.put("flags", "CONTAINER_INHERIT_ACE OBJECT_INHERIT_ACE");
f = dispatcherService.invoke("smb:addacl", path, map);
 
// Add user ACL
map.put("user", source{"accountName"});
f = dispatcherService.invoke("smb:addacl", path, map);
// Change folder ownership using a domain admin account
map.put("_auth_user", "user1");
map.put("_auth_domain", "domain1");
map.put("_auth_password", "SuperSecret");
f = dispatcherService.invoke("smb:setOwner", path, map);

The example above uses the smb:mkdir action to create the folder, the smb:addacl to add a new access control list entry. Other commands allow the query and modification of Active Directory objects like users and groups.

The list of allowed commands are:

By default, actions are performed by the account used to configure the AD connector, but sometimes, another account must be used, mainly when dealing with NAS servers. In order to user custom credentials SMB commands accept three special parameters: _auth_user, _auth_password and _auth_domain. If this parameters are null, the agent user and password is used.

Active Directory back channel configuration

Introduction

Active Directory Back Channel refers to a mechanism that allows Soffid to synchronize user information with an external Active Directory (AD) server in real-time or near real-time (Password synchronizer). This synchronization ensures that both Soffid and AD maintain consistent and up-to-date data.

How it works?

1. The AD sends the password to Soffid to verify that it complies with Soffid policy.
2. If it complies, the password is updated in the AD.
3. The password is sent to Soffid and the PropagatePassword task is created.
4. If the AD agent confirms that the new password has been saved, Soffid synchronizes it with the other systems.

How to install Active Directory back channel?

Download

In order to configure the Active Directory back-channel, you must use the eris command line tool. To do this, please, download the Password Synchronizer from our download portal:

Install

First of all, you must install the Windows package "Password synchronizer-3.0.x.msi"

Once installed Password Synchronizer on your system, please change to eris or eris64 directory (\ProgramFiles\Soffid\eris64) and execute:

eris-ad-service install

Configure

Finally, you must configute the Password Synchronizer executing the following command:

eris-ad-service CONFIGURE url-syncserver agent-name

• url-syncserver is the master sync server url (http://master.dom.dom:port)
• agent-name is the agent code name configured on Soffid console.

To see more information when configuring use | more. 

Example

eris-ad-service CONFIGURE https://sync-server.netcompose:1760/ "AD soffid.pat" | more

Test configuration

In order to test configuration, you must use the eris command line tool.

eris-ad-service TEST user pass

Where user and pass can be dummy. If you use a real one it will be propagated to the system.

To see more information during test use | more.

Example

eris-ad-service TEST aretha password | more

AD Integration flows - Update user

Update

Introduction

Soffid provides a workflow to modify and/or delete a user in the final system. In it, we can see each of the steps of which this process is composed. 

Diagram

Step by Step

In this document, we will explain the process that Soffid performs to modify a user for the AD connector.

1. Initial step

First of all, Soffid checks if the user exists in Soffid and then checks the operation to perform, update or delete. 

1.1. If the user does not exist in Soffid, then Soffid asks to delete the user in the target System. 

❓ Warning message

1.1.1. Yes: If the answer is Yes, the process follows through the Yes branch, [3. Delete branch].

1.1.2. No:  If the answer is Yes, the process finishes [10. End]. 

1.2. If the user exists in Soffid, the process continues through [2. User to remove?]. to check if the 

2. User to remove?

2.1. If the user is marked for Deletion, Soffid will ask for user consent to continue with the process or to cancel it. If the answer is Yes, the process follows through the Yes branch, [3. Delete branch].

❓ Warning message

2.2. If the user is marked for Update, it continues with the flow following through the No branch, [4. Insert or Update branch].

3. Delete branch

3.1. When the operation to perform is to delete a user, first of all, Soffid has to check if the user exists in the target system. 

3.1.1. If the user does not exist, there are no actions to perform in the target system, so the process finishes [10. End].

3.1.2. If the user exists, the flow continues executing the pre-delete triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user delete, and the result (true or false) determines if the main action will be performed or not.

3.1.2.1. False: if the result is false for one or more of these triggers, the process finishes [10. End].

3.1.2.2.True: if the result is true for all of these triggers, Soffid continues to the next step.

3.1.3. Soffid removes the AD user in the Active directory.

3.1.3.  Then Soffid executes the post-delete triggers if any. These triggers can be used to perform a specific action just after performing the remove user operation on the target object.

3.1.3.  Then the process finishes [10. End].

4. Insert or Update branch

4.1. When the operation to perform is to update a user, first of all, Soffid generates the AD user.  That is, Soffid calculates the values of the AD user object from the original values of Soffid.

4.2.Then Soffid asks if the user exists in the target system to decide the action to execute, this action can be an update or an insert. 

4.2.1. If the user does not exist in the target system, the process continues through [5. Insert user branch]. 

4.2.2. If the user exists in the target system, the process continues through [6. Update user branch].

5. Insert user branch

5.1. Soffid executes the pre-insert triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user creates, and the result (true or false) determines if the main action will be performed or not.

5.1.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the user is not created in the target system.

5.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

5.2. Soffid creates AD user in the Active directory

5.3. Then Soffid executes post-insert triggers if any. These triggers can be used to perform a specific action just after performing the create user operation on the target object.

5.4. Then the process continues through [7. Groups].

6. Update user branch

6.1. Soffid checks if there are any change between the generated object and the values of the object in the target system.

6.1.1. False: if there are no changes,  the process finishes [10. End].

6.1.2. True: if there are changes to update, Soffid continues to the next step.

6.2. Soffid executes the pre-update triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user update, and the result (true or false) determines if the main action will be performed or not.

6.2.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the user is not updated in the target system

6.2.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

6.3. Soffid updates the AD user in the Active directory

6.4. Then Soffid executes the post-update triggers if any. These triggers can be used to perform a specific action just after performing the update user operation on the target object.

6.6. Then the process continues through [7. Grants].

7. Grants

At this point, Soffid runs the actions relative to the grants. The operations can be to add the user to one or more groups or to remove the user from existing groups.

8. Group to remove

This is a loop while there are groups to remove.

8.1. If there are No groups to remove, the process goes to [9. Group to add].

8.2. Yes, there are groups to remove:

8.2.1. Soffid executes the pre-delete triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, a Remove user to group, and the result (true or false) determines if the main action will be performed or not.

8.2.1.1. False: if the response is false for one or more of these triggers, the process goes to [8. Group to remove] and the grant is not created.

8.2.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

8.2.3. If the result of the triggers is true, then Soffid adds the user to a group. 

8.2.4. Then Soffid executes the post-insert triggers if any. These triggers can be used to perform a specific action just after performing the create grant operation on the target object.

8.2.5.  Then the process continues through  [8. Grant to add].

9. Group to add

This is a loop while there are grants to remove. This grants list comes from the previous step [7. Grants].

9.1 No: If there are No grants to add, the process goes to [10. End].

9.2. Yes,  there are grants to remove:

9.2.1. Soffid executes the pre-insert triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, Add user to group, and the result (true or false) determines if the main action will be performed or not.

9.2.1.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the grant is not deleted.

9.2.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

9.2.2. If the result of the triggers is true, then Soffid adds the user to the group. This operation can return a true or false result.

9.2.2.1. False: the add action could not be performed and the process check for another grant [9. Group to add].

9.2.2.2. True: the add action could be performed properly. Soffid continues to the next step.

9.2.3. Then Soffid executes the post-insert triggers if any. These triggers can be used to perform a specific action just after performing the add grant operation on the target object.

9.2.4. Then the process continues through [9. Group to add].

10. End

The process finishes and the log is displayed, and you can download it by clicking the Download button.

AD Integration flows - Update account

Update

Introduction

Soffid provides a workflow to modify and/or delete an account in the final system. In it, we can see each of the steps of which this process is composed. 

Diagram

Step by Step

In this document, we will explain the process that Soffid performs to modify an account for the AD connector.

1. Initial step

First of all, Soffid checks if the account exists in Soffid and then checks the operation to perform, update or delete. 

1.1. If the user does not exist in Soffid, then Soffid asks to delete the user in the target System. 

❓ Warning message

1.1.1. Yes: If the answer is Yes, the process follows through the Yes branch, [3. Delete branch].

1.1.2. No:  If the answer is Yes, the process finishes [10. End]. 

1.2. If the user exists in Soffid, the process continues through [2. User to remove?]. to check if the 

2. Account to remove?

2.1. If the account is marked for Deletion, Soffid will ask for user consent to continue with the process or to cancel it. If the answer is Yes, the process follows through the Yes branch, [3. Delete branch].

❓ Warning message

2.2. If the account is marked for Update, it continues with the flow following through the No branch, [4. Insert or Update branch].

3. Delete branch

3.1. When the operation to perform is to delete an account, first of all, Soffid has to check if the account exists in the target system. 

3.1.1. If the account does not exist, there are no actions to perform in the target system, so the process finishes [10. End].

3.1.2. If the account exists, the flow continues executing the pre-delete triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, account delete, and the result (true or false) determines if the main action will be performed or not.

3.1.2.1. False: if the result is false for one or more of these triggers, the process finishes [10. End].

3.1.2.2.True: if the result is true for all of these triggers, Soffid continues to the next step.

3.1.3. Soffid removes the AD user in the Active directory.

3.1.3.  Then Soffid executes the post-delete triggers if any. These triggers can be used to perform a specific action just after performing the remove user operation on the target object.

3.1.3.  Then the process finishes [10. End].

4. Insert or Update branch

4.1. When the operation to perform is to update a user, first of all, Soffid generates the AD user.  That is, Soffid calculates the values of the AD user object from the original values of Soffid.

4.2.Then Soffid asks if the user exists in the target system to decide the action to execute, this action can be an update or an insert. 

4.2.1. If the user does not exist in the target system, the process continues through [5. Insert user branch]. 

4.2.2. If the user exists in the target system, the process continues through [6. Update user branch].

5. Insert user branch

5.1. Soffid executes the pre-insert triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user creates, and the result (true or false) determines if the main action will be performed or not.

5.1.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the user is not created in the target system.

5.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

5.2. Soffid creates AD user in the Active directory

5.3. Then Soffid executes post-insert triggers if any. These triggers can be used to perform a specific action just after performing the create user operation on the target object.

5.4. Then the process continues through [7. Groups].

6. Update user branch

6.1. Soffid checks if there are any change between the generated object and the values of the object in the target system.

6.1.1. False: if there are no changes,  the process finishes [10. End].

6.1.2. True: if there are changes to update, Soffid continues to the next step.

6.2. Soffid executes the pre-update triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, user update, and the result (true or false) determines if the main action will be performed or not.

6.2.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the user is not updated in the target system

6.2.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

6.3. Soffid updates the AD user in the Active directory

6.4. Then Soffid executes the post-update triggers if any. These triggers can be used to perform a specific action just after performing the update user operation on the target object.

6.6. Then the process continues through [7. Grants].

7. Grants

At this point, Soffid runs the actions relative to the grants. The operations can be to add the user to one or more groups or to remove the user from existing groups.

8. Group to remove

This is a loop while there are groups to remove.

8.1. If there are No groups to remove, the process goes to [9. Group to add].

8.2. Yes, there are groups to remove:

8.2.1. Soffid executes the pre-delete triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, a Remove user to group, and the result (true or false) determines if the main action will be performed or not.

8.2.1.1. False: if the response is false for one or more of these triggers, the process goes to [8. Group to remove] and the grant is not created.

8.2.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

8.2.3. If the result of the triggers is true, then Soffid adds the user to a group. 

8.2.4. Then Soffid executes the post-insert triggers if any. These triggers can be used to perform a specific action just after performing the create grant operation on the target object.

8.2.5.  Then the process continues through  [8. Grant to add].

9. Group to add

This is a loop while there are grants to remove. This grants list comes from the previous step [7. Grants].

9.1 No: If there are No grants to add, the process goes to [10. End].

9.2. Yes,  there are grants to remove:

9.2.1. Soffid executes the pre-insert triggers if there is anyone configured. More than one script can be configured. These scripts are executed just before the main action, Add user to group, and the result (true or false) determines if the main action will be performed or not.

9.2.1.1. False: if the response is false for one or more of these triggers, the process finishes [10. End] and the grant is not deleted.

9.2.1.2. True: if the response is true for all of these triggers, Soffid continues to the next step.

9.2.2. If the result of the triggers is true, then Soffid adds the user to the group. This operation can return a true or false result.

9.2.2.1. False: the add action could not be performed and the process check for another grant [9. Group to add].

9.2.2.2. True: the add action could be performed properly. Soffid continues to the next step.

9.2.3. Then Soffid executes the post-insert triggers if any. These triggers can be used to perform a specific action just after performing the add grant operation on the target object.

9.2.4. Then the process continues through [9. Group to add].

10. End

The process finishes and the log is displayed, and you can download it by clicking the Download button.

Zarafa Connector

Zarafa Connector

Introduction

Description

Zarafa Connector could manage a Zarafa mail server.

Managed System

This connector is specific for integration with a  Zarafa mail server.

For more information about the Zarafa, please visit the following page: Zarafa

For more information to check if your system may be synchronized with this connector you do not hesitate to contact us through our Contact form

Prerequisites

A Soffid Synchronization Server must be installed on the Zarafa server.

Download and Install

This addon is located in the Connectors section and its name is Zarafa Connector.

For more information about the installation process you can visit the Addons Getting started page.

Agent Configuration

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

To configure this Zarafa Connector you could select "Zimbra Agent" or the "Customizable Zimbra Agent" in the attribute "Type" of the generic parameters section in the agent's page configuration.

The difference between both agents is that "Customizable Zimbra Agent" allows "Attribute mapping" and includes "Account metadata".

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation:

Attribute mapping

This connector could manage Users, Groups, and Roles.

Users

• Every task is done using zarafa-admin tool. So its behavior depends on Zarafa server availability.
• Zarafa needs every user to have an email address. If a user has no email or short name, their name will be used as mail address.
• Soffid passwords' expiration date will be managed by Soffid. So, Linux won't be notified about when those passwords need to be expired.

Groups

• Groups will be created and removed as Zarafa groups.
• Currently, the group hierarchy is not registered in Zarafa.

Roles

• Roles bound to this system will be created as Zarafa groups.
• Any removed role will trigger the bound Zarafa group to be removed.

The "Attribute Mapping" tab is only accessible for the "Customizable Zimbra Agent".

Properties

No properties are defined for this agent.

Attributes

You can map users, groups, and role objects. These are some of the attributes to be mapped in those objects:

For more information about how you may configure attribute mapping, see the following link: Soffid Attribute Mapping Reference

For instance:

Triggers

Load triggers

Account metadata

Accounts are default objects in Soffid. Agents allow you to create additional custom data, on the "Account metadata" tab, to customize the accounts created only for that agent.

The attributes which you define here will be shown when you click on the proper account, on the Accounts Tabs on the users' page.

At this tab, you could add or delete custom attributes. You can visit the Metadata page for more information about the standard attributes.

Operational

Monitoring

After the agent configuration you could check on the monitoring page if the service is running in the Synchronization Server, please go to:

• Start Menu > Administration > Monitoring and reporting > Syscserver monitoring

Tasks

Authoritative

If you are checked "Authorized identity source", an automatic task to load identities from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will something like "Import authoritative data from <AGENT_NAME>".

Reconcile

If you are configured the "Attribute Mapping" tab with some of our objects: "user, account, role, group or grant", an automatic task to synchronize these objects from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will do something like "Reconcile all accounts from <AGENT_NAME>".

Synchronization

Regarding the synchronization of the objects, there are two possible options:

• If you are checked the generic attribute "Read Only" in the "Basics" tab, only the changes in the managed systems will be updated in Soffid. We recommend these options until the global configuration of Soffid will be tested.
• If you are not checked the generic attribute "Read Only" in the "Basics" tab, all the changes in Soffid or the managed system will be updated in the other. Note that this synchronization must be configured in the "Attribute mapping" tab correctly.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

SQL Server

SQL Server Connector

Introduction

Description

The SQL Server connector allows an easy way to configure and manage Microsoft SQL Server relational databases.

Managed System

This connector is specific for integration with the Microsoft SQL Server.

For more information to check if your system may be synchronized with this connector, do not hesitate to contact us through our Contact form

We can also manage more relational databases, for more information you can check the List of relational databases.

Prerequisites

It is needed a user with access and permissions to the schemes and tables required in the scope of the integration.

Download and Install

This addon is located in the Connectors section and its name is SQLServer.

For more information about the installation process, you can visit the Addons Getting started page.

Agent Configuration

This connector could manage User and Role objects.

Basic

Generic parameters

After the installation of the addon, you may create and configure agent instances.

To configure this SQL  Server connector you must select "SQLServer agent" in the attribute "Type" of the generic parameters section in the agent's page configuration.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Custom parameters

Below there are the specific parameters for this agent implementation:

jdbc:sqlserver://<HOST>;databaseName=<DATA_BASE>

Load triggers

You can define JavaScript or BeanShell scripts that will be triggered when data is loaded into Soffid (incoming triggers). The trigger result will be a boolean value, true to continue or false to stop.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation into Soffid objects. 

To view some examples, visit the Incoming triggers examples page.

Access Control

SQL Server connector can establish an access control for SQL Server Users.

If the access control checkbox is enabled, only the users and applications that are listed on the access control page will be allowed to log in. So, you can restrict the IP address,  the user roles, and the applications a user can connect from.

This restriction does not apply to DBA users.

Check that the user/account is not unmanaged.

When the Enable access control to the database check box is checked, the UpdateAccessControl task will be launched. The following tables will be created on the SQL Server:

• SC_OR_ACCLOG: access log
• SC_OR_CONACC: rule access control
• SC_OR_ROLE: user roles.
• SC_OR_VERSION: connector versions.

When you try to connect to SQL Server, the logon_audit_trigger is launched to check if you have access or not.

You can check the Access Logs page for access controls.

Account metadata

Agents allow you to create additional data, on the "Account metadata" tab, to customize the accounts created for that agent. This additional information will be loaded with the agent's information, or calculated as defined in the mappings.
The additional data can be used in both mappings and triggers.

The attributes that you define here will be shown when you click on the proper account, on the Accounts Tabs on the user page.

Operational

Monitoring

After the agent configuration you can check on the monitoring page if the service is running in the Synchronization Server, please go to:

• Start Menu > Administration > Monitoring and reporting > Syscserver monitoring

Tasks

Authoritative

If you checked "Authorized identity source", an automatic task to load identities from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will do something like "Import authoritative data from <AGENT_NAME>".

Reconcile

To manage an automatic task to synchronize user objects from the managed system to Soffid is available, please go to:

• Start Menu > Administration > Monitoring and reporting > Scheduled tasks

And you will do something like "Reconcile all accounts from <AGENT_NAME>".

Synchronization

Regarding the synchronization of the objects, there are two possible options:

• If you check the generic attribute "Read Only" in the "Basics" tab, only the changes in the managed systems will be updated in Soffid. We recommend these options until the global configuration of Soffid is tested.
• If you do not check the generic attribute "Read Only" in the "Basics" tab, all the changes in Soffid or the managed system will be updated in the other. Note that this synchronization must be configured in the "Attribute mapping" tab correctly.

For more information about how you may configure the generic parameters of the agent, see the following link: Agents configuration

Connectors Examples

Attribute mappings examples

Attributes

When you are configuring an agent, depending on the connector type, it will be able to define some attributes. The attributes depend on the object that you are configuring, and the objects depend on the connector type.

Get the value of an attribute (a user attribute in that case)

sAMAccountName <= userName
sAMAccountName => userName
sAMAccountName <=> userName

Get the value of a custom attribute

company <= attributes{"company"}
company => attributes{"company"}
company <=> attributes{"company"}

Get the value of an account metadata attribute

office <= accountAttributes{"office"}
office => accountAttributes{"office"}
office <=> accountAttributes{"office"}

Define a constant on the target system

nameConst <= "valueConst"

Assign the result of a script to the soffid attribute

return <SCRIPT> => attribute

Be in mind, it is allowed to use bean Shell expression only in the source when the mapping is one-way.

Assign the result of a script to the target attribute

attribute <= return <SCRIPT>

Be in mind, it is allowed to use bean Shell expression only in the source when the mapping is one-way.

Be in mind

If the attribute name in the final system is hyphenated, you have to use this expression: THIS{"ATTRIBUTENAME"}, for example THIS{"my-name"}

Outgoing triggers examples

Attribute mapping triggers

When you are configuring an agent and defining the attribute mappings of connectors, depending on the connector type, it will be able to define BeanShell scripts that will be triggered when data is loaded into the target system, outgoing triggers.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation into target objects. 

The trigger result will be a boolean value, true to continue or false to stop.

Use case examples

Example 1

Update or insert a user only when the user is internal (PreInsert User or PreUpdate User)

name = source{"userName"};
user = serviceLocator.getUserService().findUserByUserName(name);
if (user != null) {
  if (user.userType.equals("I")) {
      return true;
  }
}
return false;

Example 2

Update or insert a user only when the company is Soffid. Be in mind that company attribute is a custom attribute.

name = source{"userName"};
company = source{"attributes"}{"company"};
user = serviceLocator.getUserService().findUserByUserName(name);

if (user != null) {
  if (company != null && company.toUpperCase().equals("SOFFID")) {
  	return true; 
  }
}

return false;

Example 3

Recover a response and process it.

if (response != null) {
  for (o : response.getObjects()) {
  	if (o != null && o{"result"} != null) {
	  //TO-DO     
    }
  }
}
return true;

Example 4

Send a HTML mail with the response info.

.....
to = newObject{"identity"};
subject = "LinOTP QR";
body = o{"result"};
serviceLocator.getMailService().sendHtmlMailToActors(new String[] {to}, subject, body);
.......

Example 5

Update a user with the response info

.......
body = o{"result"};
ac = newObject{"user"};
data = new com.soffid.iam.api.UserData();
data.setAccountName(ac);
data.setSystemName("LinOTP");
data.setAttribute("token");
data.setBlobDataValue(body.getBytes());
serviceLocator.getAccountService().updateAccountAttribute(data);
......

Example 6

Call an API and process the response.

.......
userN = accontList.get(0).name;
result = dispatcherService.invoke(
	"GET",
  	"https://" + DOMINIO + "crmRestApi/resources/....?onlyData=true&q=Username=" + userN,
  	null);
if (result != null && !result.isEmpty()) {
  //TO-DO
} 
.......

Example 7

Pre Update: assign a value to an attribute depending on the value of a group attribute. The user can belong to many groups.

userName = source{"userName"};
attributes = serviceLocator.getUserService().findUserAttributes(userName);
dateChange = attributes.get("dateChange");

if (dateChange == null || dateChange == void ) {
	return true;
}

userGroupList = serviceLocator.getGroupService().findUsersGroupByUserName(userName);
contFalse = 0;
contNull  = 0;
isFound = false;
for (ug : userGroupList) {
  group = serviceLocator.getGroupService().findGroupByGroupName(ug.group);
  att = group.attributes.get("indicator");
  if (att != void) {
     if (att == null) contNull++;
     else if (att.equals("0")) contFalse++;
     else if (att.equals("1")) {
       isFound  = true; 
       break;
     } 
  }  
}

if (isFound) {
  newObject{"id-indicator"} = "1";
} else {
  if (contFalse > 0) {
    newObject{"id-indicator"} = "0"; 
  } else if (contNull > 0) {
    newObject{"id-indicator"} =  null;
  } 
} 
    
return true;

Incoming triggers examples

Load triggers

When you are configuring an agent, depending on the connector type, it will be able to define BeanShell scripts that will be triggered when data is loaded into Soffid, incoming triggers.

Triggers can be used to validate or perform a specific action just before performing an operation or just after performing an operation into Soffid objects. 

The trigger result will be a boolean value, true to continue or false to stop.

Use case examples

Example 1

A user can have more than one account on a target system. We want to reconcile only those accounts which have the same name on Soffid and on target system.

name = newObject{"accountName"};
uaList = serviceLocator.getAccountService().findUsersAccounts(name,"agentName");

for(userAccount: uaList) {
  if (userAccount.name.equals(name)) {
    return true;
  } else  {
    return false;
  }
}

return false;

Example 2

Update only users who belong to Soffid company.

name = newObject{"accountName"};
user = serviceLocator.getUserService().findUserByUserName(name);

if (user != null) {
  attributes = serviceLocator.getUserService().findUserAttributes(name);
  company = attributes.get("company");
  if (company != null && company.equals("Soffid")) {
  	return true;
}
return false;
  

Example 3

Discard to create some accounts (PreInsert account).

log.info("************** Pre Insert Account");
cuentas = new java.util.HashMap();
cuentas.put("admin",null);
account = newObject{"accountName"};

if (cuentas.containsKey(account)) {
  log.info("TRIGGER ACCOUNT PREINSERT - Discarded to create the account " + account);
  return false;
}

log.info("TRIGGER ACCOUNT PREINSERT - Correct account " + account);
return true;

Example 4

If does not exist a mail domain, it wil be created.

mailDomain = newObject{"mailDomain"};
if (mailDomain != void && mailDomain != null) {
  existMD = serviceLocator.getMailListsService().findMailDomainByName(mailDomain);
  if (existMD == null) {
    newMailDomain = new com.soffid.iam.api.MailDomain();
    newMailDomain.setName(mailDomain);
    newMailDomain.setDescription(mailDomain);
    serviceLocator.getMailListsService().create(newMailDomain);
  }
}
return true;

Example 5

Avoid deleting users (PreDelete user).

return false;

Example 6

If throw the exception, the return will be is false. True in other cases.

if (....) 
  throw new Exception("Exception message....");
return true;

Example 7

The new group on the target system will have the same id that the old group.

newObject{"idGroup"} = oldObject{"idGroup"};
.....

Example 8

Get the attribute company option 1:

company = source{"attributes"}{"company"};

Get the attribute company option 2

userName = source{"userName"};
attributes = serviceLocator.getUserService().findUserAttributes(userName);
company = attributes.get("company");

Example 9

Update the company attribute:

userName = newObject{"userName"};
// Check if the user exists 
user = serviceLocator.getUserService().findUserByUserName(userName);
if (user == null) {
	return false;
} 
log.info("***************** USER Object: " + user);

attributes = serviceLocator.getUserService().findUserAttributes(userName);
if (attributes == null) {
	attributes = new HashMap();
} 

attributes.put("company", "<COMPANY_NAME>");
serviceLocator.getUserService().updateUserAttributes(userName, attributes);

return true;

Example 10

Check user type

userName = newObject{"userName"};
user = serviceLocator.getUserService().findUserByUserName(userName);

if (user.userType.equals("I")){
  .....
  //TODO
} else {
    .....
  //TODO
}
return true;

Triggers: Script Tips

Triggers: Script Tips

Here we will show you some tips about how to use scripts.

For more information you can visit the official documentation of Soffid

Write into a sync-server log

System.out.println("what you want......");

Recover data from a Soffid object when synchronizing

* source only can be used in outgoing triggers. That object will be Soffid format.

* newObject and oldObject can be used in outgoing and incoming triggers. Those objects will be target system format in outgoing triggers and will be Soffid format in incoming triggers.

Recover data from Soffid object to synchronize

Recover user name

name = source{"userName"};

Recover a custom attribute

Recover company (company could be a user custom attribute defined on metadata page)

comp = source{"attributes"}{"company"};

Recover the attribute value that will be sent

no = newObject{"userName"};
gn = newObject{"givenName"};
....

Recover the attribute value from the select

That info comes from the target system. In a synchronization process, the first thing that Soffid does, is to query if the account exists on the target system.

no = oldObject{"userName"};
gn = oldObject{"givenName"};
....

Use  existing services

serviceLocator.getUserService().....
serviceLocator.getAccountService().....
serviceLocator.......

Create a new Soffid object

mailDomain = new com.soffid.iam.api.MailDomain();
newUser = new com.soffid.iam.api.User();
newRol = new com.soffid.iam.api.Role();
............

Loop an object list

for(role : roleList){
  //TO-DO
  out.print(" Role: " + role.roleName + "\n");
}

Recover response

if (response!=null) {
  for (o : response.getObjects()) {
    if (o!=null && o{"result"}!=null) {
      //TO-DO
    }
  }
}

Send a text email 

serviceLocator.getMailService().sendTextMail("mail@soffid.com", "Subject", "Mail message");

Send a HTML mail 

serviceLocator.getMailService().sendHtmlMailToActors(<to>, <subject>, <html-body>);