Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / bmcweb / 4d7b5ddb3a2b6cc42b7bbc0c710f297e6df4fd55
commit4d7b5ddb3a2b6cc42b7bbc0c710f297e6df4fd55[log] [tgz]
authorMalik Akbar Hashemi Rafsanjani <malikrafsan@meta.com>Wed Feb 26 13:14:30 2025 -0800
committerMalik Akbar Hashemi Rafsanjani <malikrafsan@meta.com>Fri Mar 14 07:43:14 2025 -0700
tree3a03ecfb82a2ad3f8fe3b4774f421a444f9199bd
parentd033fd17ae806365d12bb12bee7663c71e3f3512 [diff]
mtls: implement UPN parse mode

This commit is intended to implement the UserPrincipalName (UPN) parse
mode on mutual TLS (MTLS). By implementing this we can use the X509
certificate extension Subject Alternative Name (SAN), specifically UPN
to be used as the username

In our case, this feature is needed because we have a specific format
on our Subject CN of X509 certificate. This format cannot directly
mapped to the username of bmcweb because it contains special
characters (`/` and `:`), which cannot exist in the username.
Changing the format of our Subject CN is very risky. By enabling
this feature we can use other field, which is the SAN extension to
be used as the username and do not change our Subject CN on the
X509 certificate

In general, by implementing this feature, we can enable multiple
options for the system. There might be other cases where we want to
have the username of the bmcweb is not equal to the Subject CN of the
certificate, instead the username is added as the UserPrincipalName
field in the certificate

The format of the UPN is `<username>@<domain>` [1][2]. The format
is similar to email format. The domain name identifies the domain
in which the user is located [3] and it should match the device name's
domain (domain forest).

Tested
- Test using `generate_auth_certificate.py` (extended on patch [4])
- Manual testing (please see the script mentioned above for more detail)
  - Setup certificate with UPN inside SAN extension
  - Change the CertificateMappingAttribute to use UPN
  - Get request to `/SessionService/Sessions`
- Run unit tests

[1] UPN Format: https://learn.microsoft.com/en-us/windows/win32/secauthn/user-name-formats#user-principal-name
[2] UPN Properties: https://learn.microsoft.com/en-us/windows/win32/ad/naming-properties#userprincipalname
[3] UPN Glossary: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wcce/719b890d-62e6-4322-b9b1-1f34d11535b4#gt_9d606f55-b798-4def-bf96-97b878bb92c6
[4] Patch Testing Script: https://gerrit.openbmc.org/c/openbmc/bmcweb/+/78837

Change-Id: I490da8b95aee9579546971e58ab2c4afd64c5997
Signed-off-by: Malik Akbar Hashemi Rafsanjani <malikrafsan@meta.com>
9 files changed
tree: 3a03ecfb82a2ad3f8fe3b4774f421a444f9199bd
  1. .github/
  2. config/
  3. http/
  4. include/
  5. redfish-core/
  6. scripts/
  7. src/
  8. static/
  9. subprojects/
  10. test/
  11. .clang-format
  12. .clang-tidy
  13. .codespell-ignore
  14. .dockerignore
  15. .eslintignore
  16. .gitignore
  17. .markdownlint.yaml
  18. .openbmc-enforce-gitlint
  19. .prettierignore
  20. .shellcheck
  21. AGGREGATION.md
  22. CLIENTS.md
  23. COMMON_ERRORS.md
  24. DBUS_USAGE.md
  25. DEVELOPING.md
  26. HEADERS.md
  27. LICENSE
  28. meson.build
  29. meson.options
  30. OEM_SCHEMAS.md
  31. OWNERS
  32. README.md
  33. Redfish.md
  34. REDFISH_CHECKLIST.md
  35. run-ci
  36. TESTING.md
README.md

OpenBMC webserver

This component attempts to be a "do everything" embedded webserver for OpenBMC.

Features

The webserver implements a few distinct interfaces:

  • DBus event websocket. Allows registering on changes to specific dbus paths, properties, and will send an event from the websocket if those filters match.
  • OpenBMC DBus REST api. Allows direct, low interference, high fidelity access to dbus and the objects it represents.
  • Serial: A serial websocket for interacting with the host serial console through websockets.
  • Redfish: A protocol compliant, DBus to Redfish translator.
  • KVM: A websocket based implementation of the RFB (VNC) frame buffer protocol intended to mate to webui-vue to provide a complete KVM implementation.

Protocols

bmcweb at a protocol level supports http and https. TLS is supported through OpenSSL.

AuthX

Authentication

Bmcweb supports multiple authentication protocols:

  • Basic authentication per RFC7617
  • Cookie based authentication for authenticating against webui-vue
  • Mutual TLS authentication based on OpenSSL
  • Session authentication through webui-vue
  • XToken based authentication conformant to Redfish DSP0266

Each of these types of authentication is able to be enabled or disabled both via runtime policy changes (through the relevant Redfish APIs) or via configure time options. All authentication mechanisms supporting username/password are routed to libpam, to allow for customization in authentication implementations.

Authorization

All authorization in bmcweb is determined at routing time, and per route, and conform to the Redfish PrivilegeRegistry.

*Note: Non-Redfish functions are mapped to the closest equivalent Redfish privilege level.

Configuration

bmcweb is configured per the meson build files. Available options are documented in meson_options.txt

Compile bmcweb with default options

meson setup builddir
ninja -C builddir

If any of the dependencies are not found on the host system during configuration, meson will automatically download them via its wrap dependencies mentioned in bmcweb/subprojects.

Use of persistent data

bmcweb relies on some on-system data for storage of persistent data that is internal to the process. Details on the exact data stored and when it is read/written can seen from the persistent_data namespace.

TLS certificate generation

When SSL support is enabled and a usable certificate is not found, bmcweb will generate a self-signed a certificate before launching the server. Please see the bmcweb source code for details on the parameters this certificate is built with.

Redfish Aggregation

bmcweb is capable of aggregating resources from satellite BMCs. Refer to AGGREGATION.md for more information on how to enable and use this feature.