Please contact us, and we’ll be happy to help. If we consider your requirement generic, we’ll provide it for free, and provide an estimated date stating when we would make this available.

CI is made to be thoroughly user-friendly. Since the nature of identity management is technical, there is still some technical configuration required. To make this as easy as possible, CI comes with guided walk-throughs for all the tasks you will need to perform. Note that the guided flows will “break” if you take a different path from the steps, and you will need to restart from the beginning to get the guided tour back. Starting the guided flow while already in a configuration task will confuse the help system.

1.Login using the administrator link (see the welcome mail from product.support@crossidentity.com)

• Make sure to change the initial password we send

2. Setup (and reconfigure, if you opted for the pre-populated system) in the following order:

• Configure Active Directory & import Users & Roles (optional)
• Configure your web applications1 for SSO (optional)
• Configure your SAML application2 for SSO (optional)
• Configure your desktop application3 for SSO (optional)
• Add other provisioning applications4 (optional)
• Add ‘AD’ as a directory for authentication5 (Optional)
• Configure Roles6 as Static7 or Dynamic8 (optional)
• Create users (optional)
• Creates users manually, and/or
• Import users from a .CSV file
• Configure SMTP server9 (or use the one pre-configured for free)
• Configure SMS10 (or use the pre-configured one for free)

3. Each user will get a system generated mail with their login credentials but without the login URL

4. After you send them a mail with the User Login URL, users will login, change their password, and start using the system

•  By ‘web applications’ we mean websites like banking & news that do not normally support SSO
•  ‘SAML’ applications are those like Gsuite that support the SAML protocol for SSO
• Desktop applications are on-premise applications, like Putty, that require the user to enter their credentials for login. For CI on the cloud to communicate with your desktop applications, a small executable will be required on each user’s desktop. The first time you try to login to a desktop application you will be prompted to download and install an executable.
• “Provisioning Applications” are those applications that support far more features than just SSO. These applications support user creation, access permissions to specific capabilities (called entitlements) and overall user management into these applications. Active Directory is one such provisioning application, and if configured, users that are created in CI, or if passwords are changed in CI, are synchronized (provisioned) in AD. There are about 30 provisioning apps available at this time, with more applications being added every week. Ask us if you need a connector that is not available, and we’ll build it for you (either for free or for a nominal charge, based on the application’s popularity).
• ‘AD as directory’ implies that CI will use the authentication mechanism of AD, instead of its own
• The most common way to configure application access is to specify the roles of who can access each application. Users are assigned to roles, and this automates the access they have. There are two ways to decide the role for users when they are onboarded: Static & Dynamic.
• Static Roles are user groups where the users are explicitly specified to belong to that role. Roles imported from AD are always Static since users in the AD group are set to the CI Role.
• The recommended way for non-AD imported Roles is to define Dynamic Roles. This way users are given access based on their user profile, as well as get new accesses (and removal of others) based on changes in their profile.
• SMTP server is the settings of your internal mail server that CI will use to send out emails.
• SMS support (normally needed for Multi-factor authentication) requires you to configure this.