1. Federation
  2. Prerequisites

Federation

Prerequisites

Using multiple IdentityHubs as federated services

When using multiple instances of the IdentityHub there may be some flaws to take into account, depending on your use case.

The fundemental idea of federation is to split a graphql schema into smaller parts, so microservices can take care of their own small responsibility. A gateway would then serve as the API that connects the different services to a single schema. The IdentityHub could be used as a gateway including its own schema and tie up several other graphql APIs.

Since the IdentityHub brings its own types like ldap User, Container etc., there may be problems if you try to connect several services that contain the same types. For example you may want to unite an eDirectory User type and an Active Directory User type. A referable schema extension that extends the original User type would not work, because both types have the same name. This can be solved via a configured graphql prefix.

GraphQL type prefix

In the graphql config there is a new option typePrefix. You can configure it like that:

[graphql]
  typePrefix="somePrefix_"

This configuration will take care of the prefixing of all types via a transformation. After that the User type will be named someprefix_User, etc. This also applies for all query names. So in the described case for querying an eDirectory and an Active Directory, you can start the IdentityHub instance for the Active Directory with a typePrefix AD_. After that you are able to send for example the following query to that server instance:

query users {
  AD_users(paging: {...}, by: {...}) {
    nodes {
      dn
      fullName
    }
  }
}

The query for the eDirectory will be unchanged:

query users {
  users(paging: {...}, by: {...}) {
    nodes {
      dn
      fullName
    }
  }
}

schema extensions

Also the schema extensions need to respect the prefixed types. While a valid schema extension for the unprefixed schema (i.e. eDirectory) may look like this:

extend type User {
  customName: String @ldapField(attribute: "abc")
}

For a prefixed server you must write (configured prefix is 'AD_'):

extend type AD_User {
  customName: String @ldapField(attribute: "abc")
}

All directives will work on all service instances.