-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update documentation #18
base: main
Are you sure you want to change the base?
Conversation
@@ -13,19 +13,25 @@ It can be used to setup a Single Sign On using an identity provider (Keycloak, e | |||
|
|||
**Warning** : this library has not been audited. However, we are based on [pyoidc](https://github.com/CZ-NIC/pyoidc/) which we believe is a sane OIDC implementation. | |||
|
|||
We tried to make OpenID Connect (OIDC) configuration as easy and secure as possible. However | |||
everything can be customized and we tried to take into account every use case in the library design. | |||
If you are not satisfied with the default configuration, take a look at the setting wiki page TODO. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: a TODO here
- Easy integration with the [Django permission system](https://django-pyoidc.readthedocs.io/en/latest/how-to.html#use-the-django-permission-system-with-oidc) | ||
- Highly customizable design that should suit most needs | ||
- Back-channel Logout | ||
- Support back-channel logout | ||
- Support service accounts (accounts for machine-to-machine uses) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in features, add the
Bearer
authentication support fordjango-rest-framework
integration (single provider with fixed namedrf
)
@@ -69,6 +75,17 @@ MIDDLEWARE = [ | |||
] | |||
``` | |||
|
|||
**If you use `django-rest-framework`** you can configure `DEFAULT_AUTHENTICATION_CLASSES` to use `django_pyoidc.drf.authentication.OIDCBearerAuthentication` : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part with DRF should be moved AFTER the classical part. Because this integration is special and require 2 settings:
- this OIDCBearerAuthentication stuff
- a 'drf' record in DJANGO_PYOIDC
Then we should explain several things: - this drf record could contain the same thing as the previous one (like, the same client_id and client secret for example), but usually t should not
- when using OIDC on a REST API we have different needs than when using it on a classical web app, here we do not want to redirect users on login pages, or to manage logout, so the API mode is different, here we are receiving OIDC Bearer tokens -- access tokens-- (generated from other clients of the SSO) and the task is mainly to check that this token is valid and extract the user from it.
- the library can only use one provider in API mode (as you can only register one 'drf' key in DJANGO_PYOIDC
- usually you application should request a different client_id for the apimode (like a my-app-full client id for a confidential classical OIDC client and a my-app-api client id for a bearer-only OIDC client in Keycloak). But if you have only one client_id it's OK to simply make a copy for the settings.
- some defaults will differ on the
drf
record, for example the access token will always be verified by using introspection calls to the SSO server (which validates the token and extract the token claims).
==> So, a chapter on that subject seems legit.
No description provided.