Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Coming soon!Zilla supports generic application integration through APIs for custom application as well as applications which do not support API integration.

Below are the steps on how to enable generic integration for applications with the configuration details.

  1. Login to Zilla as admin.

  2. Click Add application in the top right corner.

    Image Added

  3. On the Add Application page search for the application you want to add to Zilla, click Add to Applications if found. Otherwise, add a custom application by going to the Custom Application tab.

    Image Added

Add details for the custom application and click Add to Applications.

Info

Note: Name of the application can never be Generic, GenericOauth, generic, or generic oauth.

...

4. You will be redirected to the application page.

...

5. Click the Gear icon in the top right to the left of Sync now.

6. You will see the configuration dialog, click Show Alternate Configuration Options.

...

7. Enable API Integration, you will see configuration entries to be filled in.

...

8. Enter the configuration based on the details given below:

Info

Note: Applications like Google workspace, GCP, Gitlab can not be scheduled as the user has to give consent for these applications each time.

  • Base URL: Base URL for an application API which we can be found in the developer documentation for the application. Example: For AHA it would be https://{org domain}/api/v1/.

  • Authorization Header Name: Name of the header used to pass the token or API key. Many times this is Authorization. Example: For AHA it would be Authorization. If not required, leave blank.

  • Authorization Header Value: The value for the authorization could be API key (Normal or base64 encoded) and the prefix for the API key could be Bearer or Basic followed by space and then API key. Example: For AHA the API key is a normal key with Bearer as a prefix so the header value will be Bearer APIkey. If not required, leave blank.

  • Pagination strategy: Currently Zilla only supports limit-offset pagination for generic integration so the value must be limit-offset.

  • Accounts Endpoint: The endpoint for listing all the users or accounts for an application. Example: For AHA it is users.

  • Accounts Response Property: The key value for the users' array IF the response from the API call contains JSON and the users' array is inside a field. Example: For AHA the JSON response of type has users inside users field so the value for this config would be .users. If not required, leave blank.

    Code Block
    languagejson
    {
      pagelen: number,
      size: number
      users: [
              {user1 object},
              {user1 object}
             ]
    }

  • Accounts Property Overrides: The mapping for the response from the API to Zilla fields. Example: For AHA we get the following response for a single user:

    Code Block
    {
      userId: string,
      name: string,
      firstname: string,
      lastname: string,
      enabled: boolean,
      roles: string[],
      email: string,
      lastLoggedIn: Date,
      EID: string
      .
      .
      .
      so on
    }

So the mapping would be:

Code Block
{
  "id": "userId",
  "username": "name",
  "firstName": "firstname",
  "lastName": "lastname",
  "status": "enabled",
  "email": "email",
  "roles": "roles",
  "lastLogin": "lastLoggedIn",
  "employeeId": "EID"
}

The left field denotes the Zilla fields and the right one denotes the fields from the API response.

Info

Note: If the Zilla fields and the fields from the API response are the same then this configuration property can be left blank.

  • Account Active Statuses: The status (active or inactive status) response from the API. Value could be true, enabled, active, provisioned, etc. Examples: For AHA we get true as active status so the value for this config would be true and for Okta, we get PROVISIONED so the value for this config would be PROVISIONED.

  • Authorization Url: The endpoint for the authorization server, used to get the authorization code. Example: For Okta it is https://{orgdomain}/oauth2/v1/authorize.

  • Token Url: The endpoint for the authentication server. This is used to exchange the authorization code for an access token. Example: For Okta it is https://{orgdomain}/oauth2/v1/token.

  • Client Id: The client Id issued to the client during the application registration process.

  • Client Secret: The client secret issued to the client during the application registration process.

  • Space separated scopes: The scope of the access request. It may have multiple space-delimited values.

9. Click Next/Sync now to start the sync.

Info

Notes:

  1. It is recommended to refer to developer documentation before doing generic sync.

  2. Authorization Url, Token Url, Client Id, Client Secret, and Space separated scopes are optional if the user syncs without oauth. Then the header name and value could be added which are also optional if the API does not support authentication.

Please contact Support@zillasecurity.com for assistance.