1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
FAQ
===
**Why can't SAML be implemented as an Django Authentication Backend?**
well SAML authentication is not that simple as a set of credentials you can
put on a login form and get a response back. Actually the user password is
not given to the service provider at all. This is by design. You have to
delegate the task of authentication to the IdP and then get an asynchronous
response from it.
Given said that, djangosaml2 does use a Django Authentication Backend to
transform the SAML assertion about the user into a Django user object.
**Why not put everything in a Django middleware class and make our lifes
easier?**
Yes, that was an option I did evaluate but at the end the current design
won. In my opinion putting this logic into a middleware has the advantage
of making it easier to configure but has a couple of disadvantages: first,
the middleware would need to check if the request path is one of the
SAML endpoints for every request. Second, it would be too magical and in
case of a problem, much harder to debug.
**Why not call this package django-saml as many other Django applications?**
Following that pattern then I should import the application with
import saml but unfortunately that module name is already used in pysaml2.
**saml2.response.UnsolicitedResponse: Unsolicited response**
If you are experiencing issues with unsolicited requests this is due to the fact that
cookies not being sent when using the HTTP-POST binding. You have to configure samesite
djangosaml2 middleware (see setup documentation) and also consider upgrading
to Django 3.1 or higher.
If you can't do that, configure "allow_unsolicited" to True in pySAML2 configuration.
|
