Identity and access management
Remote to Ping Identity integration: people from Remote as PingOne users per country
With an integration between Remote and Ping Identity, everyone who works for you through Remote becomes a user in PingOne, in the population of their country and with employment type, department and manager. Sign-in is enabled when Remote sets the employment to active, and disabled on a suspension or on the confirmed end date.
What the integration does
Organisations that use PingOne as their identity provider and employ people through Remote often create those people by hand in PingOne. When someone finishes onboarding at Remote, is suspended or leaves, IT only hears about it later, and sign-in stays possible too long or starts too late.
- Remote gets a Customer API token with read scopes only and webhooks for employment and user status; PingOne gets a Worker app with the Identity Data Admin role.
- We create a population per country in PingOne, or one population with country groups, as you choose.
- For an invited employment KoppelHet creates the user with sign-in blocked and a work email as username.
- When Remote sets the employment to active, KoppelHet enables sign-in and the department's groups.
- On a suspension or on the confirmed end date KoppelHet blocks sign-in; deletion follows after the retention period.
What to watch for with Remote and Ping Identity
- Remote offers a SCIM endpoint you can only read, and PingOne accepts SCIM users that another system delivers. Neither of the two therefore sends anything itself. KoppelHet reads Remote and writes to PingOne, so the two SCIM sides still connect.
- Remote's SCIM data gives email addresses with a type, personal or work, and for a new employee often only the personal address is there. With PingID a username in PingOne can no longer change after creation. KoppelHet therefore never uses the personal address, but a work email following your rule.
- People through Remote work in many countries, and PingOne puts every user in one population, with a separate call to move. KoppelHet chooses the population by the employment's country and sets the country code in the two upper-case letters PingOne requires, so policies per country work.
- Remote reports with its own webhook when a user becomes active after onboarding. KoppelHet only enables sign-in to PingOne at that moment, so someone who is invited but still in onboarding or review cannot reach the apps yet.
- Remote sets a user to inactive when their employment is suspended, and sends a webhook each time. KoppelHet blocks sign-in to PingOne on that notification and enables it again on the notification that the user is active, without deleting the user or their MFA device.
- An offboarding at Remote can get a different end date after the country check, and confidential offboardings are not in the normal list. KoppelHet requests those separately and blocks sign-in on the date Remote has processed, without putting anything about the reason in PingOne.
- Remote has EOR employees, contractors, direct employees and global payroll. The type field in PingOne has no fixed meaning. KoppelHet fills it with the type from Remote, so sign-in policies and MFA requirements for contractors can differ from those for employees.
This integration is also part of joiner, mover, leaver.
How we build and run it
- The integration runs on the KoppelHet platform, hosted in a data centre in the EU.
- Every sync and every error is visible in the functional log; on an error your administrator is notified.
- A change that cannot go through is not half-applied but queued for another attempt.
- KoppelHet is ISO 27001 certified. Data travels encrypted and stays on the platform no longer than needed.
- After go-live we manage the integration and adjust it when your process changes.
- The integration fits next to your existing integration layer. Only the fields in the design are transferred; the platform keeps no register of its own.
Implementation and price
This is not an app you switch on. We build the integration for your organisation on our platform, with building blocks we reuse on every project. So it is custom work that does not start from scratch.
A consultant prepares the intake and analyses both systems. We then record the mapping and exceptions field by field, test in the test or acceptance environment and go live at a moment you choose. Costs are a one-off amount for the setup and a monthly amount for platform, monitoring and support.
Frequently asked questions
Can Remote and PingOne not talk directly through SCIM?
No. Remote offers SCIM for reading only and PingOne expects someone to deliver. KoppelHet sits in between.
What happens with a suspended employment?
Sign-in is disabled until Remote reports the user as active again. The user remains in place.
Does pay data go to PingOne?
No. The token only reads employment and personal data needed for accounts.
Technical details for IT
For those who want to know how it works under the hood: APIs, fields and sources used.
- KoppelHet reads Remote through the Remote API (gateway.remote.com) with a Customer API token: GET /v1/employments (status, type, country), SCIM GET /v1/scim/v2/Users (read only; emails with type, department and manager in the enterprise extension), webhooks with X-Remote-Signature (employment.user_status.activated and employment.user_status.deactivated) and confidential offboardings with include_confidential.
- PingOne with a Worker app with the Identity Data Admin role: users through /v1/environments/{envID}/users with externalId, username (unique, at most 128 characters, immutable with PingID), type (at most 256 characters) and address.countryCode (ISO 3166-1 alpha-2, upper case); population.id through the population sub-resource; sign-in through the separate enabled call; groups through the Platform API. PingOne's inbound provisioners are LDAP Gateway, SCIM and Workday.
Which fields are transferred
The key fields. The full mapping is agreed per customer.
| Field in Remote | Field in Ping Identity | Notes |
|---|---|---|
employment id | externalId | |
name.givenName en name.familyName (SCIM) | name.given en name.family | |
Naamgevingsregel (nooit het persoonlijke adres) | username en email | |
type | type | |
country | address.countryCode en population | |
department (SCIM) | Groep | |
status en user_status | Aanmelden aan of uit | |
Bevestigde einddatum offboarding | Aanmelden uit |
Related
Greenhouse → Remote
Greenhouse to Remote integration: foreign hires as EOR employment with the country's form
Recruitee → Remote
Recruitee to Remote integration: hires abroad straight into an employment at Remote
Remote → 4PS Construct
Remote to 4PS Construct integration: own employees of the construction entity from Remote in 4PS
Remote → Active Directory
Remote to Active Directory integration: accounts for colleagues in other countries