Skip to content

Persons partitioning

This guide describes how persons partitioning works and will guide you through the steps required to configure it.

Persons partitioning divides persons repository into partitions. It means that person must be unique within each partition, where uniqueness is achieved by partition identifier and email address. Thanks to this solution Onegini IdP can have more than one account with the same email address.

The idea behind this feature is to replace multiple Onegini IdP instances with only one.

Prerequisites

To successfully complete this topic guide you need to ensure following prerequisites:

  • Onegini IdP instance must to be running, for the sake of this guide we assume it's available under http://idp-core.dev.onegini.me address
  • access to Onegini IdP extension project
  • external idp needs to be added in Onegini IdP admin panel, e.g. facebook or ldap

Integration

The implementation requires following steps to be done:

  1. Implement required interface PreSessionProcessExtension on extension level. Interface is responsible for determining which person partition will be used in case of web browser access. It consumes hostname and should return related personsPartitionId and localeVariantCode.
  2. Implement optional interface PartitionIdListProvider on extension level. Interface is responsible for returning list of available personsPartitionId and localeVariantCode.
  3. Set IDP_PARTITIONING_PERSONS_ENABLED to true on extension level.

Partitioning in the web layer works without additional steps but API and SAML requests require X-Onegini-Persons-Partition-Id header to be set. It should contain partition id to be used, if no header specified then default partition is used.

Testing

Prepare environment to support two domains on prepared Onegini IdP instance and add partitioning support for them.

Web layer scenario:

  1. Create a user in the first domain.
  2. Go to the second domain. Creating a user with same email address should be possible.
  3. Go to the first domain and use configured external idp to log in.
  4. Go to the second domain and log in with configured external idp by using the same credentials as in previous step.
  5. Change email/phone in the second domain and logout.
  6. Get back to the first domain and use external idp to log in. You should not see any changes done on the account in the second domain.

API layer scenario:

  1. Create a proper API request to create user. Set a X-Onegini-Persons-Partition-Id header with person's partition id related to first domain. Execute a request.
  2. Try to login via browser on first domain - should be successful.
  3. Go to second domain. Login should show wrong credential page when you provide the credentials that was used to create account via API.

Supported API endpoints

  • /api/persons/
  • /api/persons/{personId}
  • /api/persons/{personId}/password-reset
  • /api/persons/{personId}/custom-attributes
  • /api/persons/{personId}/couple
  • /api/persons/couple/{identityProviderType}/{externalIdpId}
  • /api/persons/search
  • /api/credentials/validate
  • /api/migration/status