Open sattvikc opened 2 months ago
When the backend SDK asks for tenant config, we will return the enabled booleans based on:
NOTE: We have to tell users that the new CDI will be breaking in how you create tenants. Instead of passing enabled booleans, you need to pass in firstFactors array ONLY. When the backend SDK asks for tenant config, we will return the enabled booleans based on:
NOTE: We have to tell users that the new CDI will be breaking in how you create tenants. Instead of passing enabled booleans, you need to pass in firstFactors array ONLY.
Introduce new state []
(empty) for firstFactors and providers
{
emailPasswordEnabled: boolean,
passwordlessEnabled: boolean,
thirdPartyEnabled: boolean,
firstFactors?: null | string[], // null, empty, non-empty
requiredSecondaryFactors: string[], // null, non-empty
providers: null | Provider[] // null, empty, non-empty
}
isEmailPasswordEnabled = emailPasswordEnabled || (firstFactors != null && firstFactors.includes('emailpassword')) || (requiredSecondaryFactors != null && requiredSecondaryFactors.includes('emailpassword'))
isThirdPartyEnabled = thirdPartyEnabled || (firstFactors != null && firstFactors.includes('thirdparty')) || (requiredSecondaryFactors != null && requiredSecondaryFactors.includes('thirdparty'))
isPasswordlessEnabled = passwordlessEnabled || (firstFactors != null && firstFactors.includesOneOf('otp-email', 'otp-phone', 'link-email', 'link-phone')) || (requiredSecondaryFactors != null && requiredSecondaryFactors.includesOneOf('otp-email', 'otp-phone', 'link-email', 'link-phone'))
In the above conditions, we have three parts with OR conditions:
Note: v2 means new endpoint for create/update and get/list tenants
/v2
suffix{
tenantId: string;
firstFactors?: null | string[], // allows empty array
requiredSecondaryFactors: null | string[], // does not allow empty array
coreConfig: any,
}
{
tenantId: string;
firstFactors?: string[]; // undefined or empty or non-empty
requiredSecondaryFactors?: string[]; // undefined or non-empty
thirdParty: {
providers?: Provider[]; // undefined or empty or non-empty
};
coreConfig: any;
}
firstFactors
is set to null
, providers
is set to null
firstFactors
(if not provided) is set to null
, providers
is set to null
Edge cases:
firstFactors
is set to null
firstFactors
is set to []
firstFactors
(if not provided) is set to null
, providers
is set to null
empty
state for firstFactors and providers. So, empty state is considered as null
, which will effectively use the static config from SDK.emailpassword
in firstFactor without having emailPasswordEnabled set to true.firstFactors
is set to null
firstFactors
is set to []
firstFactors
is set to null
firstFactors
is set to []
Edge cases
isFirstFactorsNull
is set to falseisThirdPartyProvidersNull
is set to falsefirstFactors
will be set to null, so in the dashboard we show all available factors based on how SDK is initialisedfirstFactors
fieldfirstFactors
, the firstFactors will never get to the null
stateproviders
will be set to null, so we show all statically defined providersproviders
to be set to null
firstFactors
was null, then same rules as 4.0 tenant will applyfirstFactors
, the firstFactors will never get to the null
stateproviders
was null, then same rules as 4.0 tenant will applyproviders
to be set to null
firstFactors
and providers
are set to []
Using MFA with static config of firstFactors and requiredSecondary factors
With Core migrated, but the SDK is not updated yet:
The tenants have firstFactors
set to null
, which will remain as is post migration. This also means that the user would have enabled necessary recipes that are being used.
null
for firstFactors
and then SDK will use the static config as expected.With core migratied and the SDK updated:
null
for firstFactors
and effectively static config will be usedUsing MFA with firstFactors and requiredSecondaryFactors configured in the tenant
With Core migrated, but the SDK is not updated yet:
firstFactors
and requiredSecondaryFactors
will return values as is and effectively they will be used in the SDK.firstFactors
and requiredSecondaryFactors
With core migratied and the SDK updated:
Using dashboard to create new tenants, but there are also existing tenants and Backend is still on an older CDI:
First Factors
firstFactors
set to null. Effectively this will use the static config. On switching any of the toggles, firstFactors
will be updated and it will never get to null
state from the dashboard.
firstFactors
since it's no more set to null. Original booleans will be ignored.firstFactors
as isfirstFactors
and the recipe booleans, we only show first factors in the dashboard. Toggling any of it will only update the firstFactors
and leave the booleans as is.
Secondary Factors
requiredSecondaryFactors
set to null
. Toggling them will update the requiredSecondaryFactors
requiredSecondaryFactors
is considered.requiredSecondaryFactors
requiredSecondaryFactors
and the recipe booleans, we only show secondary factors in the dashboard. Toggling any of it will only update the requiredSecondaryFactors
and leave the booleans as is.Creation of new tenants
firstFactors
set to []
by default. Which means, all the first factors will be disabled by default. Toggling them just updates the firstFactors
array. It will never get to null
state.
firstFactors
database states
enabled booleans for latest node SDK: filtering out the first and second factors that have boolean set to false for py/go SDK: frontend uses subset of this as first factors based on what is initialised in the frontend static config
firstFactors null: for latest node SDK: use backend static config. It will throw an error on frontend if all the recipes from this array are not initialised for py/go SDK: implies all recipe booleans are true []: for latest node SDK: no login allowed for py/go SDK: all enabled booleans are false ["emailpassword", "thirdparty"]: for latest node SDK: it means we use subset of this based on which recipe is initialised in the backend static config. This will overwrite mfa.init(firstFactors) It will throw an error on frontend if all the recipes from this array are not initialised for py/go SDK: only enabled booleans associated with the factors are true, rest false. What is rendered on frontend is subset of this based on which recipe is initialised in the frontend static config
requiredSecondaryFactors null: for latest node SDK: MFA is not enabled for py/go SDK: not applicable ["otp-phone"]: for latest node SDK: enables subset based on backend SDK initialised recipes (check with Mihaly) for py/go SDK: not applicable
providers TODO
Intention
If the backend SDK makes calls to any recipe APIs is allowed
effect on enabledBoolean
Intention
If the backend SDK makes calls to any recipe APIs is disallowed
effect on enabledBoolean
Intention
If the backend SDK makes calls to emailPassword APIs, it should be allowed in the core
effect on enabledBoolean
Intention
EmailPassword APIs are blocked by the core
effect on enabledBoolean
similarly for thirdparty and passwordless
Intention
If the backend SDK makes calls to any recipe APIs is allowed
effect on enabledBoolean
Intention
If the backend SDK makes calls to any recipe APIs is disallowed
effect on enabledBoolean
Intention
let the sdk use emailpassword as either first or second factor
effect on enabledBoolean
Intention
EmailPassword APIs are blocked by the core
effect on enabledBoolean
Intention
To use backend static config (mfa.init(firstfactors) or initialized recipes) for firstFactors for the tenant
effect on enabledBoolean
Intention
Ignore Mfa.init(firstFactors) and initialized recipes in the backend SDK and use this value instead
effect on enabledBoolean
🐛 Bug Report
Changes to the core:
When a new tenant is created, we set all enabled booleans to true, and firstFactor array as. When a new tenant is created, we set all enabled boolean to true, and firstFactor undefined for public AND non public tenants.EDIT: for non public tenants, we will set it to[]
by default because:Modifying the static list wont affect existing tenant config by default (other than the public tenant).Via the UI there is no way to make a tenant have undefined as firstFactors, so it's weird that it starts of as undefined and then there is no way for the UI to go back to that state.firstFactors array being empty vs not being set needs to be distinguished. firstFactor would be undefined for static config to take into affect.For older CDI ->if firstFactor.length > 0, then we only set those enabled flagsif firstFactor.length === 0, then we have all as falseif firstFactor is undefined, then we return the booleans as they are (needs to be communicated as a change to developers).Backend SDK changes:
Docs changes
Migration of tenant config:
Things to note:
Useful informations
(Write what happened. Add screenshots, stacktraces, videos, anything that can help)
TODO