To ease the use of this module, we added a shared task which a wrapper
arount the configured backend and will only call the
create_or_update_contact in a celery task.
Like we did for the malware_detection module, we want helpers allowing
use to instantiate a backend without knowing in the code how to do it,
just importing a module and the marketing service is ready to be used.
We want to reschedule processing task when they are older than 3 days.
A settings is used to modify this delay. The current backend is
instanciated and it is the backend responsability to determine if it
should reschedule it or not.
We want to keep in the database the failed tasks with the reason why
they failed. The idea is to take a decision later on what to do for
tasks reaching a max retries for example.
The base implementation from Mozilla let the backend in charge
of making the introspection (probably to stay generic), but
in LaSuite project we will always perform introspection when
acting as resource server.
To improve domain consistency and "payload" access to other part
of the code, we chose to make the introspection earlier in the
authentication process.
Note the introspection payload, does not contain much information,
in our current implementation we need it to contain at least the
user's `sub``.
Currently, only `GET` method as considered as refreshable url as it could
be weird to return a redirect response for other kind of HTTP methods.
On our side, we assume to be always in a XHR context so we don't want
to be bothered by redirects and in case the session has expired
we returned a 401 status. So we can safely ignore the request HTTP method
to check if the url is refreshable.
When a user's sub is defined, we don't want to allow any update
because it would break to many related data.
This fix is required since we changed the way user data is
updated in 7409ea8c6e
User model `sub` field may be nullable in certain projects, we make sure
the user is correctly updated in this case by using the User.id during
update.
Example of User.sub being nullable: in case of multi authentication
backends.
Example of project using a nullable User.sub: docs (lasuite).
Fixes session persistence issues with OIDC flows, particularly when
using a Redis backend, and strengthens OIDC security.
Key changes include:
**Session Persistence (Redis)**:
- Forcing immediate session saving (`request.session.modified = True`
and `request.session.save()`) in OIDC logout and authentication
views. This is crucial for cache-based session backends like Redis
to ensure OIDC states are persisted before redirects.
- Simplified session creation by calling `session.create()` BEFORE
`super().get()` instead of after (more logical flow).
- Removed unnecessary state merging logic that was over-engineering.
**Security Enhancements**:
- Added CSRF protection by validating the state parameter even during
silent login failures (error=login_required).
- State is now preserved (not deleted) on error=login_required to
allow the SSO provider to send a subsequent callback with the
authorization code using the same state.
- Enforced strict state parameter validation during silent login
failures (`error=login_required`), raising `SuspiciousOperation`
if state is missing or invalid.
- Graceful handling of logout callbacks without state parameter to
accommodate SSO providers sending preflight requests.
**Testing**:
- Added comprehensive tests for silent login security validation
(invalid state, missing state, valid state).
- Updated test expectations to match new behavior where states are
preserved during silent login failures.
- Added test for logout callback without state parameter.
These changes enhance both the reliability and security of OIDC
login and logout flows, especially in distributed environments
using Redis for session management.
This endpoint can be called by the IdP to kill all the user
sessions.
In order to allow to kill only one session, we need to store the
session ID when login from IdP...
We want to monitor the usage of a scope throttle. We want to know when a
throttle fails in order to determine if the rate is accurate or not.
To allow custom monitoring, a callback can be use. For example you can
capture a message in sentry instead logging a warning.
We added a management command to force to launch pending analysis. This
management command can be run periodically in a cron in order to have a
pending analysis blocked and never run.
For the JCOP backend we need to limit the number of simultaneous files
analysis. The number of simultaneous analysis must be configurable, by
default we limit it to 15.
To achieve this, we store in a table the pending analysis and a new
analysis is triggered at the end of a previous one.
This supports use of environment variables that either reference
a value or a path to file containing the value. This is useful for
secrets, to avoid the secret to be in a world-readable environment
file.
Once an analyse started, we were wiating 30 seconds to try having a
first time the result and then the retry delay was always equal to 30
seconds between every retries. JCOP ask us to reduce this waiting time
to few seconds, an analyse job should start quickly and depending the
file size the result will be available in few seconds.
The claims validation was making an error when the user is inactive
making debug session quite complex. This does not change the behavior
but add more explicit logs.
The client was always requesting for a JWT introspection reponse even if
we wanted a JSON. This commit fixes the issue by hard linking the
resource server client to the resource server backend we use.
When using introspection with a `token_introspection` claim, we don't
need to check the issuer twice (because the `iss` inside the
`token_introspection` is not mandatory and the issuer is already check
in the containing JWT).
This provides a way to to refresh the OIDC access token.
The OIDC token will be used to request data to a resource server.
This code is highly related to
mozilla/mozilla-django-oidc#377
The refresh token is encrypted in the session.
This provides:
- the OIDC authentication backend we use on our project to allow
connection via OIDC
- the OIDC authentication backend for URLs to expose via Resource
Server
