Fix a couple of typos in user-federation.adoc

Fix a couple of typos.
This commit is contained in:
daviderie 2018-08-06 12:00:28 -04:00 committed by Stian Thorgersen
parent 56afcd47e0
commit 9a6d839441

View file

@ -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}.