Request & Response Reference

Every action, shown as a request/response pair worked through against a complete example connector that implements all of them. The same ConnectorCommand → ConnectorResult/ProvisioningResult contract applies to any connector; connectionInfo shape is the only thing that varies by target system.

Each section also includes the connector's real Java method — trimmed to show only request validation and response publishing. Target-system-specific work (opening a connection, reading/writing the account, and so on) is marked // business logic elided; that part is entirely up to your connector and the system it talks to.

Connector identity and dispatch

connectorName() is what Zetect matches against every command's connectorName field to route it to your plugin. handle() and handleProvisioning() are each a single switch on cmd.getAction() — this is the connector's complete SPI surface, unabridged:

11

IDENTITY_SYNC / SYNC_USER / SYNC_GROUP

Read-only aggregation. Routed to handle(). Supports an optional chunkSize — when set, the result is split across multiple ConnectorResult messages instead of one.

15

Response — one of several messages when chunked:

16

chunkSize missing, null, or 0 → unchanged legacy behavior: exactly one publish, no chunkIndex/chunkCount/lastChunk fields at all.

23

CREATE_ACCOUNT

Routed to handleProvisioning(). connectionInfo omitted below — same shape as above.

26

27

Two connector-specific behaviors worth knowing: the top-level password field is preferred, falling back to attributeMappings.password; and the account is only created enabled when a password is supplied and the connection is secure — otherwise it's created disabled, pending a follow-up RESET_PASSWORD. This is a common pattern for target systems that refuse to accept a password write over an unencrypted connection at all.

30

UPDATE_ACCOUNT

subject.nativeAccountIdentifier is required — it's how the existing account is located. Every key in attributeMappings is applied as an update.

33

34

35

ADD_TO_GROUP

Identifies the user via subject.nativeAccountIdentifier, falling back to attributeMappings.username. entitlements lists one or more target groups.

39

40

If the account doesn't exist yet, it's auto-created first (disabled, same defaults as CREATE_ACCOUNT) before the group modification — no separate CREATE_ACCOUNT call is required ahead of the first ADD_TO_GROUP for a given user.

41

REMOVE_FROM_GROUP

Same shape as ADD_TO_GROUP, but subject.nativeAccountIdentifier is required (no auto-create — there's nothing to remove from a group if the account was never created).

43

44

DELETE_ACCOUNT

45

46

47

RESET_PASSWORD

Same top-level password preference as CREATE_ACCOUNT (falls back to attributeMappings.password / .newPassword). Always requires a secure connection — fails immediately, before touching the target system, if the connection isn't secure.

51

52

If the account was disabled, a successful password set clears that too — a disabled account created without a password becomes usable again the moment RESET_PASSWORD runs.

53