Improve OIDC doc
This commit is contained in:
parent
4413850257
commit
44b6cde64a
|
@ -132,13 +132,13 @@ For example:
|
|||
you need to set SameSite cookie value to "Lax" or "None".
|
||||
See :doc:`SSO cookie parameters<ssocookie>`
|
||||
|
||||
After registration, the OP must give you a client ID and a client
|
||||
secret, that will be used to configure the OP in LL::NG.
|
||||
After registration, the OP must give you a *Client ID* and a *Client
|
||||
secret* required to configure the OP in LL::NG.
|
||||
|
||||
Declare the OpenID Connect Provider in LL::NG
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In the Manager, select node ``OpenID Connect Providers`` and click on
|
||||
In Manager, select node ``OpenID Connect Providers`` and click on
|
||||
``Add OpenID Connect Provider``. Set a technical name (without space or
|
||||
special character) like "sample-op".
|
||||
|
||||
|
@ -183,24 +183,24 @@ JWKS data
|
|||
^^^^^^^^^
|
||||
|
||||
JWKS is a JSON file containing public keys. LL::NG can grab them
|
||||
automatically if jwks_uri is defined in metadata. Else you can paste the
|
||||
content of the JSON file in the textarea.
|
||||
automatically if jwks_uri is defined in metadata. Else you can paste
|
||||
the JSON file content in the textarea.
|
||||
|
||||
|
||||
.. tip::
|
||||
|
||||
If the OpenID Connect provider only uses symmetric encryption,
|
||||
JWKS data is not useful.
|
||||
JWKS data are useless.
|
||||
|
||||
Exported attributes
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Define here mapping between LL::NG session content and fields
|
||||
provided in UserInfo endpoint response. The fields are defined in
|
||||
provided in UserInfo endpoint response. These fields are defined in
|
||||
`OpenID Connect standard <http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims>`__,
|
||||
and depends on the scope requested by LL::NG (see options in next chapter).
|
||||
and depends on the scope requested by LL::NG (see options below).
|
||||
|
||||
So you can define for example:
|
||||
So you can define by example:
|
||||
|
||||
- cn => name
|
||||
- sn => family_name
|
||||
|
|
|
@ -10,7 +10,7 @@ Presentation
|
|||
OpenID Connect is a protocol based on REST, OAuth 2.0 and JOSE
|
||||
stacks. It is described here: http://openid.net/connect/.
|
||||
|
||||
LL::NG can act as an OpenID Connect Provider (OP). It will answer to
|
||||
LL::NG can act as an OpenID Connect Provider (OP). It will reply to
|
||||
OpenID Connect requests to give user identity (through ID Token) and
|
||||
information (through UserInfo endpoint).
|
||||
|
||||
|
@ -179,7 +179,7 @@ For each OpenID Connect attribute you want to release to applications, you can d
|
|||
|
||||
.. attention::
|
||||
|
||||
The specific ``sub`` attribute is not defined here, but in User attribute parameter (see below).
|
||||
The specific ``sub`` attribute is not defined here, but in ``User attribute`` parameter (see below).
|
||||
|
||||
|
||||
.. _oidcextraclaims:
|
||||
|
@ -365,7 +365,7 @@ The Resource Owner Password Credentials Grant allows you to exchange a user's lo
|
|||
|
||||
.. versionchanged:: 2.0.12
|
||||
|
||||
when using the :doc:`Choice <authchoice>` authentication module, the *Choice used for password authentication* setting can be used to select which authentication choice is used by the Resource Owner Password Credentials Grant. Naturally, the selected choice must be a password-based authentication method (LDAP, DBI, REST, etc.)
|
||||
When using the :doc:`Choice <authchoice>` authentication module, the *Choice used for password authentication* setting can be used for selecting which authentication choice is used by the Resource Owner Password Credentials Grant. Naturally, the selected choice must be a password-based authentication method (LDAP, DBI, REST, etc.).
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
@ -388,12 +388,12 @@ The following attributes are made available in the created session:
|
|||
* The ``_clientConfKey`` attribute is set to the LemonLDAP::NG configuration
|
||||
key for the client that obtained the access token.
|
||||
|
||||
The Access Rule, if defined, will have access to those variables, as well as
|
||||
The **Access Rule**, if defined, will have access to those variables, as well as
|
||||
the `@ENV` array. You can use it to restrict the use of this grant to
|
||||
pre-determined scopes, a particular IP address, etc.
|
||||
|
||||
These session attribute will be released on the UserInfo endpoint if they are
|
||||
mapped to Exported Attributes and Extra Claims
|
||||
These session attributes will be released on the UserInfo endpoint if they are
|
||||
mapped to **Exported Attributes** and **Extra Claims**.
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
|
|
@ -30,7 +30,7 @@ values unless you have a specific need to change them.
|
|||
|
||||
.. tip::
|
||||
|
||||
The end points are published inside JSON metadata.
|
||||
These endpoints are published inside JSON metadata.
|
||||
|
||||
Authentication context
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
@ -74,19 +74,21 @@ sessions, else they will be stored in main sessions storage.
|
|||
Dynamic Registration
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
- **Activation**: Set to 1 to allow clients to register
|
||||
themselves. This may be a security risk as this will create a new
|
||||
configuration in the backend per registration request. You can restrict
|
||||
this by protecting the WebServer registration endpoint with
|
||||
an authentication module, and give the credentials to clients.
|
||||
- **Activation**: Set to 1 to allow clients to register themselves
|
||||
|
||||
If dynamic registration is enabled, you can configure the following
|
||||
If **Dynamic Registration** is enabled, you can configure the following
|
||||
options to define attributes and extra claims released when a new relying
|
||||
party is registered through ``/oauth2/register`` endpoint:
|
||||
|
||||
- **Exported vars**
|
||||
- **Extra claims**
|
||||
|
||||
.. warning::
|
||||
Dynamic Registration can be a security risk because a new configuration
|
||||
will be created in the backend for each registration request.
|
||||
You can restrict this by protecting the WebServer registration endpoint
|
||||
with an authentication module, and give credentials to clients.
|
||||
|
||||
Keys rotation script
|
||||
--------------------
|
||||
|
||||
|
|
Loading…
Reference in New Issue