Management servers

You can configure the following management servers on the SR Linux:

gRPC server – allows external gRPC clients to connect to the device and modify the configuration and collect state information
JSON-RPC server – allows you to issue JSON-formatted requests to the device to retrieve and set configuration and state

You can configure Transport Layer Security (TLS) profiles, which contain TLS settings that can be provided to the gRPC and JSON-RPC management servers.

gRPC server

SR Linux can enable a gRPC server that allows external gRPC clients (gNMI, gNOI, gNSI P4Runtime, and gRIBI) to connect to the device and modify the configuration and collect state information.

When the gRPC server is enabled, the SR Linux gRPC server functions as a target for gRPC clients. The gRPC server validates gRPC clients and passes RPCs to the SR Linux mgmt_server application via the gRPC interface.

Configuration changes made by gRPC clients are made within a private candidate configuration, using a snapshot of the current running configuration as a baseline for the private candidate. As with other types of candidate configurations, the private candidate can operate in exclusive mode, which locks out other users from concurrently modifying the private candidate configuration.

Sessions between gRPC clients and the SR Linux device can be encrypted using TLS. You can specify TLS settings within a TLS profile, and apply the TLS profile when configuring a gRPC server within a network instance. When the gRPC server is enabled, gRPC clients connect and authenticate to the SR Linux device using the settings specified in the TLS profile.

New connections between gRPC clients and the SR Linux device are mutually authenticated. By default, the SR Linux device validates the X.509 certificate of the gRPC client, and the other way around; this behavior can be disabled in the TLS profile. The SR Linux device, after validating the X.509 certificate of the gRPC client, performs local authentication if the metadata-authentication parameter is set to true. In this case, the gRPC client is required to provide a username and password in the metadata of the RPCs. The supplied username and password are authenticated by the SR Linux aaa_mgr application.

In cases where the client's X.509 certificate contains a SPIFFE-ID, the SPIFFE- ID is checked for a match with any user in the system. When a match is found, the client receives the permissions granted to that user. The user is rejected if there is no match. For information about using SPIFFE for client authentication, see Using SPIFFE for client authentication (mTLS).

For more information about supported gRPCs, see the following:

SR Linux System Management Guide (for gNOI, gNMI, and gNSI)
SR Linux gRIBI Guide
SR Linux P4Runtime Guide

Configuring a gRPC server

Note: gRPC server configuration is supported on 7220/7250 IXR and 7215 IXS-A1 platforms.

SR Linux supports configuring one or more gRPC servers for one or more network instances. Each gRPC server is distinguished by a unique configurable name. For each server instance, you can specify the services that the instance supports.

Note:

If no services are configured when the server instance is enabled, all services are enabled by default.
For upgrades from pre-24.3.1 releases, gRPC server instance mgmt is automatically created and all existing configurations are moved to this path.

You can limit the number of simultaneous active gRPC client sessions, as well as the number of connection attempts per minute by gRPC clients. You can also specify the IP address and port for gRPC client connections, as well as the TLS profile used for authenticating gRPC clients. See TLS profiles.

The following example shows a configuration that enables a gRPC server running gNMI on the SR Linux device. The gRPC server is configured so that gNMI clients can connect to SR Linux via the mgmt network instance on port 50052 (default: 57400). Connecting gNMI clients are authenticated using the settings specified in the TLS profile tls-profile-1. The max-concurrent-streams parameter sets the limit on the number of concurrent gRPC streams.

Note: 57400 is the default gRPC server port value, Any other value requires that you configure an ACL CPM filter to accept traffic on the configured port value (in this case 50052).

--{ * candidate shared default }--[  ]--
# info system grpc-server mgmt
    system {
        grpc-server mgmt {
            admin-state enable
            timeout 7200
            rate-limit 60
            session-limit 20
            max-concurrent-streams 100
            metadata-authentication true
            tls-profile tls-profile-1
            network-instance mgmt
            port 50052
            trace-options [
                request
                response
                common
            ]
            services [
                gnmi
            ]
            source-address [
                192.168.0.1
            ]
            gnmi {
                commit-confirmed-timeout 10
                commit-save false
                include-defaults-in-config-only-responses false
            }
            unix-socket {
                admin-state enable
            }
        }
    }

Disconnecting clients from a gRPC server

You can use a tools command to manually disconnect gRPC clients from the server.

To do this, obtain the identifier for the P4Runtime client using the info from state system grpc-server <name> command, then enter the following command to disconnect the client:

Disconnect client from the gRPC server

-{ running }--[  ]--
# tools system grpc-server mgmt client 4053 disconnect

Displaying gRPC client information

To display gRPC service information for a client, use the info from state system grpc-server mgmt client <id> command, with the following optional parameters.

election-id: election ID of the client
gnmi: container for gNMI related session info
gribi: container for gRIBI related session info
p4rt: container for P4RT related session info
remote-host: remote host of the client
remote-port: remote port of the client
rpc: the called package, service, and RPC
start-time: time of the subscription creation
type: client type
user: authenticated username for the client
user-agent: user agent used for the client

Displaying the RPCs that clients are using

To display the RPCs that a client is using, get the identifier for the gRPC client from the info from state system grpc-server <name> command, then enter the following command to display the RPCs for that client:

-{ running }--[  ]--
# info from state system grpc-server mgmt client 4053 rpc

JSON-RPC server

You can enable a JSON-RPC server on the SR Linux device, which allows you to issue JSON-formatted requests to the device to retrieve and set configuration and state. You can use the JSON-RPC API to run CLI commands and standard get and set methods. The SR Linux device returns responses in JSON-format.

Configuration changes made using the JSON-RPC API are made within a private candidate configuration, using a snapshot of the current running configuration as a baseline for the private candidate. As with other types of candidate configurations, the private candidate can operate in exclusive mode, which locks out other users from concurrently modifying the private candidate configuration.

When the JSON-RPC server is enabled, the application passes the requests to the SR Linux mgmt_svr application via the gRPC interface. This JSON-RPC API uses HTTP and HTTPS for transport and users are authenticated with the aaa_mgr application. HTTPS requests can be authenticated using TLS, using settings specified in a TLS profile. See TLS profiles.

In cases where the client's X.509 certificate contains a SPIFFE-ID, the SPIFFE- ID is checked for a match with any in the system. When a match is found, the client receives the permissions granted to that user. The user is rejected if there is no match. For information about using SPIFFE for client authentication, see Using SPIFFE for client authentication (mTLS).

See the SR Linux System Management Guide for examples of using the get method to retrieve state information from the SR Linux, the set method to modify the SR Linux configuration, and the cli method to enter SR Linux CLI commands.

Configuring a JSON-RPC server

The SR Linux supports configuring a JSON-RPC server under one or more network-instances. You can specify limits for the number of simultaneous active HTTP or HTTPS connections and the TCP port used for HTTP or HTTPS connections. If the TCP port is in use when the JSON-RPC server attempts to bind to it, the commit operation fails.

The following example shows a configuration that enables a JSON-RPC server within the mgmt network-instance on the SR Linux device. The JSON-RPC server is configured so that HTTP requests are accepted on TCP port 4000 and TCP port 443. HTTPS requests are authenticated using the settings in the TLS profile tls-profile-1.

--{ * candidate shared default }--[  ]--
# info system json-rpc-server
    system {
        json-rpc-server {
            admin-state enable
            network-instance mgmt {
                http {
                    admin-state enable
                    use-authentication true
                    session-limit 1
                    port 4000
                }
                https {
                    admin-state enable
                    use-authentication true
                    session-limit 1
                    port 443
                    tls-profile tls-profile-1
                    source-address [
                        ::
                    ]
                }
            }
        }
    }

Note:

To connect to the configured JSON-RPC server, enter the <source-address> defined in the system json-rpc-server configuration, followed by /jsonrpc:

https(s)://<source-address>/jsonrpc

TLS profiles

TLS is a protocol for enabling applications or devices to exchange information. The SR Linux supports configuring TLS settings in TLS profiles, which can be provided to applications such as the gRPC server and the JSON-RPC server, so that clients connecting to the SR Linux device via these applications are authenticated using the settings in the TLS profile.

Configuring a TLS profile

A TLS profile can specify whether authentication is performed for clients connecting to SR Linux applications to which the profile is applied. Within a TLS profile, you can configure certificates, keys, and ciphers to use when negotiating TLS connections with clients.

--{ * candidate shared default }--[  ]--
# info system tls
    system {
        tls {

            server-profile clab-profile {
                key $aes1$ATMxOVggIuZnwW8=$c7pnl/gCx62+/gDmsIklg8cQW6RbdwxL2LxTsrxlMEAtdGupPrjL8wrqvhEWb0ET4Q1hAz4CnwwbcWDdJpOWcV/EzVeRvdR5Rkdt0DemjPXsCtbxjxtf/dxmXUOTSLkk80SWNGp97xUMojdhAJUMVDFloU7qpcIYyMrzlsvU3pMCG4VJAF+PPsiXeUZUz4HnqahtxMcOmCBdLqVgt1iw7kTss/BVqTvpLftXGDyUvALOmgLvvSjPY8fvtC8V1rlpOvWfvXhbYwrfkYU2pnbkxvLCDDbabgpPD1jUyvBQ4SQz0c3MqXfg8kiWUd0jKw1OM9R6EqcGt6RFuYHON4CRzRmsA/gUZXbUhUwter8Dz1sJ9D1oU4SkaiJju4RzTIxzBcXtNpar31aBYn2mikCgotV4r+XgcQZsjHqxG2o2wt6e/VNL+S8bG+1AVG8Tpne/HFmV7wMzWjLP4bWTe0HB3f4pzmN11r0Z87yLGwaCTyXSowy+IYFM1Ffpx8NLWcgH9nOkvRdDA2xuKFqHYpWIU2UFujRolTe8PifrSeZkSIcwwQcjrs6qbG5qb4xT0gQS4ODGGXpsqeSyRm0FRsU0MRRcKcGEVeyjDODYNU/PeBnLat598M3NQ8qRLdksN/MSJqehHl4hQCqXtLUiz00PfHy16xCsJX3eUTJ/svByfNsOE//e6PtC5jVW4ATYiZnzIsY8wU0L2xy+hX0TLHz1G9OH5FYqy9lbujBRTFRw5/5Pno7euSB8cSub/QLMcbBubDUExSpifrmURP+BREDbsPDL2tFhYgwqal2iYuAQyFE8J3Nmly9iyyZEQZMl/ZqSEm0d5lPaF6333YkdWW1Dzj85twbPT8Sy3bshhouhAIsnj5Wjk1ToztJZ2CLJdRQ/U8rukbldhdIF+O/6hHNwazheGI+G2/cE8DpV4kBan80Ty9EZ/dxSoPoELWCTeDBqbr32ADYtF4lRcrgoNcN+jZLnDDBstdz7pKtPb5CO7VamgUmptQWDyGiUM/QCuCzpmNlHsT1hcDfORX01xmC0rqq+GX3Qoi4FsbAhYKQKe1wpEE4bvbf5Xdmfb8Y4FMAEDjRp98XneIlHIEvHYdlZu6MxB9pL9RMk/hSlsUiyviupvoAAhd0H51MjuRMwDl6K/g5BoZsKW2oZaw/tcgHPqlopSMIlDV+d8LDax7Zumf2uGxYhRxN/z3IrctkRKUli13exJ9Vybd8NgXXhfyVlg5CR/Bed9VdiSHTtAWcZxya8wdgeeaEGXgTC+zK9oh9DoT8D3fFAsymedwdmuHCPeWwFWf8xOaxCoZa/qo3cJrKP2hpqPiFGJRBFxddIi7b5BlWNj4VSC4hof7sdflEEfNQ8jxLeurlGmKr2adLEeODLirghSc2HtZ5i9qtaNLi08Lc30T+xz4SRZNCiX62E3XRkyRyOMMKvU+3u39+oo94PAzsUwwUMvYTQdHgluElqU/gEqybmZMqiXp+l6driapo1RlqvEYD7hPTXmNuIwSJOyZspr12eGzEg7DzfBrHNVgWgk2sXExmtW+mS0nBPX/+k18LQnwgtskD//uamjwC/IKm6zKp8HIKpnTB4qd4nvyKjWiwoh3O9IQqvPrQ7Dn5ihQMM94NxToAqxubIBMCpjcQSLfEOwy0cZVdgSiS/GRfA45UUViAutoSAE/BN+9FQ4UHZa/+3fc1tBtmLm/qsKwcSn1QyUtaY5V6NVrHW6yiFysAKbnyAgdI5SlXX1oSXQBQvzptoSKRMu9RKGsP/9HaS+qDmuePIj/UQdlkTU/tOQom2NsleOXBLZFWVUAF+uhq4Ef/ggQNEOaUE8PenAlfhkeaOlNN9XGbDIOEHs/dQLONLMABgIVWs5E2mj8a2kC3BjyXIdLtGg2a1XDi57ZeT0eH88tra5hKN7+P8O3X8A1llGx/60Q1/7GsTSYJHN+FQqmgASfvHnZRgcZNPKAutqjuwq4CVngZcoUxOummdM2aW/H5bsl6m8bgJpGPFFK+8REg61v/cttv7CWc6syempQ16k56iCXmf6yvY6Mloyij9jBRt1fJLqDE67JBNyRr+rstcOpj0fLIsWld8gqtx19dD3h4GJveTzGlMe3VZuAsnAv8v31SYwwDMFwypO+xacBjO3Pzht++TrVrwLG9R5HPUTnp2lxOQA33Ym3R+2i65ktKWcnrUMcQInxAm6zwhMA+yQaCZmDIZAfRlZ54wE9mlaATGoI0N7/tw
                certificate "-----BEGIN CERTIFICATE-----
MIID2DCCAsCgAwIBAgICBnowDQYJKoZIhvcNAQELBQAwUzEJMAcGA1UEBhMAMQkw
BwYDVQQHEwAxFTATBgNVBAoTDGNvbnRhaW5lcmxhYjEJMAcGA1UECxMAMRkwFwYD
VQQDExBzcmxjZW9zMDEgbGFiIENBMB4XDTI0MDIxNjA1MDYwNFoXDTI1MDIxNjA1
MDYwNFowVDEJMAcGA1UEBhMAMQkwBwYDVQQHEwAxFTATBgNVBAoTDGNvbnRhaW5l
cmxhYjEJMAcGA1UECxMAMRowGAYDVQQDExFzcmwxLnNybGNlb3MwMS5pbzCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANKb/Um7TzljvC84vpHKt3FwA9/p
zo94Je1treFJDaH5sVIfHCkGFj0QUcuB9Xc/zEd+O18pY1Xt1/4GdXoYnWlPkXOV
NVJqXt8As/sZOoa4gGTizz0KLOwd/by/FEhMCfIXKOa+5FIC3NgA2LYMYHMTAFYq
EBYku6rcVM96yW4BFnDhatefJf8SFO3wh4AWAQok52H+DxME7rwnBK7B3ITPQKYG
seZZHMC8O65wIHjrUxn+D63Aea6PbJzFlAzT1MaUw3qfMKiErLLXETXg9ylLGugM
TwV9Jh4KwuJTLJch+adhLRIxwipQ+sHtsHG8vjuU8xe+EdgeA4DzMRXNYZsCAwEA
AaOBtDCBsTAOBgNVHQ8BAf8EBAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG
AQUFBwMBMA4GA1UdDgQHBAUBAgMEBjAfBgNVHSMEGDAWgBSBDbZBxouhQI85egna
FbecTUl/2jBPBgNVHREESDBGggRzcmwxghNjbGFiLXNybGNlb3MwMS1zcmwxghFz
cmwxLnNybGNlb3MwMS5pb4cErBQUA4cQIAEBcgAgACAAAAAAAAAAAzANBgkqhkiG
9w0BAQsFAAOCAQEAaCAzkQkjxx32lvWa78pnUzIZmIUr6K1ZciMeslLuQb1PB4jn
GPiKNXghesVoiAmvUV2H7BBf6fLgVQvRqcSgJwyT50MAyRgaHW8L7XnSJVvXpjMU
uLKyvkUWeWZqWzfy6+nA/YhC1qr3FV3/v9s1BbdyBy/eluRcjpQZRrvNKG4+ZAsZ
JR8yWs3k8fTvybpFxcy7V5W7/oVdcw36N17fmA91X5NElk3reEQagmno7GwLOFfx
b8GpxIvu1JjIUDib0Ri8atZlsymwDlCvPPmhFgixlEwVlsAqmhNDBCfmSlmOvROC
eZT2SM6EUlZ4jOvcKFXtDptmMiGeNg9r0Fp3kA==
-----END CERTIFICATE-----"
                authenticate-client false
                cipher-list [
                    ecdhe-ecdsa-aes256-gcm-sha384
                    ecdhe-ecdsa-aes128-gcm-sha256
                    ecdhe-rsa-aes256-gcm-sha384
                    ecdhe-rsa-aes128-gcm-sha256
                ]
            }
        }
    }

Note:

The following TLS 1.3 ciphers are always enabled and are non-configurable.

tls_aes_256_gcm_sha384
tls_aes_128_gcm_sha256
tls_chacha20_poly1305_sha256

By default, the following TLS 1.2 ciphers are used unless explicitly configured by a user.

ecdhe-ecdsa-aes256-gcm-sha384
ecdhe-ecdsa-aes128-gcm-sha256
ecdhe-rsa-aes256-gcm-sha384
ecdhe-rsa-aes128-gcm-sha256

Configuring a TLS profile with TPM Device Identity

Note: TLS client authentication using the TPM IDevID key and certificate is supported on 7250 IXR-6e and 7250 IXR-10e CPM4 with Root of Trust and 7250 IXR-X1b/X3b systems.

SR Linux supports configuring a TLS server-profile to use the TPM IDevID (Initial Device Identity) or oIDevID (owner Issued Initial Device Identity) key and certificate, instead of configuring the private key and certificate.

Use the command system.tls.server-profile.use-tpm-devid to configure the TLS server to authenticate clients based on the TPM device IDs and certificates during TLS handshake and session establishment.

Configure TLS profile to use IDevID key with IDevID certificate

In the following example, TLS connections are authenticated using the TPM IDevID key and certificate. This profile affects any new TLS sessions that use it.

--{ * candidate shared default }--[  ]--
info system tls server-profile clab-profile
    system {
        tls {
            server-profile clab-profile {
                
                use-tpm-devid idevid
                
            }
        }
    }

Configure TLS profile to use IDevID key with oIDevID certificate

In the following example, TLS connections are authenticated using the TPM IDevID key and the operator's device ID certificate (oIDevID). This profile affects any new TLS sessions that use it.

info system tls server-profile clab-profile
    system {
        tls {
            server-profile clab-profile {
                
                use-tpm-devid oidevid
                
            }
        }
    }

Note: When the use-tpm-devid parameter is set to oIDevID, and oIDevID is not present, the system does not revert to IDevID. This ensures that the TLS server is operational only if oIDevID is present on the CPM.

Generating a self-signed certificate

From the SR Linux CLI, you can create a self-signed certificate and key. By default, SHA-256 hash functions with RSA encryption are used for the signature algorithm. Private keys are not encrypted using DES/3 and are 4096 bits in length.

The following example generates a private key, followed by the self signed certificate:

# tools system tls generate-self-signed email info@nokia.com country us organization nokia
/system/tls:
-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQC3Q7PnCWjevlFn
--snip--
1ecXRjvpRvIEDUWYqVOioMfCaWxJoTJUX6HgjIY0Z9ktfWiceX1Ka4e3ZxIpEC4p
SvzKsoCTqpQcIk5pCsALhznOO6ArtPc4
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIE/TCCAuWgAwIBAgIJAKzAUREbPIV1MA0GCSqGSIb3DQEBCwUAMBQxEjAQBgNV
--snip-
BTTcAiQnIIkdJ0niqE+ZcOneSgxP3dKEovWQ+Bh3ES2QLsqbDvBYjz4eBoDigaAZ
KDnK207h3hiKLAaxMbAQeWGiu2ZKoKKdd4QE6OphOw6T
-----END CERTIFICATE-----

This tools command example is equivalent to the following openssl command:

# openssl req -x509 -newkey rsa:4096 -days 365

Generating a certificate signing request

You can issue a CLI command that returns a private key and certificate signing request (CSR). This CSR can be passed to a certificate authority (the same one that the client/server uses to validate certificates on either side) for the certificate authority to sign the request; the CSR cannot be used as-is.

The following command returns the private key, followed by the CSR:

# tools system tls generate-csr email info@nokia.com country us organization nokia
/system/tls:
-----BEGIN PRIVATE KEY-----
MIIJRAIBADANBgkqhkiG9w0BAQEFAASCCS4wggkqAgEAAoICAQC3Q7PnCWjevlFn
--snip--
1ecXRjvpRvIEDUWYqVOioMfCaWxJoTJUX6HgjIY0Z9ktfWiceX1Ka4e3ZxIpEC4p
SvzKsoCTqpQcIk5pCsALhznOO6ArtPc4
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE REQUEST-----
MIIC5TCCAc0CAQAwgZ8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
vy3MjE7rJtmWTg0pTfiuU4BFoAzLhHRN1hl1mXuE2m6XJ8gvBPp2sN7SvieUCy/L
RVTs+/Fmcc4vMjx3t/0hAewIsd7DNe+kVQ==
-----END CERTIFICATE REQUEST-----

This tools command example is equivalent to the following openssl command:

# openssl req -newkey rsa:4096

SPIFFE

SPIFFE (Secure Production Identity Framework for Everyone) is a framework that enables services to bootstrap and obtain identity. SPIFFE enables a central authority (CA) to issue signed certificates for identifying clients and servers, establishing mutual trust among them based on their trust in the CA.

SPIFFE is applicable only for TLS sessions and is not used when system is accessed over SSH/CLI or any other non-TLS interfaces.

SPIFFE defines an identity document known as the SPIFFE Verifiable Identity Document (SVID). This is a cryptographically-verifiable document that contains a SPIFFE ID, which represents the identity of a service. SVIDs can be encoded in two formats: X.509 certificates or JWT tokens1.

Note: SR Linux supports X.509 certificates as SVIDs only.

In an X.509 SVID, the corresponding SPIFFE ID is set as a URI type in the Subject Alternative Name (SAN) extension (subjectAltName) field. The SVID only supports one URI field in the SAN extension. You can add multiple IP or DNS fields to the SAN, but there must be only one URI in the SAN.

A SPIFFE-ID is a URI that starts with spiffe scheme, followed by a FQDN and a path that identifies the user. For example,

spiffe://nokia.com/sa/alice

where, nokia.com refers to the domain name, and alice refers to the user.

SPIFFE is used for authentication only. Authorization is performed by the role assigned to the user referred by the SPIFFE-ID.

Leveraging SPIFFE

The high-level steps for leveraging SPIFFE are as follows:

Create two sets of certificates, one for the server and one for the client. These certificates should be signed by a Certificate Authority (CA).
Configure a TLS profile on the system with authenticate-client parameter set to true and the trust-anchor parameter set to the public certificate of the CA that was used to sign the client and server certificates. For more information, see Configuring a TLS profile.
Reference the TLS profile to use on a TLS supporting server. For configuration examples, see the sections that correspond to the TLS server you are using:
- For gRPC server configurations, see Configuring a gRPC server.
- For JSON-RPC server configurations, see JSON-RPC server.
- For gRIBI server configurations, see the section "Enabling the gRIBI server for a network-instance" in SR Linux gRIBI Guide.
- For P4Runtime server configurations, see the section "Configuring the P4Runtime server for a network-instance" in SR Linux P4RT Guide.
Configure a SPIFFE-ID for a user. For instructions, see Configuring SPIFFE-ID for users.

Note:

The TLS supporting server does not check the SPIFFE-ID in the client’s X.509 certificate unless you enable mTLS (set .system.tls.server-profile[].authenticate.client to true). Additionally, the presence of a SPIFFE-ID in the client's X.509 certificate does not necessarily indicate support for mTLS.

Configuring SPIFFE-ID for users

The SPIFFE-ID list is configured under .system.aaa.authentication.user. The format of SPIFFE-ID is spiffe://<domain-name>/<user>.

Configure SPIFFE-ID for a local user

--{ * candidate shared default }--[  ]--
# info system aaa authentication user srl-test-user spiffe-ids
    system {
        aaa {
            authentication {
                user srl-test-user {
                    spiffe-ids [
                        spiffe://nokia.com/srl-test-user
                    ]
                }
            }
        }
    }

Configure SPIFFE-ID for a admin user

--{ * candidate shared default }--[  ]--
# info system aaa authentication admin-user spiffe-ids
    system {
        aaa {
            authentication {
                user admin-user {
                    spiffe-ids [
                        spiffe://nokia.com/admin-user
                    ]
                }
            }
        }
    }

Using SPIFFE for client authentication (mTLS)

In a handshake with TLS client authentication (authenticate-client enabled), the server expects the client to present its X.509 certificate.

In cases where the client's X.509 certificate contains a SPIFFE-ID, the SPIFFE-ID is checked for a match with any SPIFFE-ID configured within the spiffe-ids field in the user configuration. When a match is found, the client receives the permissions granted to that user. The user is rejected if there is no match.

If the X.509 certificate provided by the client does not contain a SPIFFE-ID, the behavior depends on whether the TLS supporting server has enabled the use-authentication or not. When enabled, the HTTP metadata is checked for the username and password. To proceed with authentication, both the username and password must be provided. When the use-authentication is not enabled, the client is rejected.