Closed steverecio closed 4 years ago
Have you tried integrating django-saml2-auth with Dj-Rest-Auth?
My personal opinion is that auth is very broad category so rather than having one opinionated package that solves every related problem, it's better to have separate specific packages for each concern.
E.g
Dj-Rest-Auth
Dj-Rest-Auth
django-prbac
django-saml2-auth
django oauth toolkit
I'm open to hear other opinions on this.
Yeah I've looked into django-saml2-auth and python3-saml. I tend to agree that this package should remain pretty minimal but I like it as a base package that could have additional plugins, similar to how django-otp has additional compatible plugins like django-otp-yubikey.
It would be nice to be able to install this package and add plugins as needed (without having to figure out the logic to integrate completely separate packages).
I'm using djangosaml2 and whatever the SAML2 SP implementation would be I think that yes, the packages should be apart.
AFAIK there would be the possibility to put a django signal, that triggers after a user have been logged in, that would create a token for him.
How then the token would be passed/shared between different endpoint would be something out of scope here, I think but I'm quite new in simplejwt and I'm curious about your approach regarding this kind of stuffs
Just about every major identity management service now supports OpenID Connect (extension on OAuth2.0). I highly recommend going that route instead of SAML.
On the React side, I recommend react-oidc and on the server side this package will eventually provide some drop in OIDC-friendly authentication classes for DRF.
Yes, the only problem Is that afaik the response type would be implicit and the access token will be sent through a http redirect, in the URL.
This means that It Will Be printed in all the webserver and proxy involved between the endpoints.
I don't like this "convention" and still Wondering about security with those JS libraries
access token will be sent through a http redirect
That's not true. In the "Auth code flow", the auth request receives a redirect, not the token request. Also, it's not a just a small convention created by libraries - it's an official spec written by Oauth 2.0/ OpenID Connect. I can't think of a more secure option for SSO or federated login.
I'm going to close this ticket since this package will be supporting OIDC instead of SAML.
Yes, in fact I say "implicit" flow. Auth code is the only secure way to do that but I'm wondering about the real implementations in the libraries. Either the RP should expose it's jwks and take the provider metadata where jwks urls resides, to check and verify jwt signatures.
I just want to put a special attention about the real security level in each implementations. Hope to test vue.js oidc-client asap to follow and check these things
django-allauth[saml] supports SAML, wrapping those functions should not be difficult. I will give it a go and see if I can get it running fast!
I actually managed to integrate SAML2,9 support via django-allauth[saml]... but the code is rather ugly as it was constrained by the interfaces and design of django-allauth, dj-rest-api and saml2.
don't forget this https://github.com/IdentityPython/djangosaml2
take a look at this if you are interested: I am going to cleanup the the code today, add tests, make sure everything works, and publish it on pypi. Hopefully this week. https://github.com/oussjarrousse/dj-rest-auth-saml
Any chance this project will support single sign on?