From 4b993718535cc89523c4bd61c944fab534e00c06 Mon Sep 17 00:00:00 2001 From: Christophe Maudoux Date: Sun, 28 Aug 2022 00:47:03 +0200 Subject: [PATCH] Fix doc & typos --- doc/sources/admin/idpcas.rst | 12 ++--- doc/sources/admin/idpopenidconnect.rst | 47 +++++++++---------- doc/sources/admin/idpsaml.rst | 4 +- doc/sources/admin/testopenidconnect.rst | 29 ++++++------ .../lib/Lemonldap/NG/Manager/Build.pm | 2 +- .../site/htdocs/static/forms/samlService.html | 2 +- .../static/forms/simpleInputContainer.html | 2 +- 7 files changed, 46 insertions(+), 52 deletions(-) diff --git a/doc/sources/admin/idpcas.rst b/doc/sources/admin/idpcas.rst index 8c28ac66d..e80285f5f 100644 --- a/doc/sources/admin/idpcas.rst +++ b/doc/sources/admin/idpcas.rst @@ -4,14 +4,12 @@ CAS server Presentation ------------ -LL::NG can be used as a CAS server. It can allow one to federate LL::NG -with: +LL::NG can be used as a CAS server. It can allow one to federate LL::NG with: - Another :doc:`CAS authentication` LL::NG provider - Any CAS consumer -LL::NG is compatible with the `CAS -protocol `__ +LL::NG is compatible with the `CAS protocol `__ versions 1.0, 2.0 and part of 3.0 (attributes exchange). Configuration @@ -20,8 +18,7 @@ Configuration Enabling CAS ~~~~~~~~~~~~ -In the Manager, go in ``General Parameters`` » ``Issuer modules`` » -``CAS`` and configure: +In the Manager, go in ``General Parameters`` » ``Issuer modules`` » ``CAS`` and configure: - **Activation**: set to ``On``. - **Path**: it is recommended to keep the default value (``^/cas/``) @@ -31,8 +28,7 @@ In the Manager, go in ``General Parameters`` » ``Issuer modules`` » .. tip:: - For example, to allow only users with a strong authentication - level: + For example, to allow only users with a strong authentication level: :: diff --git a/doc/sources/admin/idpopenidconnect.rst b/doc/sources/admin/idpopenidconnect.rst index 16902e11d..9cec93796 100644 --- a/doc/sources/admin/idpopenidconnect.rst +++ b/doc/sources/admin/idpopenidconnect.rst @@ -265,12 +265,12 @@ Options - **Basic** + - **Public client** (since version ``2.0.4``): Set this RP as public + client, so authentication is not needed on tokens endpoint - **Client ID**: Client ID for this RP - **Client secret**: Client secret for this RP (can be used for symmetric signature) - - **Public client** (since version ``2.0.4``): Set this RP as public - client, so authentication is not needed on tokens endpoint - - **Redirection addresses**: Space-separated list of redirect + - **Allowed redirection addresses for login**: Space-separated list of redirect addresses allowed for this RP - **Advanced** @@ -279,8 +279,6 @@ Options sharing consent screen (consent will be accepted by default). Bypassing the consent is **not** compliant with OpenID Connect standard. - - **User attribute**: Session field that will be used as main - identifier (``sub``). Default value is ``whatToTrace``. - **Force claims to be returned in ID Token**: This options will make user attributes from the requested scope appear as ID Token claims - **Use JWT format for Access Token** (since version ``2.0.12``): When @@ -290,13 +288,15 @@ Options - **Release claims in Access Token** (since version ``2.0.12``): If Access Tokens are in JWT format, this option lets you release the claims defined in the *Extra Claims* section inside the Access Token itself - - **Additional audiences** (since version ``2.0.8``): You can - specify a space-separated list of audiences that will be added to the - ID Token audiences - **Use refresh tokens** (since version ``2.0.7``): If this option is enabled, LL::NG will issue a Refresh Token that can be used to obtain new access tokens as long as the user session is still valid + - **User attribute**: Session field that will be used as main + identifier (``sub``). Default value is ``whatToTrace``. + - **Additional audiences** (since version ``2.0.8``): You can + specify a space-separated list of audiences that will be added to the + ID Token audiences - **Security** @@ -321,40 +321,39 @@ Options This feature only works if you have configured a form-based authentication module. - **Allow OAuth2.0 Client Credentials Grant** (since version ``2.0.11``): Allow the use of the :ref:`Client Credentials Grant ` by this client. - - **Authentication Level**: Required authentication level to access this application - - **Access Rule**: Lets you specify a :doc:`Perl rule` to restrict access to this client + - **Authentication level**: Required authentication level to access this application + - **Access rule**: Lets you specify a :doc:`Perl rule` to restrict access to this client - **Timeouts** - - **Authorization Code expiration**: Expiration time of - authorization code, when using the Authorization Code flow. The - default value is one minute. - - **ID Token expiration**: Expiration time of ID Tokens. The default + - **Authorization Codes**: Expiration time of + Authorization Codes, when using the Authorization Code flow. + Default value is one minute. + - **ID Tokens**: Expiration time of ID Tokens. Default value is one hour. - - **Access token expiration**: Expiration time - of Access Tokens. The default value is one hour. - - **Offline session expiration**: This sets the lifetime of the - refresh token obtained with the **offline_access** scope. The - default value is one month. This parameter only applies if offline + - **Access Tokens**: Expiration time + of Access Tokens. Default value is one hour. + - **Offline sessions**: Lifetime of the + refresh token obtained with the **offline_access** scope. + Default value is one month. This parameter only applies if offline sessions are enabled. - **Logout** - **Bypass confirm**: Bypass logout confirmation when logout is initiated by relaying party + - **Session required**: Whether to send the Session ID in the logout request + - **Type**: Type of logout to perform (only Front-Channel is implemented for now) + - **URL**: Specify the relying party's logout URL - **Allowed redirection addresses for logout**: A space-separated list of URLs that this client can redirect the user to once the logout is done (through ``post_logout_redirect_uri``) - - **URL**: Specify the relying party's logout URL - - **Type**: Type of logout to perform (only Front-Channel is implemented for now) - - **Session required**: Whether to send the Session ID in the logout request - Macros ^^^^^^ You can define here macros that will be only evaluated for this service, -and not registered in the session of the user. +and not registered in the user's session. Display ^^^^^^^ diff --git a/doc/sources/admin/idpsaml.rst b/doc/sources/admin/idpsaml.rst index 91f44100d..1ac823d0e 100644 --- a/doc/sources/admin/idpsaml.rst +++ b/doc/sources/admin/idpsaml.rst @@ -171,8 +171,8 @@ Security NameID or Assertion). - **Enable use of IDP initiated URL**: set to ``On`` to enable IDP Initiated URL on this SP. -- **Authentication Level**: required authentication level to access this SP -- **Access Rule**: lets you specify a :doc:`Perl rule` to restrict access to this SP +- **Authentication level**: required authentication level to access this SP +- **Access rule**: lets you specify a :doc:`Perl rule` to restrict access to this SP Extra variables ^^^^^^^^^^^^^^^ diff --git a/doc/sources/admin/testopenidconnect.rst b/doc/sources/admin/testopenidconnect.rst index 588306b75..46330a843 100644 --- a/doc/sources/admin/testopenidconnect.rst +++ b/doc/sources/admin/testopenidconnect.rst @@ -2,15 +2,14 @@ Test OpenID Connect with command line tools =========================================== We present here how to test the OpenID Connect protocol (authorization code flow) with commande line tools, like `curl`. - We use in this example a public OIDC provider based on LL::NG: ``_ Authentication -------------- -The first step is to obtain a valid SSO session on the portal. The standard solution is to use a web browser and log into the portal, then get the value of the SSO cookie. +The first step is to obtain a valid SSO session on the portal. The standard solution is to use a web browser and log into the portal, then get the value of the SSO cookie. -In our case, to be able to use only command lines, we will use portal REST API (which requires to adapt the `requireToken` configuration to get cookie value in JSON response (see :doc:`REST services`). This should not be what you will on a production service. +In our case, to be able to use only command lines, we will use portal REST API (which requires to adapt the `requireToken` configuration to get cookie value in JSON response (see :doc:`REST services`). This should not be what you want on a production service. Example of REST service usage, with credentials `dwho`/`dwho`: @@ -31,12 +30,12 @@ The session id is displayed in JSON response: Authorization code ------------------ -In the first step of authorization code flow, we request a temporary code, ont the `authorize` end point. +In the first step of authorization code flow, we request a temporary code, on the `authorize` end point. -Parameters needed: +Required parameters: * SSO session id (will be passed in `lemonldap` cookie, adapt the name if needed) * Client ID: given by your OIDC provider, we use here `private` - * Scope: depends on which information you need, we will use here `openid profile email` + * Scope: depends on which information you want, we will use here `openid profile email` * Redirect URI: shoud match the value registered in your OIDC provider, we will use here `http://localhost` The OIDC provide will return the code in the location header, so we just output this reponse header: @@ -52,7 +51,7 @@ The value of the location header is: location: http://localhost?code=294b0facd91a0fa92762edc48d18369e99c330ba2b8fb05ab2c45999fcef6e17&session_state=BpB8KRMBEDUs%2B7lAjsz4DRk3E0RJImxgUbMsCFFAUa8%3D.N3dVOFg3a2RpNXVJK3ltSldrYXZjUjhtU0tvd29sWkpuWWJJbll5ZGs5NzhZMnh5bmQwd0IxRmJVWUxJSTlkWDBnSWZ2SWFVZmU0UnRaMkVJVjNUY3c9PQ -So we get the code value: `94b0facd91a0fa92762edc48d18369e99c330ba2b8fb05ab2c45999fcef6e17` +So we get the code value: `294b0facd91a0fa92762edc48d18369e99c330ba2b8fb05ab2c45999fcef6e17` This code has a short lifetime, we will use it to get access token and ID token in the next step @@ -64,7 +63,7 @@ In this step, we exchange the authorization code against tokens: * ID token * Refresh token (optional) -Parameters needed: +Required parameters: * Authorization code: see previous step * Grant type: we use here `authorization_code` * Redirect URI: same value as the one used in the previous step @@ -72,7 +71,7 @@ Parameters needed: .. code-block:: shell - curl -X POST -d grant_type=authorization_code -d 'redirect_uri=http://localhost' -d code=94b0facd91a0fa92762edc48d18369e99c330ba2b8fb05ab2c45999fcef6e17 -u 'private:tardis' 'https://oidctest.wsweet.org/oauth2/token' | json_pp + curl -X POST -d grant_type=authorization_code -d 'redirect_uri=http://localhost' -d code=294b0facd91a0fa92762edc48d18369e99c330ba2b8fb05ab2c45999fcef6e17 -u 'private:tardis' 'https://oidctest.wsweet.org/oauth2/token' | json_pp The JSON response looks like this: @@ -86,7 +85,7 @@ The JSON response looks like this: "token_type" : "Bearer" } -The access token will be used for the last step, to get information about the user. +The access token will be used for the last step, to retrieve information about the user. The ID Token is a JWT (JSON Web Token) and can be parsed easily, as this is the concatenation of 3 JSON strings encoded in base 64: `base64(header).base64(payload).base64(signature)`. @@ -113,7 +112,7 @@ User info This step is optional and allows to fetch user information linked to scopes requested in the first step. -Parameters needed: +Required parameters: * Access token, used as bearer authorization .. code-block:: shell @@ -134,9 +133,9 @@ JSON response: Introspection ------------- -You can the validity of the access token with the introspection endpoint. +You can test access token validity with the introspection endpoint. -Parameters needed: +Required parameters: * Client ID and Client Secret, used as basic authorization * Access token, sent as POST data @@ -162,7 +161,7 @@ Refresh an access token If the access token has expired, you can get a new one with the refresh token. -Parameters needed: +Required parameters: * Grant type: we use here `refresh_token`, sent as POST data * Refresh token, sent as POST data * Client ID and Client Secret, used as basic authorization @@ -187,7 +186,7 @@ Logout To kill SSO session, call the OIDC logout endpoint. By default a confirmation is requested, but you can bypass it by adding `confirm=1` to URL. -Parameters needed: +Required parameters: * SSO session id (will be passed in `lemonldap` cookie) .. code-block:: shell diff --git a/lemonldap-ng-manager/lib/Lemonldap/NG/Manager/Build.pm b/lemonldap-ng-manager/lib/Lemonldap/NG/Manager/Build.pm index 78b9dff74..67994775c 100644 --- a/lemonldap-ng-manager/lib/Lemonldap/NG/Manager/Build.pm +++ b/lemonldap-ng-manager/lib/Lemonldap/NG/Manager/Build.pm @@ -706,7 +706,7 @@ sub scanTree { } # issue 2439 - # FIXME: in future versions, oidcOPMetaDataJSON and samlIDPMetaDataXML shoud + # FIXME: in future versions, oidcOPMetaDataJSON and samlIDPMetaDataXML should # behave the same if ( $leaf =~ /^oidcOPMetaData(?:JSON|JWKS)$/ ) { push @simpleHashKeys, $leaf; diff --git a/lemonldap-ng-manager/site/htdocs/static/forms/samlService.html b/lemonldap-ng-manager/site/htdocs/static/forms/samlService.html index 801593286..9754fce17 100644 --- a/lemonldap-ng-manager/site/htdocs/static/forms/samlService.html +++ b/lemonldap-ng-manager/site/htdocs/static/forms/samlService.html @@ -2,7 +2,7 @@

{{translateTitle(currentNode)}}

- +
diff --git a/lemonldap-ng-manager/site/htdocs/static/forms/simpleInputContainer.html b/lemonldap-ng-manager/site/htdocs/static/forms/simpleInputContainer.html index 61abc9997..10bab1dff 100644 --- a/lemonldap-ng-manager/site/htdocs/static/forms/simpleInputContainer.html +++ b/lemonldap-ng-manager/site/htdocs/static/forms/simpleInputContainer.html @@ -81,7 +81,7 @@
- ERROR, complex node inside. Don't use simpleInputContainer for {{currentNode.title}} + ERROR, complex node inside. Do not use simpleInputContainer for {{currentNode.title}}