Want to know some best ways how to achieve Single Sign On for cross platform django projects. I have a monolithic application which is getting converted to Multi Tenant system. The core part of the monolithic application is converted and divided into micro services but there are portions and part of monolithic application which will take time to get converted.
So currently I cannot remove monolithic application hence needed a way to implement Single Sign On for these two application running in parallel.
Monolithic Stack:- Python, Django1.10, mysql,
MultiTenantSystem Stack :- Python, Django2.1, Postgres
Some references :-
https://github.com/aldryn/django-simple-sso
https://medium.com/#MicroPyramid/django-single-sign-on-sso-to-multiple-applications-64637da015f4
I would recommand working with OpenID Connect or SAML.
At work we are currently using django-oidc-provider with some business customization of course. This allows you to serve a single sign-on across multiple platforms.
The way it works is having a central authentication server that handles all logins and redirects the user to clients, which then again, exchange for an access-token and/or id-token. How to implement the access token from here varies, but for your sake the back-end middleware would fetch user info from the authentication server, and give the user a session cookie for your service related to the user info just fetched.
Or even better, use id-tokens. That way you dont need to ask for user info from the authentication server as these are JWT and can be verified by cryptography.
For more info you can checkout the OpenID website.
Related
We r finally taking a leap into writing a mobile application for some of our platforms core functionality.
After spending some time - narrowed down that it is a HTML 5 application, CSS and Apache Phone gap to support different platforms mainly IOS and Android
We are writing WCF based REST services and have a question about securing the web service calls - specially ones for new user creation and login.
How can we ensure that the web service call to create a new user account or subsequently to log into the app is genuinely originating from a mobile device and not via a brute attack or someone trying to execute a service if they do discover the URL? Is there some kind of device identifier that we can depend on as part of the request (or something we embed into the app) etc or are there other more reliable techniques.
Any help would be appreciated.
Regards
Sid
Good question: I use the device plugin to get the device uuid and then hash it with the user email and the timestamp of the registration to create a key. One way hashing is your friend in this scenario. Keep all of your communication on https secure socket layer and create keys based on the UUID and you should be able to solve this problem.
I'm designing an architecture where the web interface is a client (developed using a front-end js framework) and all requests are routed to several webservices.
All communication will happen using standard HTTP responses and JSON entities.
Now I'm facing the authentication mechanism.
My service will, of course, have several users, and I need to restrict access to users' resources.
Users will 1) signin to the web client (/admin) and then 2) the client-side js will perform several AJAX requests on webservices on user behalf.
Should I create a persistent session between the client/server and then pass some reference alongside each request or authenticate each single request using a stateless approach? How could I authenticate the web-client requests for the current user without adding too much overhead or complexity to my system?
I'm looking at passport-local and passport-localapikey but it's not very clear to me if I should authorize my client or the user itself (meaning should I have only one pair of credentials for all users when performing web-service request or one pair per user?)
A simple example (explained I don't need to copy-paste code) would be very appreciated. At this stage I'd prefer the solution introducing less complexity but granting a good security in order to be able to set it up very quickly.
PS. I could also take into account creating a distinct service handling authentication in order to create a common API to be shared between client and server, but that seems a bit over-engineering to me.
Thanks,
If you're already using Express as a framework for Node.js, you can use it's built in session handling. It is capable of using any sort of session store including memory, redis, mongo, etc.
There's a good example here: http://blog.modulus.io/nodejs-and-express-sessions
I have a SharePoint server running on my network and I am trying to build an app in Delphi which allows me to access the various SharePoint Web Services hosted there.
Running my app on the same network as the SharePoint server works fine, however, when I attempt to run it on a VM which is not part of the same Domain I can't get authenticated. I was looking for some advice as to how I should be handling authentication for this type of scenario, more specifically, should I be prompting the user for their credentials or is there some built in security model I can use for this?
Ideally I would like to try avoid dealing with Usernames & Passwords in my app and let the OS handle that sort of thing, however, at the moment I can't seem to see any other way around this.
After some investigation, for my particular scenario I decided that the best approach would be to use WinINet. I chose this approach over Indy because after some thorough investigation I found Indy did have some bugs & also it didn't have all the authentication handling we needed built in.
WinINet supports prompting for credentials & automatically authenticating across the wire. See Handling Authentication.
We don't exactly comply with the XML-RPC spec, but the concepts are nearly identical. A client comes in over HTTP/HTTPS with an XML payload. We respond with an XML payload answering the request. This is primarily machine to machine, so no human to type a username/password. Our construct runs within apache tomcat. We would like to authenticate the request and since not every service is available to every client, we need to authorize the request as well. We have both subscription and per use charging models so it is necessary to log everything.
What would you recommend for both server and client?
HTTP BASIC/DIGEST works fine for most machine to machine tasks, and it handled by the server so your API is unaffected.
It doesn't work as well for interactive uses because it's difficult to "log out" the user without closing the browser.
Otherwise you'll most likely need to alter your APIs to include authentication information and have your methods authenticate that within your code.
Or you could use the classic "login", set a cookie, keep a session technique.
But, frankly, for machine to machine work, HTTP BASIC is the easiest.
edit, regarding comments.
HTTP BASIC is simply a protocol used to present the artifacts necessary for authentication, and it works well for machine to machine web services.
HOW IT IS IMPLEMENTED is dependent on you and your application. Using Java, you can use container authentication and that will provide authentication as well as role mapping. The user -> role mapping is handled in either a data file or database. The URLs protected, and what roles are valid for each URL, is managed by web.xml.
If you continue to add different roles to different URLs, then, yes, you'll need to redeploy that application.
However, if you're just adding new users, then you simply update your file or database. And if you're adding new logic, and this new URLs, then you have to redeploy anyway. If you have a ROLE structure with a fine enough granularity, you won't have to be messing with the web.xml until you actually add new methods. For example you could, at the extreme, create a role per method, and assign them individually to users. Most don't need to go that far.
If you don't want to use container authentication, then write a Servlet Filter to implement your vision of mapping user and roles to URLs. You can still use the HTTP BASIC protocol for your clients, even if you implement your own facility.
If you're looking for an overall generic Java security framework, I defer to google -- there are several, I've not used any of them. I've had good luck with container authentication and writing our own.
#Will
I second the HTTP Basic suggestion, and can testify that it integrates fairly well with Spring Security, which I implemented on top of a legacy application that rolled its own DB-based authentication/authorization logic.
How would you implement a system with the following objectives:
Manage authentication,
authorization for
hundreds of thousands of existing users currently tightly integrated with a 3rd party vendor's application (We want to bust these users out into something we manage and make our apps work against it, plus our 3rd party vendors work against it).
Manage profile information linked to those users
Must be able to be accessed from any number of web applications on just about any platform (Windows, *nix, PHP, ASP/C#, Python/Django, et cetera).
Here some sample implementations:
LDAP/AD Server to manage everything. Use custom schema for all profile data. Everything can authenticate against LDAP/AD and we can store all sorts of ACLs and profile data in a custom schema.
Use LDAP/AD for authentication only, tie LDAP users to a most robust profile/authorization server using some sort of traditional database (MSSQL/PostgreSQL/MySQL) or document based DB (CouchDB, SimpleDB, et cetera). Use LDAP for authorization, then hit the DB for more advanced stuff.
Use a traditional database (Relational or Document) for everything.
Are any of these three the best? Are there other solutions which fit the objectives above and are easier to implement?
** I should add that almost all applications that will be authenticating against the user database will be under our control. The lone few outsiders will be the applications we're removing the current user database from and perhaps 1 or 2 others. Nothing so broad as to need an openID server.
Its also important to know that a lot of these users have had these accounts for 5-8 years and know their logins and passwords, et cetera.
There is a difference between authentication and authorization/profiling so don't force both necessarily into a single tool. Your second solution of using LDAP for authentication and a DB for authorization seems more robust as the LDAP data is controlled by the user and the DB would be controlled by an admin. The latter would likely morph in structure and complexity over time, but authentication is just that authentication. Separation of these functions will prove more manageable.
If you have an existing ActiveDirectory infrastructure, that will be the way to go. This will be particularly advantageous to companies that have already had Windows servers set up for authentication. If this is the case, I'm leaning towards your first bullet point in "sample implementations".
Otherwise it will be a toss-up between AD and opensource LDAP options.
It might be not viable to roll your own authentication schema for single-sign-on (especially considering the high amount of documentation and integration work you might have to do), and obviously do not bundle your authentication server with any of the applications running on your system (since you want it to be able to be independent of the load of such applications).
Goodluck!
Use LDAP/AD for authentication only, tie LDAP users to a most robust profile/authorization server using some sort of traditional database (MSSQL/PostgreSQL/MySQL) or document based DB (CouchDB, SimpleDB, et cetera). Use LDAP for authorization, then hit the DB for more advanced stuff.
We have different sites with around 100k users and they all work with normal databases. If most applications can access the db you can use this solution.
You can always implement your own OpenID server. There is already a Python library for OpenID so it should be fairly easy.
Of course you don't need to accept logins authorized by other servers in your applications. Accept credentials authorized only by your own server.
Edit: I have found an implementation of OpenID server protocol in Django.
Edit2: There is an obvious advantage in implementing OpenID for your users. They will be able to login to StackOverflow with their logins :-)