Doc & Typos
This commit is contained in:
Christophe Maudoux
parent
e5415338cb
commit
20c4773065
|
|
@ -20,15 +20,15 @@ LL::NG can act as an OpenID Connect Relying Party (RP) towards multiple
|
|||
OpenID Connect Providers (OP). It will get the user identity through an
|
||||
ID Token, and grab user attributes through UserInfo endpoint.
|
||||
|
||||
As an RP, LL::NG supports a lot of OpenID Connect features:
|
||||
As an RP, LL::NG supports many OpenID Connect features:
|
||||
|
||||
- Authorization Code flow
|
||||
- Authorization Code, Implicit and Hybrid flows
|
||||
- Automatic download of JWKS
|
||||
- JWT signature verification
|
||||
- Access Token Hash verification
|
||||
- ID Token validation
|
||||
- Get UserInfo as JSON or as JWT
|
||||
- Logout on EndSession end point
|
||||
- Logout on EndSession endpoint
|
||||
|
||||
You can use this authentication module to link your LL::NG server to any
|
||||
OpenID Connect Provider. Here are some examples, with their specific
|
||||
|
|
@ -60,11 +60,11 @@ Google France Connect Pro Santé Connect
|
|||
|
||||
.. attention::
|
||||
|
||||
OpenID Connect specification is not finished for logout
|
||||
propagation. So logout initiated by relaying-party will be forward to
|
||||
OpenID Connect specification is not achieved for logout propagation.
|
||||
So logout initiated by relaying-party will be forwarded to
|
||||
OpenID Connect provider but logout initiated by the provider (or another
|
||||
RP) will not be propagated. LLNG will implement this when spec will be
|
||||
published.
|
||||
RP) will not be propagated. LL::NG will implement this when specification
|
||||
is published.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
|
@ -93,11 +93,11 @@ In ``General Parameters`` > ``Authentication modules``, set:
|
|||
.. attention::
|
||||
|
||||
Browser implementations of formAction directive are
|
||||
inconsistent (e.g. Firefox doesn't block the redirects whereas Chrome
|
||||
inconsistent (e.g. Firefox does not block the redirects whereas Chrome
|
||||
does). Administrators may have to modify formAction value with wildcard
|
||||
likes \*.
|
||||
|
||||
In Manager, go in :
|
||||
In Manager, go in:
|
||||
|
||||
``General Parameters`` > ``Advanced Parameters`` > ``Security`` >
|
||||
``Content Security Policy`` > ``Form destination``
|
||||
|
|
@ -118,7 +118,7 @@ Register LL::NG to an OpenID Connect Provider
|
|||
To register LL::NG, you will need to give some information like
|
||||
application name or logo.
|
||||
|
||||
You will be asked to provide a *Redirect URI* for LL::NG, which is constructed
|
||||
You will be prompted to provide a *Redirect URI* for LL::NG, which is built
|
||||
by appending the ``openidconnectcallback=1`` parameter to the Portal URL.
|
||||
|
||||
For example:
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ IssuerDB
|
|||
Go in ``General Parameters`` » ``Issuer modules`` » ``OpenID Connect``
|
||||
and configure:
|
||||
|
||||
- **Activation**: set to ``On``
|
||||
- **Activation**: Set to ``On``
|
||||
- **Path**: Keep ``^/oauth2/`` unless you need to use another path
|
||||
- **Use rule**: Rule to allow user to use this module, set to ``1``
|
||||
to always allow
|
||||
|
|
@ -150,10 +150,10 @@ Configuration of Relying Party in LL::NG
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Go in Manager and click on ``OpenID Connect Relying Parties``, then
|
||||
click on ``Add OpenID Relying Party``. Give a technical label (no
|
||||
spaces, no special characters), like “sample-rp”;
|
||||
click on ``Add OpenID Relying Party``. Set a technical name
|
||||
(without space or special character), like “sample-rp”;
|
||||
|
||||
You can then access to the configuration of this RP.
|
||||
You can then set this RP configuration.
|
||||
|
||||
.. _oidcexportedattr:
|
||||
|
||||
|
|
@ -165,7 +165,7 @@ Exported attributes
|
|||
By default, only `standard OpenID Connect claims <http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims>`__
|
||||
are exposed to applications. If you want to add non-standard attributes, you have to create a new scope in the *Scope values content* section and your application must request it.
|
||||
|
||||
For each OpenID Connect attribute you want to release to applications, you can define:
|
||||
For each OpenID Connect attribute you want to expose to applications, you can define:
|
||||
|
||||
* **Claim name**: Name of the attribute as it will appear in Userinfo responses
|
||||
* **Variable name**: Name of the LemonLDAP::NG session variable containing the attribute value
|
||||
|
|
@ -225,7 +225,7 @@ be able to read the ``company`` and ``position`` attributes from the UserInfo en
|
|||
|
||||
.. _oidcscoperules:
|
||||
|
||||
Scope Rules
|
||||
Scope rules
|
||||
^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 2.0.12
|
||||
|
|
@ -347,6 +347,22 @@ Options
|
|||
- **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.
|
||||
|
||||
Display
|
||||
^^^^^^^
|
||||
|
||||
- **Display name**: Name of the RP application
|
||||
- **Logo**: Logo of the RP application
|
||||
|
||||
.. |beta| image:: /documentation/beta.png
|
||||
|
||||
|
||||
Access Rule extra variables
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
@ -398,17 +414,3 @@ mapped to **Exported Attributes** and **Extra Claims**.
|
|||
.. seealso::
|
||||
|
||||
Specification for the Client Credentials Grant: :rfc:`6749#section-4.4`
|
||||
|
||||
Macros
|
||||
^^^^^^
|
||||
|
||||
You can define here macros that will be only evaluated for this service,
|
||||
and not registered in the session of the user.
|
||||
|
||||
Display
|
||||
^^^^^^^
|
||||
|
||||
- **Display name**: Name of the RP application
|
||||
- **Logo**: Logo of the RP application
|
||||
|
||||
.. |beta| image:: /documentation/beta.png
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
Writing rules and headers
|
||||
=========================
|
||||
|
||||
Lemonldap::NG manages applications by their hostname (Apache's
|
||||
virtualHosts). Rules are used to protect applications, headers are HTTP
|
||||
headers added to the request to give datas to the application (for logs,
|
||||
profiles,...).
|
||||
LL::NG manages applications by their hostname (Apache's
|
||||
Virtual Hosts or Nginx Block Servers). Rules are used for protecting applications,
|
||||
and HTTP headers are appended to each request for sending datas to protected
|
||||
applications (for logs, profiles,...).
|
||||
|
||||
|
||||
.. attention::
|
||||
|
|
@ -12,12 +12,12 @@ profiles,...).
|
|||
Note that variables designed by $xx correspond to the
|
||||
name of the :doc:`exported variables<exportedvars>` or
|
||||
:ref:`macro names<macros_and_groups>` except for ``$ENV{<cgi-header>}`` which
|
||||
correspond to CGI header (``$ENV{REMOTE_ADDR}`` for example).
|
||||
correspond to CGI headers (``$ENV{REMOTE_ADDR}`` for example).
|
||||
|
||||
Available $ENV variables
|
||||
------------------------
|
||||
|
||||
The %ENV table provides:
|
||||
The %ENV hash provides:
|
||||
|
||||
- all headers in CGI format (``User-Agent`` becomes
|
||||
``HTTP_USER_AGENT``)
|
||||
|
|
@ -30,7 +30,7 @@ The %ENV table provides:
|
|||
- For Nginx handler: all variables given by ``fastcgi_param``
|
||||
commands.
|
||||
|
||||
- For portal:
|
||||
- For Portal:
|
||||
|
||||
- $ENV{urldc} : Origin URL before Handler redirection, in cleartext
|
||||
- $ENV{_url} : Origin URL before Handler redirection, base64 encoded
|
||||
|
|
@ -62,29 +62,28 @@ Makes authentication optional, but authenticated users are seen as such (that is
|
|||
Restrict access to the whole site to users that have the LDAP description field set to "LDAP administrator" (must be set in exported variables) default
|
||||
=============================================================================================================================================== ================== ======================================
|
||||
|
||||
The "**default**" access rule is used if no other access rule match the
|
||||
The "**default**" access rule is used if none rule matches the
|
||||
current URL.
|
||||
|
||||
|
||||
.. tip::
|
||||
|
||||
See :doc:`the rules examples page<rules_examples>` for a few
|
||||
See :doc:`the rule examples page<rules_examples>` for few
|
||||
common use cases
|
||||
|
||||
|
||||
.. tip::
|
||||
|
||||
|
||||
|
||||
- Comments can be used to order your rules: rules are applied in the
|
||||
alphabetical order of comment (or regexp in there is no comment). See
|
||||
- Comments can be employed for ordering your rules: rules are applied depending on
|
||||
comment alphabetical order (or regexp if no comment is defined). See
|
||||
:ref:`security chapter<security-write-good-rules>` to learn more
|
||||
about writing good rules.
|
||||
- See :ref:`performances<performances-handler-performance>` to know how
|
||||
to use macros and groups in rules.
|
||||
about rules best practice.
|
||||
- See :ref:`performances<performances-handler-performance>` to learn how
|
||||
using macros and groups in rules.
|
||||
|
||||
|
||||
Rules can also be used to intercept logout URL:
|
||||
Rules can also be used for intercepting logout URL:
|
||||
|
||||
================================================================================================================= =================== =====================================
|
||||
Goal Regular expression Rule
|
||||
|
|
@ -98,24 +97,24 @@ Logout user from current application and from Lemonldap::NG and redirect it to h
|
|||
.. danger::
|
||||
|
||||
\ ``logout_app`` and ``logout_app_sso`` rules are not
|
||||
available on Nginx, only on Apache.
|
||||
available with Nginx, Apache ONLY.
|
||||
|
||||
By default, user will be redirected on portal if no URL defined, or on
|
||||
the specified URL if any.
|
||||
By default, users will be redirected to the Portal if no URL is defined,
|
||||
or to the specified URL if exists.
|
||||
|
||||
|
||||
.. attention::
|
||||
|
||||
Only current application is concerned by logout_app\*
|
||||
targets. Be careful with some applications which doesn't verify
|
||||
Lemonldap::NG headers after having created their own cookies. If so, you
|
||||
can redirect users to a HTML page that explain that it is safe to close
|
||||
browser after disconnect.
|
||||
targets. Be careful with some applications which does not check
|
||||
headers sent by LL::NG after having created their own application cookies.
|
||||
If so, you can redirect users to a HTML page that explain that it is better
|
||||
to close browser after logout.
|
||||
|
||||
Rules based on authentication level
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
LLNG set an "authentication level" during authentication process. This
|
||||
LL::NG set an "authentication level" during authentication process. This
|
||||
level depends on authentication backend used by this user. Default
|
||||
values are:
|
||||
|
||||
|
|
@ -142,8 +141,8 @@ There are three ways to impose users a higher authentication level:
|
|||
|
||||
.. tip::
|
||||
|
||||
Instead of returning a 403 code, "minimum level" returns user
|
||||
to a form that explain that a higher level is required and propose to
|
||||
Instead of returning a 403 code, "minimum level" returns users
|
||||
to a form that explains that a higher level is required and propose to
|
||||
reauthenticate himself.
|
||||
|
||||
.. _headers:
|
||||
|
|
@ -152,8 +151,8 @@ Headers
|
|||
-------
|
||||
|
||||
Headers are associations between an header name and a perl expression
|
||||
that returns a string. Headers are used to give user data to the
|
||||
application.
|
||||
that returns a value. Headers are used for sending user data to protected
|
||||
applications.
|
||||
|
||||
Examples:
|
||||
|
||||
|
|
@ -175,7 +174,7 @@ use macros, local macros,...
|
|||
|
||||
- Since many HTTP servers refuse non ascii headers, it is recommended
|
||||
to use encode_base64() function to transmit those headers
|
||||
- Don't forget to add an empty string as second argument to
|
||||
- Do not forget to add an empty string as second argument to
|
||||
encode_base64 function to avoid a "newline" characters insertion in
|
||||
result
|
||||
- Header names must contain only letters and "-" character.
|
||||
|
|
@ -189,7 +188,7 @@ use macros, local macros,...
|
|||
|
||||
By default, SSO cookie is hidden. So protected applications
|
||||
cannot retrieve SSO session key. But you can forward this key if
|
||||
absolutely needed:
|
||||
absolutely needed (NOT recommanded because can be a security issue):
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -203,7 +202,7 @@ Available functions
|
|||
In addition to macros and name, you can use some functions in rules and
|
||||
headers:
|
||||
|
||||
- :doc:`LLNG extended functions<extendedfunctions>`
|
||||
- :doc:`LL::NG extended functions<extendedfunctions>`
|
||||
- :doc:`Your custom functions<customfunctions>`
|
||||
|
||||
Wildcards in hostnames
|
||||
|
|
@ -215,8 +214,8 @@ aliases !): ``*.example.com`` matches all hostnames that belong to
|
|||
wildcards such as ``test-*.example.com`` or ``test-%.example.com``. The
|
||||
``%`` wilcard doesn't match subdomains.
|
||||
|
||||
Even if a wildcard exists, if a virtualhost is explicitly declared, this
|
||||
rule is applied. Example with precedence order for test.sub.example.com:
|
||||
Even if a wildcard exists, if a VirtualHost is explicitly declared, this
|
||||
rule will be applied. Example with precedence order for test.sub.example.com:
|
||||
|
||||
#. test.sub.example.com
|
||||
#. test%.sub.example.com
|
||||
|
|
|
|||
Loading…
Reference in New Issue