I'm trying to setup OpenWisp Django-IPAM with WebUI authentication via LDAP. We have an OpenLDAP server within our network and I am looking to use a simple LDAP lookup to check for a valid user object for login.
I see that the API's generics.py file has an authentication_classes section, which then contains SessionAuthentication and BasicAuthentication.
Is this the same mechanism that handles the authentication for the Web UI? Is there a way to configure OpenWisp Django-IPAM to use something like Django-Auth-LDAP for authentication when logging into the web interface?
the authentication of the web UI of OpenWISP Django-IPAM works like default authentication of other django projects. So to use LDAP authentication at the web UI, you simply need to edit your settings.py file to contain the setups as shown here.
Something like django-auth-ldap will help, but users will have to start a session by authenticating against the django authentication backends before being able to use the API (eg: login via the admin or provide another login view).
After a successful LDAP authentication using the method mentioned above, a new local user will be created, which maps the LDAP user.
I'm not sure if LDAP authentication requires a redirect to another application (like oauth2 or SAML) or if username and password are just redirected behind the scenes, in the latter case, BasicAuthentication should work, I just look at its code and it looks like it respect the standard django authentication framework, which supports multiple authentication backends (the LDAP backend is provided by the third party app suggested above).
A sidenote: we're moving the development of django-ipam to openwisp-ipam, It's mostly the same. I suggest you to upgrade.
Related
I am trying to implement a Authentication Server using Django which will be used only for user authentication.
We have multiple services hosted on different subdomains like one.service.com, two.service.com, three.service.com etc. And we don't want our users to memorize/use different login credentials for each service. We want a system where user can authenticate themselves through the auth server and can access all the services of the subdomains.
Just think about Google or Microsoft, we just need one login credential and then we can access all of their services.
How can I implement this type of system for our services using Django ??
Note: We are primarily using JWTAuthentication for our servers.
Use SSO with SimpleJWT is the best and easier approach.
in Django settings set SESSION_COOKIE_DOMAIN to all subdomains use cookies and save tokens on that
check links for detail
Looking for insight into a use case in Django REST Framework (DRF) and supporting customer defined authentication method: TokenAuthentication (by default), SAML 2.0 SSO, OAuth2 federated login. The method is set per customer account. I know I would enable SAML 2.0 support for all users in DRF, but I don't see how to have each user account in our software use their own Auth engine, method and settings. DRF seems to want an all or nothing configuration.
I'm aware of both django-saml2-auth plugin and this StackOverflow question SAML SSO Authentication with Django REST Framework
django-saml2-auth is a great plugin and is likely involved in the solution, but I see no examples of how to have multiple different authentication methods on a per account in your app.
More details:
I want to allow a per customer method of supporting account settings enabling the option to select one of multiple authenticate methods such as TokenAuthentication (by default), or SSO and providing SAML 2.0 or Oauth2 setting. Every account could select from the enabled methods. DRF seems to expect a single authentication provider to be enabled. Not grokking how to do this in this framework yet. Currently using TokenAuthentication as the default authentication system. TokenAuthentication would remain the default provider for most accounts. I need to be able to allow more sophisticated enterprise customers to switch authentication methodology. That's the challenge. Adding SAML2 is simple. Using OAuth2 is simple. Allow any of them to be chosen by accounts, with each account having their own authentication workflow. This is quite a different requirement than the use case that django-saml2-auth solves. That plugin may be involved in the solution, but the limitation here seems to be the model DRF uses to define the authentication provider. I've scanned the DRF, and django-saml2-auth docs, code and examples. Nothing I've seen anticipates this.
My current working theory is that I could make it possible with a little creative thinking. Perhaps there's a different URL mapping that utilizes different login/authentication method. The logged in data token that must be provided in subsequent calls could have a custom validation method that works with all supported protocols without large new blocks of code. So my instinct is the problem is mapping the login process to something that is not universal and requires some type of pre-fetching of account configuration. My proposed solution there is in the login URL for the enterprise cases. But still DRF seems to still be lacking a method for defining the authentication process per each account. Say I use SAML2 through Okta, You use OneLogin, Another person uses an OAuth2 provider, and most customers use the default native TokenAuthentication. We're all users in the same DRF app. But there isn't a way I see to define authentication engine based on account.
I know there is a possible brute force method of customizing the method being invoked to perform the login action that could be non-standard, query to configuration for a customer, then use either native or a federated identity provider. However, I'm hoping there are more DRF grokking folks that know of other strategies to enable this functionality.
I understand that there is a chicken and egg syndrome in that until you know something about the customer making the request you won't know what their configuration is. We will most likely need to support a different login URL for enterprise customers who enable SAML. That way you could load the customer's configuration. Perhaps we would do something like use a URL like so: www.myproduct/login/the_customer_company. Being new to Django REST Framework I am not super clear how to wire up different methods of authentication within the Django settings.py or urls.py? The default new user configuration would remain TokenAuthentication based but on request a customer could configure SAML and use a different URL including the company name. Hopefully my question is clear. I see how to configure DRF to use SAML SSO instead of TokenAuthentication, but I want to allow customer configured settings.
DRF and the django-saml2-auth approaches seem to be "all or nothing" and provide a single authentication provider mapping for the application. I would love to be wrong about that limitation!
One option to achieve this would be to use an Identity Provider (IdP) that can act as an identity broker, for example Keycloak. Configured this way, your Django app would be configured for SAML authentication with the single IdP. The IdP can then be configured for whatever upstream SAML / OAuth identity providers it supports depending on the customer requirements.
How you get the users to the right upstream identity provider and still have a good user experience would have a few options. The two most obvious ones would be to either configure a custom URL for each user group, and have that URL redirect to the correct IdP landing page when logging on. Alternately you could perhaps have a login page on the Django site that asked for their login / email address (without password), and when they entered that it looked up the IdP URL associated with that user and then to sent them to the right place.
While this is not a Django module / code solution for the problem, it simplifies the authentication on the Django side, and decouples the authentication to an external service specifically designed to do auth, providing the app with more flexibility (and probably more security).
I am trying to configure Jupyterhub using these instructions.
However, instead of Github authentication I would like to use either
1) Rstudio server like authentication where credentials are the same as linux user ones, or
2) I would like to integrate it with my Django app where the users can login through the Django app login credentials. Something like Coursera has done here: https://hub.coursera-notebooks.org/hub/login (maybe with a different framework)
How can i do it?
Rstudio server like authentication where credentials are the same as linux user ones
This is the default behavior of JupyterHub, which uses the PAMAuthenticator to login with existing system usernames and passwords.
I would like to integrate it with my Django app where the users can login through the Django app login credentials.
This would mean writing an Authenticator. If your django app is an OAuth provider, you can use the oauthenticator package, which implements logging in with OAuth2. You can write your own subclass of the base OAuthenticator that talks to your application, using the various implementations in that repo as an example.
If your application is not an OAuthenticator, you may need to start from the base Authenticator class and define .authenticate() method.
If you proxy JupyterHub behind your django app, the simplest way to authenticate is to check a header that the proxy sets for authenticated users (and make sure that only authenticated requests arrive at the Hub). The RemoteUserAuthenticator is one such example that relies on the REMOTE_USER header set by Apache during login.
I am struggling to set up for authentication with apache and mod wsgi in Django.
I have a big question mark. It is fundamental question for me before beginning to use basic or digest authentication in apache really.
Why do you need basic or digest authentication in Django in the first place? Django has own authentication system. You can manage permissions with user and permission itself in Django.
I think there is a clear case that you need this apache authentication. I don't think people put effort to explains how to set up for using apache authentication with mod wsgi in Django manual if you don't need it at all.
In Django manual,
for example, you could:
1.Serve static/media files directly from Apache only to authenticated users.
2.Authenticate access to a Subversion repository against Django users with a certain permission.
3.Allow certain users to connect to a WebDAV share created with mod_dav.
Even after reading this setence and manual repeatly, I can't come up with some situation which need to select using apache authentication for the best option.
why do you need to use apache authentication in Django or in Which special situation do you need it?
Both apache and django authentication are different. First one is web server level and next is application level.
One thing, there will be some urls accessible both login and without login.This type of auth cannot be set in apache(from my knowledge).You can do it in inside django.
I have an application running on Django and a bugtracker (redmine).
I'd like to have the same accounts for my users on both applications.
So I decided to install an LDAP on my server and plug my apps on.
In the mean time, in the future I'd like to give my users the ability to attach their accounts with OAuth, OpenID (like Google, Facebook, ...).
Is LDAP still a good idea for this purpose ?
Is it something usual and how easy ?
With a unique LDAP you get resolved the duplicated account problem but you dont get the SSO or SLO functionality. The Ldap plugin of Django and Redmine are easy to configure and are well documented. Same happens with the OpenLdap server.
If you are thinking in the future, I think a nice solution would be to set a SAML enviroment.
Use simplesamlphp to build a IdP and enable the authentication sources that you want: Facebook, Gmail, Ldap, etc
Use djangosaml2 to add SAML support to django and connect it with the IdP
Use this plugin to add SAML support to Redmine and connect it with the IdP
At the end you get a system based on SAML, a protocol that actually are using Google and other big companies.