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.
Login to Zilla as admin.
Click
Add application
in the top right corner.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 theCustom Application
tab.
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:
Frequency: to schedule integration. See Scheduling an automated sync for more details.
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 beAuthorization
. 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 belimit-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 language json { 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 betrue
and for Okta, we getPROVISIONED
so the value for this config would bePROVISIONED
.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:
|
Please contact Support@zillasecurity.com for assistance.