User Ids cannot be something sepcified entirely by the Federation providers. If they are, there are a handful of potential problems:
1. The userId specified will be too big for the colum (varchar 64)
2. Two different Identity Providers can provide the same value for user_id
The solution is to use the id_mapping capability of the identity backend. This should be enabled on a per-idp basis, and the default should be enabled.
The id_mapping approach needs a separate domain_id to deconflict userids. This domain should be created by default and linked 1-to-1 with the IdP id.
User Ids cannot be something sepcified entirely by the Federation providers. If they are, there are a handful of potential problems:
1. The userId specified will be too big for the colum (varchar 64)
2. Two different Identity Providers can provide the same value for user_id
The solution is to use the id_mapping capability of the identity backend. This should be enabled on a per-idp basis, and the default should be enabled.
The id_mapping approach needs a separate domain_id to deconflict userids. This domain should be created by default and linked 1-to-1 with the IdP id.