OTA-Insight / djangosaml2idp

SAML 2.0 Identity Provider in Django
Apache License 2.0
104 stars 96 forks source link

Example SP/IdP implementation bugs, how to solve them and a question about one #144

Open Amable-Valdes opened 2 years ago

Amable-Valdes commented 2 years ago

Hi everyone!

My team and I are working on a project where we have to use SAML together with django and your example of how to create an IdP and SP is the best we have found on the web. Sadly, we haven't been able to turn it on yet :(

We have managed to fix some problems and we want to present them in this issue for future corrections and to help people with the same issues.

First, we start with the downloaded project (no modifications) and do

sudo docker compose up

This will brings up the containers, but the IdP container fails to start because it doesn't have the djangosaml2idp library in the requirements.txt file.

You just need to add djangosaml2idp==XXXX (or just djangosaml2idp) and this will fix the problem.

Later, with the container already up, I think there would be network problems. localhost is being used in the configuration of both containers and its IP or container name should be used instead, but I have not been able to test it so I do not know very well how this will be. In any case, I then prepare the environment to run it on my machine without docker on localhost so that way the servers can see each other and there will not be configuration problems. Create the superuser with python manage.py createsuperuser on dir /example/idp.

When I try to login with the SP, an error is thrown because the idp_metadata.xml has an expired tag attribute validUntil="2020-12-27T12:41:18Z">. We must update the year and add 1.

https://github.com/OTA-Insight/djangosaml2idp/blob/0b4325782a6fd2c034677b5923041b5df10087ec/example_setup/sp/sp/saml2_config/idp_metadata.xml#L4

Thanks for the help @ericbolo!

Changing the "validUntil" attribute l4 of example_setup/sp/sp/saml2_config/idp_metadata.xml to a future date solved it for me

Originally posted by @ericbolo in https://github.com/OTA-Insight/djangosaml2idp/issues/141#issuecomment-1146566431

After this, we had a problem related to the signature of the response and we had to configure the settings of the two services in this way:

            'sign_response': False,
            'sign_assertion': False,
            'want_authn_requests_signed': False,

to sp.settings.py and idp.settings.py

Originally posted by @MathieuB1 in https://github.com/OTA-Insight/djangosaml2idp/issues/135#issuecomment-1205018189

(Note: Does anyone know why this is? Is it because it doesn't go through HTTPS?)

Finally, and this is the problem that I am not able to solve... we get this error:

Error during SAML authentication
UnknowSystemEntity
http://localhost:8000/saml2/metadata

It corresponds to what was seen in the https://github.com/OTA-Insight/djangosaml2idp/issues/143#issue-1305792053 issue and, honestly, from here I don't know how to continue... this same address is found in the settings of the SP, but I don't know how to configure it...

https://github.com/OTA-Insight/djangosaml2idp/blob/0b4325782a6fd2c034677b5923041b5df10087ec/example_setup/sp/sp/settings.py#L148

I think it's some problem with the XML. We can find the ID that is "http://localhost:9000/idp/metadata/", but of course, that's the ID of the IdP... and I don't know very well where this entityID of the SP comes into play... Does anyone know how to configure it correctly so that it works?

kakulukia commented 1 year ago

Hi @Amable-Valdes did you actually figure this out, because im about to start that same journey and fear it might lead to a dead end because the project seems abandoned. :/

peppelinux commented 1 year ago

I forked this project many years ago and then I made this https://github.com/UniversitaDellaCalabria/uniAuth

it is a community driven project, I'll be happy to answer to your questions and proposal to get the best of it

kakulukia commented 1 year ago

Yes, i saw you mentioning it also in another thread. I might have a look at it and i definitely like the statement that you changed a lot. Because the idea of having another "ghost user" instead of a new required identity token field on the existing user model, made me dislike the project already. The second thing that already haunts me is that metadata xml which got me thinking to explore other methods as well.

My goal is to get SSO working between my one Django app and a Zulip server. SAML is one of the supported methods, but i already got the feeling this might be more complicated than the also supported OpenID. I will probably have another look into the OpenID requirements and maybe will fall back to uniAuth. Lets see what actually works with minimal setup work.

But thanks for offering help already!

peppelinux commented 1 year ago

Well, OpenID Connect means many things. Which flow implicit or auth code? (with or without PKCE)

and which signature alg (considering that none is one of those)

I can say that if you have libraries and middlewares that do all the XML stuff automatically, well SAML2 is simpler then OIDC. OIDC is something more complext because it is divided in several components, some of the OAuth2 inheritance and some of the digital identities experiences. It has different endpoints and much more options, extensions and implementation profiles.

I used to say that OAuth2 and consequentially OIDC, are more frameworks that give you the best if you have to design a scalable infrastructure with delegations features. SAML2 is quite monolitic

I've implemented both SAML2 and OIDC

https://github.com/peppelinux/django-oidc-op https://github.com/italia/Satosa-Saml2Spid https://github.com/italia/spid-cie-oidc-django

if you're looking for something self consistent, easy and well-tested, SAML2 is ready to use out of the box. If you want to do something more smart, scalable and extendible, OAuthw/OIDC is the best choice ever.

before deciding, see the zulip OIDC requirements and specs