This section describes options for importing users into the application from a corporate directory. An iOffice representative will work with the customer to understand needs and requirements, as each process varies based on module, customer and business requirements.
Import Via SFTP
The customer uploads a file to iOFFICE's SFTP server on an interval determined at their discretion. The SFTP account is exclusive to the customer, securely isolated from other customer accounts. The customer’s developer has the option of using either a password- or key-based authentication, and inbound connections to iOFFICE's SFTP server can be blocked after a predefined number of login attempts for additional security.
Once the process is in place, the customer will upload a file. When complete, iOFFICE's directory watcher process will pick up the file and begin processing automatically.
Additional Encryption Using PGP
Files sent to our SFTP server are fully encrypted in transit and are only accessible to employees who require access for business purposes, with access granted using the principle of least privilege. Additionally, all files stored on the SFTP server at Azure are encrypted at rest using transparent data encryption (TDE); however, if your security team requires an additional layer of encryption for SFTP import files, iOFFICE can also support PGP encryption using the RSA protocol.
File Format and Requirements
File format options are flexible, allowing delimiter separated values (comma, tab, pipe) or XML. The name of the file must be alphanumeric and the only special characters allowed in the file name are '-' (hyphen), '_' (underscore), or '.' (period). No spaces are allowed. Delimited files must have a header row and fields should be qualified with double quotes. It is iOFFICEʼs experience that XML is the most reliable file format, as a closing element confirms a complete file has been received.
iOFFICE requires a field with a unique key (such as an employee id). This key maps existing user records with data in the customer’s file. Users in the file without a matching record in the application will have an account created for them. Accordingly, users in the application without a matching record in the file are deactivated. Matching user records are updated if required.
Standard required fields are: employee ID (any unique identifier may be used as a substitute), first name, last name and email. Depending on use case, other fields may be needed.