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
Related
I am developing web platform which has to have 3 type of users (user, admin, partner companies). For the authentication I am considering to use google Identity platform with multitenancy (probably users in one tenant and admins are in different tenant).
As I understand from documentation, how do we integrate identity platform to our application is to create identity platform provider from console and integrate it into frontend with UI. From front-end, without contacting backend service we can sign up, login and logout by calling firebase SDK and it will give us authentication token. From backend I can check that token with middleware and decide if I agree the user as authenticated or not. Correct me if I am wrong.
Then I can get some metadata of authenticated user from the token, maybe email or name etc. But I want to store user related information on noSQL database as well. For example, if user wants to change his email I need to handle it in backend server, also, I'd like to store users log (access and audit log on somewhere else). In case of, I am using frontend UI and SDK how do log the access and audit information on my backend? also, when changing user's information, do I just write handler function in backend end update user's data with REST API or Admin SDK? what is the best practice over here? Or should I better write my own login and logout function on my backend then call REST API or Admin SDK? is there preferred way? Google is showing me only integration way of authentication from frontend?
BTW, I am deploying backend application on google cloud run, and frontend would be developed in react and should be deployed maybe in firebase or in cloud run as well.
Thanks
As per the Documentation,Yes your understanding is correct to integrate identity platform to the application.
You can store the user related information on a noSQL database like Firestore or Firebase Realtime Database. You can write the Rest API to change or update the user's information in the database.
If you want to write your own login and logout function, I don’t think it is necessary because Firebase Admin SDK provides these features. But if you want to manage user authentication in the backend for specific requirements, you can write your own login and logout function on the backend and use the Firebase Admin SDK.
For access and audit log information you can use Firebase Analytics, Firebase Analytics helps you understand what your users are doing in your app. It has all of the metrics that you’d expect in an app analytics tool combined with user properties like device type, app version, and OS version to give you insight into how users interact with your app.
But finally, the best way would depend on your requirements and use case.
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.
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 creating a service that will include a website, a mobile app, and a web service.
Both the website and mobile app will talk to the web service to interact with the database and any other backend items.
I would like users to be able to log in with other services (such as google, facebook, twitter, etc.)
I have two questions in implementing this:
1.) Should I use OpenID or OAuth? I'm not sure which is better for the situation. I have no need to actually access features from a users account, I just want them to be able to log in with accounts they already have,
2.) Where should I implement the authentication? Do I have to implement it both on the website and on the mobile app, or could I have both talk to the web service and do the authentication there?
Thanks
If you are just doing authentication and not syncing any account details, I think OpenID is the way to go. From a security standpoint, I would say to implement your authentication on the website and on the app and not in the webservice. You want to handle credentials the least amount possible and especially avoid sending the credentials via webservice if not using SSL.