Skip to content

Commit 619e565

Browse files
authored
Merge pull request #15229 from DefectDojo/release/3.1.100
Release: Merge release into master from: release/3.1.100
2 parents b4ab122 + 1af626b commit 619e565

83 files changed

Lines changed: 3575 additions & 150 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

components/package.json

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"name": "defectdojo",
3-
"version": "3.1.0",
3+
"version": "3.1.100",
44
"license": "BSD-3-Clause",
55
"private": true,
66
"dependencies": {
137 KB
Loading
144 KB
Loading
278 KB
Loading
91.5 KB
Loading
123 KB
Loading
220 KB
Loading
5.35 KB
Loading

docs/content/admin/user_management/OS__creating_new_users.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -36,6 +36,8 @@ The admin who creates the account is responsible for delivering the initial cred
3636

3737
If your instance is configured with [SSO](../configure_sso/), the workflow is different — users are typically created on first login from the Identity Provider, and you only need to grant them group membership or roles afterwards.
3838

39+
If you have moved to open-source DefectDojo (where SSO is Pro-only) and existing SSO users can no longer log in, see [Re-enabling login for SSO users](../os__sso_user_local_login_fallback/).
40+
3941
## Recovering from a lost MFA token
4042

4143
If a user loses access to their MFA device, see the [MFA recovery section](/get_started/pro/cloud/connectivity-troubleshooting/#ive-lost-access-to-my-mfa-codes) of the connectivity troubleshooting guide. There is currently no way to remove MFA from an account without an MFA code — the workaround is to create a new account for the user and re-grant the same permissions.
Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
---
2+
title: "Re-enabling login for SSO users (Open Source)"
3+
description: "Give SSO-provisioned users a local password after moving to Open Source, where SSO is a Pro-only feature"
4+
audience: opensource
5+
weight: 2
6+
---
7+
8+
## When this applies
9+
10+
SSO (SAML, OIDC, OAuth) is a [DefectDojo Pro](https://defectdojo.com) feature. If you upgrade to open-source DefectDojo 3.x (or otherwise move off Pro), the SSO login options are removed, and users who were provisioned through SSO can no longer log in. Their accounts were never given a local password, and the UI and API will not let you set one for them: DefectDojo detects them as SSO accounts and blocks the change.
11+
12+
You do **not** need to delete and recreate these users (which would lose their history, permissions, and object ownership). Instead, give each account a local password on the backend and force a password reset on next login.
13+
14+
See the [SSO section](/admin/sso/) and the [3.0 upgrade notes](/releases/os_upgrading/3.0/#sso-providers-are-available-in-defectdojo-pro-only) for background on SSO being Pro-only.
15+
16+
## Why it happens
17+
18+
Open-source DefectDojo authenticates against Django's local user database only. It decides whether an account is an "SSO user" purely by whether the account has a usable password. SSO-provisioned accounts were created with an *unusable* password, so:
19+
20+
* local login fails (there is no password to check), and
21+
* the **Force password reset** control in the UI and API is blocked, with a message that the user is authorized through SSO.
22+
23+
Setting a real password clears both conditions at once: the account can log in locally, and the forced-reset flag becomes settable.
24+
25+
## The workaround
26+
27+
Run these steps from the Django shell inside the `uwsgi` container:
28+
29+
```bash
30+
docker compose exec -it uwsgi ./manage.py shell
31+
```
32+
33+
### Exmaple for a single user
34+
35+
```python
36+
from dojo.user.models import Dojo_User, UserContactInfo
37+
38+
u = Dojo_User.objects.get(username="alice@example.com")
39+
u.set_password("<temporary-strong-password>") # makes the account a local login account
40+
u.save()
41+
42+
uci, _ = UserContactInfo.objects.get_or_create(user=u)
43+
uci.force_password_reset = True # force a change on next login
44+
uci.save()
45+
```
46+
47+
## What the user does next
48+
49+
Deliver the temporary password to each user out-of-band (email, your team chat, however you normally share secrets). On their next login, DefectDojo redirects them to the **Change Password** page and will not let them go anywhere else until they set their own password. The forced-reset flag clears automatically once they do.
50+
51+
If your instance has the "I forgot my password" flow enabled (`DD_FORGOT_PASSWORD`, on by default) and email configured, users can instead use the **I forgot my password** link on the login page after their account has a usable password, and set a password without needing the temporary one.
52+
53+
## Notes
54+
55+
* **Kubernetes:** run the shell in the Django pod instead, e.g. `kubectl exec -it deploy/defectdojo-django -c uwsgi -- ./manage.py shell` (adjust the deployment and container names to your release).
56+
* Choose a strong throwaway password. With `force_password_reset = True` the user cannot keep it, so it only needs to survive one login.
57+
* Keep at least one working local admin account so you are never locked out.

0 commit comments

Comments
 (0)