Skip to content

Commit

Permalink
Apply suggestions from code review
Browse files Browse the repository at this point in the history
Co-authored-by: Philip Durbin <[email protected]>
  • Loading branch information
qqmyers and pdurbin authored Jan 24, 2025
1 parent 4551779 commit 063fa5e
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions doc/sphinx-guides/source/api/auth.rst
Original file line number Diff line number Diff line change
Expand Up @@ -94,13 +94,13 @@ By default, the Bearer token is expected to include the following claims that wi
- ``lastName``
- ``emailAddress``

The one parameter required by default is ``termsAccepted``` which must be set to true, indicating that the user has seen and accepted the Terms of Use of the Installation.
The one parameter required by default is ``termsAccepted`` which must be set to true, indicating that the user has seen and accepted the Terms of Use of the installation.

If the feature flag ``api-bearer-auth-handle-tos-acceptance-in-idp``` is enabled (along with the ``api-bearer-auth`` feature flag), Dataverse assumes that the Terms of Service acceptance was handled by the identity provider, e.g. in the OIDC ``consent``` dialog, and the `termsAccepted``` parameter is not needed.
If the feature flag ``api-bearer-auth-handle-tos-acceptance-in-idp`` is enabled (along with the ``api-bearer-auth`` feature flag), Dataverse assumes that the Terms of Service acceptance was handled by the identity provider, e.g. in the OIDC ``consent`` dialog, and the ``termsAccepted`` parameter is not needed.

There is another flag called ``api-bearer-auth-provide-missing-claims`` that can be enabled (along with the ``api-bearer-auth`` feature flag) to allow sending missing user claims in the registration JSON. This is useful when the identity provider does not supply the necessary claims listed above. If properties are provided in the JSON, but corresponding claims already exist in the identity provider, an error will be thrown, outlining the conflicting properties. Note that supplying missing claims is configured via a separate feature flag because using it may introduce user impersonation issues, for example if the identity provider does not provide an email field and the user submits an email address they do not own.

In all cases, the submitted JSON can optionally include the fields ``position`` or ``affiliation``, which will be added to the users's Dataverse account profile. These fields are optional, and if not provided, they will be persisted as empty in Dataverse.
In all cases, the submitted JSON can optionally include the fields ``position`` or ``affiliation``, which will be added to the user's Dataverse account. These fields are optional, and if not provided, they will be persisted as empty in Dataverse.

Signed URLs
-----------
Expand Down

0 comments on commit 063fa5e

Please sign in to comment.