.. Reminder for header structure:
  Parts (H1)          : #################### with overline
  Chapters (H2)       : ******************** with overline
  Sections (H3)       : ====================
  Subsections (H4)    : --------------------
  Subsubsections (H5) : ^^^^^^^^^^^^^^^^^^^^
  Paragraphs (H6)     : """""""""""""""""""""

.. meta::
 :description: Configuring ACL
 :keywords: ACL, WAPT, documentation, Access Control Lists

.. role:: cyan
   :class: cyan-text

.. |date| date::

########################################################
Enhancing the security of your WAPT setup - Console side
########################################################


.. _generating_CA:

**************************************************************
Generating the Certificate Authority (CA) |enterprise_feature|
**************************************************************

.. youtube:: mdUcQSdPqQ4
   :align: center
   :width: 50%

When installing WAPT, you are asked to :ref:`create <create_certificate>` a :mimetype:`.pem` / :mimetype:`.crt` pair by checking the boxes :guilabel:`Tag as code signing` and :guilabel:`Tag as CA Certificate`.

This :mimetype:`.pem` / :mimetype:`.crt` pair will allow to sign WAPT packages and new certificates.

Generating a new certificate with the Certificate Authority
===========================================================

:ref:`Build a new <building_certificate>` :file:`.pem` / :file:`.crt` pair.

.. note::

  The new certificate will not be a self-signed certificate;

  This new certificate will be signed by the CA (the key generated at the time of the first installation of WAPT);

You **MUST** then fill in the :guilabel:`Authority Signing Key` and the :guilabel:`Authority Signing Certificate`.

When generating the new pem/ crt pair, you have the option to choose whether or not the new certificate will be a **Code Signing** type.

.. hint::

  For recall, a *Code Signing* certificate is reserved to individuals with the :term:`Administrator` role in the context of WAPT and a simple SSL certificate without the ``Code Signing`` attribute is reserved to individuals with the role of :term:`Package Deployer`.

  :term:`Administrators` will be authorized to sign packages that **CONTAIN** a :file:`setup.py` executable file (i.e. *base* packages).

  Individuals with the :term:`Package Deployer` role will be authorized to sign packages that **DO NOT CONTAIN** :file:`setup.py` executable file (i.e. *host*, *unit* and *group* packages).

.. figure:: wapt-resources/wapt_console_generate-certicate-non-code-signing_dialog-box.png
  :align: center
  :scale: 75%
  :alt: Generating a certificate without the *Code Signing* attribute

  Generating a certificate without the *Code Signing* attribute

Keys and certificates that are **Not Code Signing** may be distributed to individuals in charge of deploying packages on the installed base of WAPT equipped devices.

Another team with certificates having the **Code Signing** attribute will prepare the WAPT packages that contain applications that will need to be configured according to the security guidelines of the :term:`Organization` and the user customizations desired by her.

.. figure:: wapt-resources/wapt_console_generate-certificate-code-signing_dialog-box.png
  :align: center
  :scale: 75%
  :alt: Generating a certificate with the *Code Signing* attribute

  Generating a certificate with the *Code Signing* attribute

Generating a new .pem / .crt pair will also allow to formally identify the individual who has signed a package by looking up the :abbr:`CN (Common Name)` attribute of the WAPT package certificate.

.. hint::

  The new certificates will not be *CA Certificates*, which means that they will not be authorized to sign other certificates.

  As a general rule, there is only one **CA Certificate** pem / crt pair per :term:`Organization`.

.. attention::

  It is not necessary to deploy child certificates with the WAPT Agent.

  Child certificates are used with the WAPT Console to allow or restrict actions.

Deploying certificates of local IT admins on clients
====================================================

.. hint::

  Some Organizations will choose to let local IT administrators perform actions on WAPT equipped devices by issuing them personal certificates that will work on the set of devices for which the local IT admins are responsible.

  The headquarter IT admins will deploy the certificates of local IT admins on the computers that local admins manage on their respective sites.

  This way, local IT admins will not be able to manage computers located in headquarters, but on their own sites only.

  It is possible to manage simply and in a finer way using :ref:`Access Control Lists <ACL>` with the Enterprise version of WAPT.

You will need to copy the certificates of allowed local IT admins on WAPT clients in :file:`C:\\program files(x86)\\wapt\\ssl`.

.. hint::

  Do not forget to restart the WAPT service on clients for them to use their new certificate.
  Open a command line :program:`cmd.exe`.

  .. code-block:: bash

    net stop waptservice && net start waptservice

If you want to deploy the certificates using WAPT, use :ref:`WAPT package templates <create_package_from_console>`



*****************************************************************************************
Displaying the Certificates trusted by the hosts in the WAPT Console |enterprise_feature|
*****************************************************************************************

In this tab, you can see the certificates that the host accepts to trust.

  .. figure:: wapt-resources/wapt_console_certificate-tab.png
    :align: center
    :alt: Window showing the certificates trusted by the selected host

    Window showing the certificates trusted by the selected host


.. _ACL:

*****************************************************
Configuring Access Control Lists |enterprise_feature|
*****************************************************

.. hint::

  The *SuperAdmin* user of WAPT is authenticated by a password stored in :file:`waptserver.ini` as a value of the :code:`wapt_password` attribute.
  Others WAPT users may be local users :code:`htpasswd_path`) or AD account users (:code:`ldap_auth_server` / :code:`ldap_auth_base_dn`).

ACLs define actions enabled for all types of users in the WAPT context.

.. note::

  Default ACLs user level are defined by :code:`default_ldap_users_acls` in :file:`waptserver.ini`.

  The default ACL for a new user is ``view``.

.. attention::

  **Security is define by the certificate deployed on clients, not by ACLs.**

  **ACLs simply limit what actions the WAPT Server is allowed to relay from the WAPT Console to the WAPT Agents.**

  **As of** |date| **, the WAPT Agents do not check ACL rights.**


To configure ACLs in WAPT, go to :guilabel:`Server` → :guilabel:`Manage WAPT users and rights`.

.. image:: wapt-resources/wapt_console_server_menu-list-manage-wapt-users-and-rights.png
  :align: center
  :scale: 75%
  :alt: Menu list for managing ACLs in the WAPT Console

.. note::

  On first launch after the WAPT Server installation, only the *SuperAdmin* account is present in the list of users.

  If the *SuperAdmin* account does not exist or does not have the *admin* right, then the account is recreated by restarting the WAPT Server service.

  The *SuperAdmin* account is authenticated using the value of :code:`wapt_password` in the :file:`waptserver.ini` configuration file.

.. _creating_users:

Creating the user account
=========================

Two types of account are manageable by ACL, *local* and *Active Directory*.

* In :guilabel:`WAPT Users rights` window, click on :guilabel:`New account`.

.. figure:: wapt-resources/wapt_console_acl-new-account_screen-item.png
  :align: center
  :alt: Creating a new local account

It is possible to rename accounts by pressing :kbd:`F2` on the :guilabel:`User` column.

.. tab-set::

  .. tab-item:: Local User

      Fill in the user name, like :cyan:`user1` for example.

      .. note::
        
        Local users are defined by a :mimetype:`.htpasswd` file.

  .. tab-item:: AD User

      Fill in the user name and add @your_domain.lan, like user1@mydomain.lan.

      .. note::
        
        To manage WAPT users with Active Directory, you need to activate :ref:`Active Directory authentication <ldap_authentication>`.

        After a first successful login, the AD account will appear automatically in the list of WAPT users.

* Save by clicking on :guilabel:`Save account`.

* For setting a password, see below.

* For setting rights, see the section on :ref:`managing ACL rights <manage_right_acl>`.

If the local user has a password in :file:`waptusers.htpasswd`, then the username appears in **bold** and `Local User` is checked, else change the password for this user.

Changing the user password
==========================

To change the password for the selected account:

* Do a :menuselection:`right click on the account --> Change User Password on Wapt Server`.

.. image:: wapt-resources/wapt-change_user_password_on_waptserver.png
  :align: Center
  :scale: 75%
  :alt: wapt change user password on waptserver

* Enter the new password.

.. figure:: wapt-resources/wapt_console_acl-change-password_dialog-box.png
  :align: center
  :alt: Dialog box for changing the user password in the htaccess file

  Dialog box for changing the user password in the htaccess file

The local user appears in *bold* and the `Local User` is checked.

Blocking local user accounts
============================

To unregister local users, do :menuselection:`right click on the account --> Invalidate User Password on WAPT Server`.

.. image:: wapt-resources/wapt-invalidate_user_password_on_waptserver.png
  :align: center
  :scale: 75%
  :alt: wapt invalidate user password on waptserver

The user account will be blocked from managing anything in WAPT.

.. _ACL_rigths:

List of rights
==============

Many :ref:`rights and restrictions <manage_right_acl>` can be set for each user in the WAPT Console.

.. list-table:: List of user rights
  :header-rows: 1
  :widths: auto

  * - Right
    - Description
  * - :guilabel:`Admin`
    - Grants the same rights as *SuperAdmin*, all rights are granted except :guilabel:`local user`.
  * - :guilabel:`View`
    - Allows only view information on the WAPT Console.
  * - :guilabel:`view with certificate`
    - Limits the view to the certificate associated with the user.
  * - :guilabel:`Register hosts`
    - Allows to use the Admin credentials to :ref:`register manually a host <host_packages>` with the WAPT Server.
  * - :guilabel:`Unregister hosts`
    - Allows to :ref:`remove a host <host_packages>` from the WAPT Console.
  * - :guilabel:`Edit hosts`
    - Allows to :ref:`edit the host profile <host_packages>` on the WAPT Console.
  * - :guilabel:`Assign package`
    - Allows to assign package(s) on hosts with the WAPT Console.
  * - :guilabel:`Remote hosts actions`
    - Allows to make use of the Windows Computer Management tool with the WAPT Console.
  * - :guilabel:`Apply upgrade`
    - Allows to remotely apply upgrades on her perimeter of hosts, if host is on **PENDING** status.
  * - :guilabel:`Edit packages`
    - Allows to :ref:`modify base packages <base_packages>` on the WAPT Console.
  * - :guilabel:`Edit groups`
    - Allows to :ref:`modify group packages <group_packages>` on the WAPT Console.
  * - :guilabel:`Edit self-service`
    - Allows to :ref:`modify self-service rules <self-service_packages>` on the WAPT Console.
  * - :guilabel:`Edit WUA`
    - Allows to :ref:`modify WUA / WSUS rules <waptwua_packages>` on the WAPT Console.
  * - :guilabel:`Edit AD groups`
    - Allows to :ref:`modify profiles packages <profile_packages>` on the WAPT Console.
  * - :guilabel:`Edit Org Units`
    - Allows to :ref:`modify unit packages <unit_packages>` on the WAPT Console.
  * - :guilabel:`Edit config packages`
    - Allows to :ref:`create, modify or delete configuration packages <config_packages>` on the WAPT Console.
  * - :guilabel:`Edit Reports`
    - Allows to :ref:`create new or modify reporting queries <wapt_reporting>`.
  * - :guilabel:`Run Reports`
    - Allows to :ref:`run existing SQL reports <wapt_reporting>`.
  * - :guilabel:`View audit data`
    - Allows to read the content of the tab audit data on the WAPT Console.
  * - :guilabel:`WADS admin`
    - Allows a user to have the admin right for WADS on the WAPT Console.
  * - :guilabel:`WADS host deploy`
    - Allows an user to activate the deploy button on the WAPT Console.
  * - :guilabel:`WADS view`
    - Allows to read the content of the tab :guilabel:`OS Deploy`.
  * - :guilabel:`Update audit data`
    - Allows to create, modify or delete the data on the tab :guilabel:`Audit Data` on the hosts.
  * - :guilabel:`Edit repo`
    - Allows an user to create, edit or remove, rules for secondary repository.
  * - :guilabel:`Accounts Manage`
    - Allows creating user accounts. You cannot assign permissions higher than those of your own account.
  * - :guilabel:`Managed by`
    - Allows viewing the manager associated with certain user accounts.
  * - :guilabel:`Add asset`
    - Allows to updates the host with custom data.

.. _manage_right_acl:

Managing rights
===============

By default, the **SuperAdmin** is the :ref:`CA certificate <generating_CA>` user.

For other user, it is **possible to associate a certificate** that has been generated from the WAPT :abbr:`PKI (Public Key Infrastructure)` or from another :abbr:`CA (Certificate Authority)`.

These certificates may or may not be children of the WAPT Certificate Authority.

.. important::

  If certificates are not issued from the Certificate Authority:

  * Updated WAPT packages are available only to computers where certificates are deployed. 
    Use :ref:`this section <generating_CA>` to easily create and deploy user certificates.

  * ACLs are valid only on the perimeter of the hosts where the certificates are deployed.

.. tab-set::

  .. tab-item:: Use classic mode

    1. Select a user.
    2. Choose one or more ACLs to assign.
    3. Set the permission (typically Deny ou Allow).
    4. Save your changes.

    .. figure:: wapt-resources/wapt-assign_acl_classic_mode.gif
      :align: center
      :scale: 50%
      :alt: Assign Acls classic mode

      Example: Assign Acl "register hosts" for user1.

  .. tab-item:: Use Local Role

    1. Open the WAPT Console.

    2. Navigate to: :guilabel:`Server` → :guilabel:`Manage Wapt users and rights` → :guilabel:`New Role`.

    3. Enter the name of the role.

    4. Once the role is created, you can add ACLs to it.

    5. Assign the role to relevant users.

    6. Save the changes.

    .. figure:: wapt-resources/wapt-create_local_role_and_assign.gif
      :align: center
      :scale: 50%
      :alt: Create local role and assign

      Example: Assign the local role "waptpackages" for user1.

  .. tab-item:: Use AD Role

    **AD action ( RSAT or OpenRSAT)**

    1. Create a user group (e.g, waptpackage).

    2. Add the relevant users to this group.

    
    **In the WAPT Console.**

    3. Navigate to: :guilabel:`Server` → :guilabel:`Manage Wapt users and rights` → :guilabel:`New Role`.

    4. Enter the role name, followed by @your_domain.lan (e.g., waptpackage@your_domain.lan).

    5. Once the role is created, you can add ACLs to it.

    6. Automatically, all users in the AD group will inherit the ACLs assigned to the role.

    7. Save the changes.

    .. figure:: wapt-resources/wapt-create_ad_role_and_assign.gif
      :align: center
      :scale: 50%
      :alt: Create AD role and assign

      Example: Assign ad role "waptpackage@domain.lan" for AD users.

Associating a certificate to a user
-----------------------------------

.. hint::

  By default no certificate is set for any user (including *SuperAdmin*).

  The account in the WAPT Console appears in *italic* if no certificate is associated to the user.

There are two classic ways for associationg a certificate with a user.

.. tab-set::

  .. tab-item:: First method

    Select an user and do a :guilabel:`Right-click` → :guilabel:`Register user certificate`

    .. image:: wapt-resources/ACLS-Assign_user_certificate_first_method.png
      :align: center
      :scale: 75%
      :alt: Assign user certificate first method

    Then, choose the certificate to associate to the user.

  .. tab-item:: Second method

    Select an user and click on :guilabel:`Register user certificate` in the top banner.

    .. image:: wapt-resources/ACLS-Assign_user_certificate_second_method.png
      :align: center
      :scale: 75%
      :alt: Assign user certificate second method

    Then, choose the certificate to associate to the user.


Adding / Removing rights
------------------------

To add or remove rights:

1 - Select the user(s).

2 - Choose an ACL from the board.

3 - Enable or disable the desired right by clicking or use "Enter" keyboard.

.. image:: wapt-resources/wapt_console-acl-check-right_screen-item.gif
  :align: center
  :scale: 75%
  :alt: Checking the ACL rights

Restricting the perimeter of rights permitted to user
-----------------------------------------------------

It is possible to associate a perimeter to a right given to a user.

View
^^^^

.. tab-set::

  .. tab-item:: View

    .. list-table:: Definition of the allowed perimeter
      :header-rows: 1
      :widths: auto

      * - Perimeter
        - Description
      * - :guilabel:`Deny all`
        - Denies any view right (not checked).
      * - :guilabel:`Allow on any perimeter`
        - Allows view right for all WAPT Agents.
      * - :guilabel:`Allow specific perimeters`
        - Allows view right on the selected perimeter defined as a list of certificates.
      * - :guilabel:`Allow where user certificate is deployed`
        - Allows view only on the perimeter where the certificate of the WAPT Administrator is deployed.

  .. tab-item:: View with certificate

    When :guilabel:`View with certificate` is activate. The user will be able to see only hosts where is certificate are deployed.

    **Do not forget to assign certificate to user beforehand**

Edit group packages
^^^^^^^^^^^^^^^^^^^

.. hint::

  All group packages work on the same principle as described below.

.. list-table:: Definition of the allowed perimeter
  :header-rows: 1
  :widths: auto

  * - Perimeter
    - Description
  * - :guilabel:`Deny all packages`
    - Denies any edit right to any package (not checked).
  * - :guilabel:`Allow any packages`
    - Allows edit right to all WAPT packages.
  * - :guilabel:`Allow specific packages name`
    - Allows edit right for the WAPT packages selected in the list.

.. _re_sign_package_gui:

*************************************************************
Re-signing packages on the WAPT Server using the WAPT console
*************************************************************

It is possible that a package was created by a WAPT user whose certificate is not recognized on certain machines. 
However, the package might still be suitable for those machines. 
In such cases, you can re-sign the package using the certificate of another WAPT user who has higher privileges within the network.

Go to :guilabel:`Packages inventory`, identify your package and do right-click :guilabel:`Resign packages`.

.. figure:: wapt-resources/wapt_console-re-signing-with-WAPT-console.png
  :align: center
  :alt: Re-signing with WAPT console

  Re-signing with WAPT console

Then, click on :guilabel:`Resign packages`, and wait the :command:`OK`, you can :kbd:`close`.

.. figure:: wapt-resources/wapt_console-re-signing-with-WAPT-console-OK.png
  :align: center
  :alt: Windows of re-signing with WAPT console

  Windows of re-signing with WAPT console

However, if this does not work the only way to perform the operation is to resign on the command line.


*********************************************
Different Ways to Connect to the WAPT Console
*********************************************

**Starting from version 2.7**, multiple methods are available to connect to the WAPT console.

You can still log in using local accounts on the WAPT server or Active Directory (AD) accounts.

However, additional authentication methods have been introduced:

- Log in via **Kerberos** using either your current Windows session (no password required) or by specifying a different username and password.

- Secure authentication methods such as **OAuth2/OpenID** Connect and **Bearer Token**.

Available Authentication Methods
================================

At the opening of the waptconsole you can choose different authetification method

.. white_toggle::
  :titleen: User and Password
  :titlefr: Utilisateur et mot de passe
    
    This method allows authentication using a username and password combination.

    Enter a user and is password .
    See the :ref:`user creation documentation <creating_users>` for details.

.. white_toggle::
  :titleen: Use current sesssion (Kerberos)
  :titlefr: Utiliser la session courante (Kerberos)

  This method allows you to authenticate **without entering a password** by leveraging your active Kerberos session.
  
  To use this feature:

   - Ensure the user is registered in ``waptconsole`` in the format ``user@domain.lan``.

   - Configure Kerberos authentication as described in :ref:`Kerberos configuration <configuring_kerberos_authentication>`.    

.. white_toggle::
  :titleen: Kerberos with user and password
  :titlefr: Kerberos avec utilisateur et mot de passe

  This method allows you to authenticate by leveraging your active Kerberos session.
  
  To use this feature:

   - Ensure the user is registered in ``waptconsole`` in the format ``user@domain.lan``.

   - Configure Kerberos authentication as described in :ref:`Kerberos configuration <configuring_kerberos_authentication>`.    


.. white_toggle::
  :titleen: OAuth2 / OpenID Connect
  :titlefr: OAuth2 / OpenID Connect

   This method enables authentication via **OAuth2/OpenID Connect**, using an identity provider (such as Microsoft Entra ID) for secure, passwordless login.

   **Prerequisites for Microsoft Entra ID:**

   - A Microsoft Entra ID tenant (formerly Azure AD) with admin rights.

   - A web browser to validate authentication.

   - A proxy (if required in your environment) to access Microsoft Entra ID.

   - Access to the WAPT server and admin rights in the WAPT console.

   **Configuration Process:**

   **1. Register the Application in Microsoft Entra ID:**

   - Navigate to `entra.microsoft.com`.

   - Go to **Identity** > **Applications** > **App registrations**.

   - Click **New registration** and fill in the details:

     - **Name**: Your application name (e.g., WAPT OpenID).

     - **Redirect URI**: ``http://localhost:8095/callback``.

   - Go to **Certificates & secrets** and create a new client secret. **Save the secret securely**.

   **2. Configure the WAPT Server:**

   - Open the configuration file: ``/opt/wapt/conf/waptserver.ini``.

   - Add the ``[openid]`` section with the following details:

     .. code-block:: ini

        [openid]
        issuer=https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0
        client_id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
        client_secret=mysecretcode
        redirect_uri=http://localhost:8095/callback
        username_key=upn

   - If using a proxy, add the following line:

     .. code-block:: ini

        http_proxy=http://srvproxy.mydomain.lan:8080

   **3. Update Global Authentication Methods:**

   - Modify the ``[global]`` section in ``waptserver.ini`` to include ``oidc`` in the ``login_auth_methods`` parameter:

     .. code-block:: ini

        registration_auth_methods = oidc,kerb,admin,passwd
        login_auth_methods = oidc,kerb,admin,passwd

   **4. Restart WAPT Services:**

   - Apply the changes by restarting the WAPT services:

     .. code-block:: bash

        systemctl restart waptserver wapttasks

   **5. Local Testing:**

   - Run the following command in a command prompt to test the configuration:

     .. code-block:: powershell

        C:\Users\htouvet>wapt-get openid-auth -c "c:\Program Files (x86)\wapt\wapt-get.ini"

   - A browser window will open, prompting you to grant access to the application. Check the consent box for your organization.

   - **Expected Output:**

     .. code-block:: text

        Code: 1.AR8AbB103-z_eEidXlooPaYJLuvHmHHwvztCsV7nQNvj_yhMAbwfAA.AgABBAIAAABVrSpeuWamRam2jAF1XRQEAwDs_wUA9P9CWi14DUUxhFdifAJG6aygRZwO_bcwGzCXOSlkGUD_YmYsWHGIiBHLiUX5lWnYU0qk847CCOmJxnKZyDepL6-d40yYYhHq
        ...
        ClientSecret is known, using it to exchange code for a token...
        Token: {"aud":"00000003-0000-0000-c000-000000000000","iss":"https://sts.windows.net/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/","iat":1758812637,"nbf":1758812637,"exp":1758817061,"acct":0,"acr":"1","acrs":
        [...0","b79fbf4d-3ef9-4689-8143-76b194e85509"],"xms_ftd":"4Bv2ZusNHcpIBqPAClu5jRjnL-ldhsTz0S54w-3nbrABZXVyb3Bld2VzdC1kc21z","xms_idrel":"1 10","xms_st":{"sub":"xRnlPpQ8mrb2xYcinckhWxAIaaoeiUfLoX3sFoKidK8"},"xms_tcdt":1517
        233874,"xms_tdbr":"EU"}
        ID Token: {"aud":"7198c7eb-bff0-423b-b15e-e740dbe3ff28","iss":"https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/v2.0","iat":1758812637,"nbf":1758812637,"exp":1758816537,"rh":"1.A
        R8AbB103-z_eEidXlooPaYJLuvHmHHwvztCsV7nQNvj_yhMAbwfAA.","sub":"xRnlPpQ8mrb2xYcinckhWxAIaaoeiUfLoX3sFoKidK8","tid":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","uti":"cABi3a7vQECEsCD_EAVUAA","ver":"2.0"}
        User authenticated: XXXX XXXXXXX
        End session: 1

   **6. Assign Application Roles:**

   - In **Microsoft Entra ID**, navigate to **Enterprise Applications**.

   - Select your newly registered application.

   - Go to **Users and groups** > **Add user/group**.

   - Select the users who will have the ``waptadmins`` role.

   **7. Verify Role Assignment in Token:**

   - Test the authentication again with the following command:

     .. code-block:: powershell

        wapt-get openid-auth -c "c:\Program Files (x86)\wapt\wapt-get.ini"

   - Ensure the token contains the role assignment: ``"roles":["waptadmins"]``.

   **8. Configure Roles in the WAPT Console:**

   - Log in to the WAPT console with an admin account.

   - Navigate to **User and Rights Management**.

   - Check **Roles** > **New Role**.

   - Rename the default role (e.g., ``role1``) to ``waptadmins``.

   - Assign the desired permissions, then close the window and log out.

   - Reopen the console and log in using the **OAuth2/OpenID Connect** option.

.. white_toggle::
  :titleen: Bearer Token
  :titlefr: Bearer Token

    A Bearer Token can be generated using various authentication methods to verify the user's identity, such as Kerberos or username/password credentials.

    To enable this feature, add ``token`` to the ``login_auth_methods`` parameter in the waptserver.ini file. After making this change, restart the WAPT services to apply the modifications:

    .. code::

      systemctl restart waptserver wapttasks

    How to create a token examples: 
          
    .. tab-set::

      .. tab-item:: Login / Password

        - Open a command prompt on the machine

        - Run :code:`wapt-get server-login` and enter your credentials (local account or user@mydomain.lan)

        - A token will be generated, which you can use to access the console

      .. tab-item:: Kerberos

        - Run :code:`wapt-get server-login --login_method=sessionkerberos`

        - A token will be generated, which you can use to access the console

    .. note::

      For this moment token have a lifetime to 12h, to change it you can modify the value of the token_lifetime in the file /opt/wapt/waptserver/config.py .


.. white_toggle::
  :titleen: x509 certificate
  :titlefr: x509 certificate

  It is possible to connect to the **WAPT Console** using an **X.509 certificate**. This method provides a secure and passwordless authentication option.

  **How to configure it**

  *In the WAPT Console:*

    - Create a User Certificate: Generate a certificate with the same name as the user (example: certificate john for user john@domain.lan ).

    - Associate the Certificate with the User: In the WAPT Console, go to User Rights Management and link the certificate to the user.
        
        - In the WAPT Console, navigate to **Server > Manage WAPT Users and Rights (ACLs)**.

        - Select the desired user.

        - Click **Register User Certificate** and upload the user's X.509 certificate.

  *In the WAPT Server:*

    - Update waptserver.ini: Add :guilabel:`ssl` to the authentication methods parameter :guilabel:`login_auth_methods`.

    - Create a Client Certificates File: Create a file (e.g., /opt/wapt/conf/ca-clients.crt) and append the public parts of user certificates to it.

    - Configure Nginx: Edit :file:`/etc/nginx/sites-enabled/wapt.conf` and modify the line : ssl_client_certificate "/opt/wapt/conf/ca-clients.crt".

    - Reload Nginx: 

      .. code-block:: 
        
        nginx -s reload

    - Restart WAPT Services

      .. code-block:: 
        
        systemctl restart waptserver wapttasks waptserver-uwsgi

  *In the WAPT Console:*

    - Choose the right certificate in the parameter tools > preferencies > path to personnal certificate.

    - Close and relaunch the waptconsole

    - The user can now connect to the WAPT Console with the option **X.509 certificate**.

.. hint::
    
  You can test any authentication method by entering the required credentials in the login fields (e.g., username/password or token). 

The successfully chosen method will be saved for the next session.

