Fix a couple of typos in user-federation.adoc
Fix a couple of typos.
This commit is contained in:
parent
56afcd47e0
commit
9a6d839441
1 changed files with 2 additions and 2 deletions
|
@ -3,7 +3,7 @@
|
|||
== User Storage Federation
|
||||
|
||||
Many companies have existing user databases that hold information about users and their passwords or other credentials.
|
||||
In may cases, it is just not possible to migrate off of those existing stores to a pure {project_name} deployment.
|
||||
In many cases, it is just not possible to migrate off of those existing stores to a pure {project_name} deployment.
|
||||
{project_name} can federate existing external user databases.
|
||||
Out of the box we have support for LDAP and Active Directory. You can also code your own extension for any custom
|
||||
user databases you might have using our User Storage SPI.
|
||||
|
@ -13,7 +13,7 @@ If it can't find it there it will iterate
|
|||
over every User Storage provider you have configured for the realm until it finds a match. Data from the external store is mapped into a common user model that is consumed by the {project_name}
|
||||
runtime. This common user model can then be mapped to OIDC token claims and SAML assertion attributes.
|
||||
|
||||
External user databases rarely have every piece of data need to support all the features that {project_name} has.
|
||||
External user databases rarely have every piece of data needed to support all the features that {project_name} has.
|
||||
In this case, the User Storage Provider can opt to store some things locally in the {project_name} user store.
|
||||
Some providers even import the user locally and sync periodically with the external store. All this depends on the capabilities of the provider and how its configured. For example, your
|
||||
external user store may not support OTP. Depending on the provider, this OTP can be handled and stored by {project_name}.
|
||||
|
|
Loading…
Reference in a new issue