We make the full name mandatory and add a field to
allow user to store personnal notes on the contact.
This also make the "base" contact not mandatory because
user may want to create new contacts out of the blue.
To improve readability and code sharing we group all
APIs into the same "api" module for each application.
Next submodules might be "scim",
"resource_server_scim", ...
The only shared module is the "permissions" one for now.
When updating an Organization in the Django admin, the validator
falsly raises a "duplicated" error because it does not exclude the
current object from the database lookup.
We don't want every Service Provider to be able to request
every endpoint if those are not implementing a filtering on
the data returned. To prevent any data leak we enforce the
developers to manually "whitelist" each endpoint and add
the proper filtering when needed.
When we use the feature to get Organization registration
number, the claim contains this value and it does not
match with any user field.
I switched to a whitelist instead of a blacklist (and two
loops, with an if condition on each)
This commit removes the slug field from
the database, now the nullable migration is in
production and the field has been remove from
the code deployed.
FIXES#505
This allows, on a per user basis, the display of
features.
The main goal here is to allow Team admin or owner
to see the management views.
We also added the same for the two other features
(mailboxes and contacts)
This will be improved later if needed :)
After some reflexion, the use of a slug field raises to many
problems without being really needed.
One problem is the slug is made from the group name, but we
don't have unicity on this, so a user might be blocked without
any clue.
We also want to allow group names to be reused (which is already
allowed except for the automatic slug).
The unique ID that will be shared with Service Providers will be
the PK/UUID.
We introduce the Organization model has a "hat" for all
users and team.
Each User must have a "default" organization.
Each Team must have an organization.
When a User creates a new Team, the team is linked to their
default Organization.
For now the Organization should not be visible to end users
this is a purely technical aspect as it.
The models are also adding a permission to allow User to edit
an Organization, but for now there are no endpoints for that.
Next steps:
- Add an Organization to each User and Team on all environments
to mark Organization as mandatory in database.
- Add scope to Organization to list the Service Provider list
allowed for a User in an Organization.
- Add endpoints + frontend to manage Organization's scopes
Some OIDC identity providers may provide a random value in the "sub"
field instead of an identifying ID. In this case, it may be a good
idea to fallback to matching the user on its email field.
Tests are missing, let's ship it, I'll open an issue.
Without such protection, the whole app would crash if the resource server is
not configured. The fallback backend would return an appropriate error to
the client if the resource server is improperly configured.
Overload mozilla-django-oidc class to support an authentication method
with the resource server backend.
This enables any route of the API to be called with an access token
issued by Agent Connect.
Why:
Many services in La Suite rely on Agent Connect to authenticate their users.
Delegating authentication to Agent Connect is highly beneficial. With a central
party (Agent Connect) handling user authentication, our services can seamlessly
communicate with each other. Our backend must be able to receive and verify
access tokens issued by Agent Connect.
Additionally, it should ensure that the resource owner has granted permission
for our data to the service provider transmitting the access token.
How:
Our backend needs to verify access tokens by introspecting them. This involves
requesting the Authorization Server to validate the access token received in
the authentication header. The Authorization Server validates the token's
integrity, provides authentication and authorization information about
the user currently logged into the service provider requesting data from
the resource server.
The data returned by the Authorization Server to the resource server
is encrypted and signed. To encrypt the introspection token, the Authorization
Server retrieves the resource server's public key from
the new ‘/jwks’ endpoint.
Encryption parameters, such as algorithm and encoding, are configured on
the resource server. Ensure that these parameters match between
the Authorization Server and the resource server.
The resource server verifies the token signature using the Authorization
Server's public key, exposed through its `/jwks` endpoint. Make sure
the signature algorithms match between both servers. Finally, introspection
token claims are verified to adhere to good practices for handling JWTs,
including checks on issuer, audience, and expiration time.
The introspection token contains a subject (`sub`). The resource server uses
this subject to retrieve the requested database user, compatible
with both pairwise and public subjects.
Important:
Agent Connect does not follow RFC 7662 but uses a draft RFC that adds security
(signing/encryption) to the initial specification. Refer to the "References"
section for more information.
References:
The initial RFC describing token introspection is RFC 7662 "OAuth 2.0 Token
Introspection". However, this RFC specifies that the introspection
response is a plain JSON object.
In eGovernment applications, our resource server requires stronger assurance
that the Authorization Server issued the token introspection response.
France Connect's team implemented a stronger version of the spec, returning
a signed and encrypted token introspection response. This version is still
a draft, available under:
"draft-ietf-oauth-jwt-introspection-response".
In OAuth 2.0, the Authorization Server is equivalent to the OIDC provider.
The Authorization Server exposes endpoints for token introspection and JWKS.
I’ve created a client to easily interact with the Authorization Server,
while doing the token introspection in our resource server.
Token introspection will be explained in upcoming commits.
The current OIDC library used in the project doesn’t offer token introspection,
leading to redundancy in the code handling some OIDC/OAuth2 flows.
This overlap makes the code bulky. My goal is to quickly deliver a working
PoC for the resource server, with plans to refactor in the longer run.
Please feel free to provide feedback on the class design.
Introduce a new endpoint, /jwks, which returns a JSON Web Key Set (JWKS).
This set of public crypto keys will be used by external parties to encrypt
data intended for our backend. In the context of the resource server, this key
will be used by the authorization server to encrypt the introspection response.
The current implementation exposes a single public key, with the private key
configurable in the app settings. The private key is represented as a string.
For enhanced security, we might prefer to store this data in a .pem file
excluded from version control.
A few parameters for this key, such as its type and encoding, are configurable
in the settings.
A critique of the current design is its lack of extensibility.
If we decide to offer more than one encryption method, this view will require
refactoring.
Additionally, the current implementation is tightly coupled with joserfc.
This lays the foundation for further improvements.
Please note, this endpoint only public components of the key, there is no
chance for any secret leaking.
By making this email address invariant, we remove failures due to FactoryBoy's
random address being considered as a match to our test query
(and hence returning unexpected number of matches).
Pylint 3.2.0 introduced a new check `possibly-used-before-assignment`, which
ensures variables are defined regardless of conditional statements.
Some if/else branches were missing defaults. These have been fixed.
The default Logout view provided by Mozilla Django OIDC is not suitable
for the Agent Connect Logout flow.
Previously, when a user was logging-out, only its Django session was ended.
However, its session in the OIDC provider was still active.
Agent Connect implements a 'session/end' endpoint, that allows services to
end user session when they logout.
Agent Connect logout triggers cannot work with the default views implemented
by the dependency Mozilla Django OIDC. In their implementation, they decided
to end Django Session before redirecting to the OIDC provider.
The Django session needs to be retained during the logout process.
An OIDC state is saved to the request session, pass to Agent Connect Logout
endpoint, and verified when the backend receives the Logout callback from Agent
Connect. It seems to follow OIDC specifications.
If for any reason, the Logout flow cannot be initiated with Agent Connect,
(missing ID token in cache, unauthenticated user, etc), the user is redirected
to the final URL, without interacting with Agent Connect.
Prepare adding advanced authentication features. Create a dedicated
authentication Python package within the core app.
This code organization will be more extensible.
