- Groups can also be fetched locally: this is enabled automatically if the `hsh` app is available, skipping multiple software layers for additional security
- Suppresses direct permission assignment (`django.contrib.auth``User`<->`Permission`), use groups instead
#### Minimal SSO Intro:
-[SSO](https://lmddgtfy.net/?q=SSO): Single Sign On
- SLO: Single Log Out
- SP: Service Provider (your web app)
- IdP: Identity Provider (server with some dreadful software like Shibboleth)
- Metadata/Meta: an XML that describes SP or IdP (or some other entity)
- SAML/SAML2: It's just another XML-based enterprise-grade standard that will make you cry blood and shit bricks
- IDP: Identity Provider (e.g. Shibboleth)
- Metadata: an XML that describes SP or IDP (or some other relying party)
- SAML/SAML2: yet another XML-based enterprise-grade standard that will make you cry blood
#### Necessary Stuff
...
...
@@ -21,7 +30,7 @@
#### Development Setup
- Should work with zero additional configuration.
- You can use `localhost:8000/dev/` _(might change depending on your configuration)_ to access the dev view with all its helper features.
- You can use `localhost:8000/dev/` _(might change depending on your url configuration)_ to access the dev view with all its helper features.
#### Advanced development setup
If you are not sure whether you need it: you don't need it.
...
...
@@ -49,19 +58,19 @@ There are some apps like `django.contrib.admin` or `wagtail` that will simply ig
- Optional argument `already_authenticated_403=True` is used to avoid redirect loops (e.g. caused by `django.contrib.admin`). You can also use `already_authenticated_redirect="url-name"`.
- Adjust the path if needed
- Optional argument `already_authenticated_403=True` is used to avoid redirect loops (e.g. those caused by `django.contrib.admin`). You can also use `already_authenticated_redirect="url-name"`.
#### Regarding Logging Out
After logging out locally, user will be redirected to one of the following (with this priority):
After logging out locally, user will be redirected to one of the following (in this order):
-`?next=` GET value (Note: instead of `next` use use `django.contrib.auth.REDIRECT_FIELD_NAME`)
- Default: redirect to the view that asks users what to do next. Don't forget to override template `ssoauth/logged_out_locally.html`
- Default: redirect to the view that asks users what to do next. You might want to override template `ssoauth/logged_out_locally.html`
#### Advanced Logging Out and SLO
...
...
@@ -69,18 +78,18 @@ If unsure, ignore this section.
**SLO**: SLO/SLS is disabled by default. If you want to try your luck with SLO you should add to your project settings `SP_SLS_ENABLED = True`
Currently only IdP-initiated SLO is supported by this app. The only supported binding type is HTTP-Redirect due to the limitations of the underlying library used.
Currently only IDP-initiated SLO is supported by this app. The only supported binding type is HTTP-Redirect due to the limitations of the underlying library used.
For SLO with HTTP-Redirect to work, the SLS page must be included as `<iframe>`. Your server and/or browser might restrict such behavior. Start with setting `SP_SLS_X_FRAME_OPTIONS` (check `ssoauth.app_settings.defaults`).
If you have `nginx` serving pages to users, you might need to configure `x-frame-options` for the SLS view (Only the SLS view, nowhere else!). Additionally you might need to configure CSP on the web server on the IdP side. Anyways it will most likely be a lot of [fun](https://duckduckgo.com/?q=dwarf+fortress+fun) for you.
If you have `nginx` serving pages to users, you might need to configure `x-frame-options` for the SLS view (Only the SLS view, nowhere else!). Additionally you might need to configure CSP on the web server on the IDP side. Anyways it will most likely be a lot of [fun](https://duckduckgo.com/?q=dwarf+fortress+fun) for you.
#### Groups and Permissions
With `ssoauth` the only way to assign permissions is with groups:
- when user logs in, `ssoauth` receives group names from the IDP
- if your project has `django.contrib.admin``Groups` with exactly the same names, as received from the IDP, these groups are assigned to the user.
- all other groups and permissions are automatically removed from the user (so it's not possible to "patch" what IDP says with some extra rules in the project)
- when user logs in, `ssoauth` receives group names from the IDP, or fetches them from the `hsh` app if it's present
- if your project has local groups (`django.contrib.auth``Group`) with exactly the same names, these groups are assigned to the user
- all other groups and permissions are removed from the user for security reasons (better don't workaround this behaviour in your project)
You can predefine some groups in project settings (see `ssoauth` default config for details). These predefined groups will be created automatically (when migrating). For example, a superuser group:
...
...
@@ -95,12 +104,12 @@ PREDEFINED_GROUPS = {
This example might be incomplete. See `ssoauth.app_settings.defaults` for additional info
```python
""" settings/prod.py """
""" settings.py """
fromdjangoimporturls
SP_HOST="foobar.it.hs-hannover.de"# FQDN of your SP
IDP_META_URL="https://idp.hs-hannover.de/idp/shibboleth"# production
IDP_LOGOUT_URL="https://idp.it.hs-hannover.de/idp/profile/Logout"# web page for IdP logout (might initiate SLO)
IDP_LOGOUT_URL="https://idp.it.hs-hannover.de/idp/profile/Logout"# web page for IDP logout (might initiate SLO)