Hi All I am working on a single sign on system which a load of other web applications will use as its membership provider. I currently have the system up and running in ASP.NET MVC and everything works well, users can log into an application once and have access to all the other apps through that login cookie.
The problem is that users dont all have access to the same apps, this is currently handled at login and if they dont have access to the app they are denied. However with the cookie being set automatically by asp membership, if they do login to an application they have access to they are then given access to all the other apps via the cookie, including the ones they dont have access to.
Any ideas on how to fix this? Ideally I want the cookie to remain as part of the process as I like the idea of a user logging in just once to access all the apps they have. Ideally the applications will maintain the login details but check a webservice if those details have access to that app? I wont have access to the individual applications (they all use standard out the box asp membership, only the web config is altered to point to my system) and all this must be managed by the Signle Sign On area.
Many thanks in advance to those who contribute!
How about setting the names differently for each of the apps that use the membership system?
Related
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.
I have created a chrome extension which gets data from the current active tab in chrome. I send the data to my webapp via an API which stores it in the database.
At the moment my chrome extension has a fixed user_id. I would like to prompt the user the user to log in in order to get the correct user.
Is it safe/valid to check for cookie - if it exists use it otherwise prompt user to sign in via the browser?
It's probably okay, as long as you're not storing anything sensitive in the cookie like a password (obviously).
However, the appropriate way to accomplish this would be through something like oAuth. In this scenario your web app's API would be a oAuth consumer, and you would use the following library to authenticate in a Chrome extension:
https://developer.chrome.com/extensions/tut_oauth.html
This library will save an authentication to local storage for you. It's pretty easy to use. The difficult part is ensuring your web app's API supports OpenID. Google's AppEngine supports this pretty much out of the box with little configuration on your side, but this may not be the case with your API.
I am working on a cross platform app that will be created using C++-> mobile devices, and using Perl-> Desktop PCs (like Windows /Linux/Mac OS).
Now, since the app will be downloadable, I have concerns regarding the ability of hackers to obtain the source code of my app.
Specifically, the app will connect to my central database-- at the minimum, I want that hackers are not able to obtain my database connection details. Ideally, I would want no part of the code to be hacked.
Basically, the user can update some of his information using this app-- if hackers get hold of this data they can easily change any unfortunate user's data. One thing that I have thought of is that the user will have to initially authenticate with OAuth/OAuth2 ( using his email ID #yahoo/#hotmail/#gmail)-- and only after that the app will actually show the admin interface. But at any rate, at some point the app will connect to the central database-- which is why I dont want the database's access details to be compromised.
Many organisations make such apps, so they must be facing this type of problem themself? I would like to know how I can protect my app (ideally entire code), and atleast the db credentials.
The simple answer is you do not expose your database. Ever.
Add a service layer (could be HTTP-based but doesn't have to be) on top that will deal with authentication and authorisation. Your app then logs in using the user's credentials and acts on their behalf. Your service layer exposes an API which your application talks to, but your service makes and controls all calls to the DB.
You already mention OAuth - that's a perfectly acceptable way of adding authentication to such an API.
You cannot.
On the bright side you can put security on your server. The connecting client provides credentials that they are a given user. The server generates the SQL command after proving the request is allowed. Backers can do anything your app can do, but your app becomes incapable of behaving badly to your database.
The previous answers are absolutely correct. You want a server based service layer that provides the authentication/authorization code and interacts with the database. However, it isn't always a perfect world and if you are stuck with the requirement that these applications must act as a database client you want to limit the exposure as much as possible. Typically this is done by having the client use a specific account which has not been granted any access to the general database. You then create specific stored procedures that can only do the operations and queries that are required of the application. This prevents anyone finding the credentials in the code from doing anything in the database that isn't intended, but you still have the problem that anyone can impersonate someone else by reviewing the code. There isn't a way to prevent that without a server side component. This might be okay for a closed/trusted group of users, but I wouldn't release anything to the general public with this method.
If you can do it, use OAuth2 and allow a trusted third party handle authentication. Twitter, Facebook and GitHub are all relatively paranoid about security; and the other poster is correct: never expose direct db access as part of the app the user has access to; put it behind a service of its own.
Good luck! :)
So I want to do the following:
A person registers online and selects their login and password for a desktop and web application (same login and password for both applications)
They then download the desktop application (written in C++ with Qt as it's cross platform)
Then the login and password is automatically passed to the desktop application without the person needing to enter this data. The login and password is used to authenticate with the server.
Each version of the desktop application needs to be individually coded with the person's login and password based on the fact that they signed up on the web page.
So here is a more simple explanation:
1. The user signs up on the web site and choose login\password
2. The user download desktop client on his computer
3. The user runs desktop client (C++ binary) and it asks for a login/password from the step
I would like that software fill in login/password automatically on step 3 for the first time. Is it possible? How would it be done without security risks?
The main problem is, that anyone could execute the program and gain access to a user account. I would suggest using a one-time login for first authentification with random tokens and after the first start, get the user/password information through an ssl-connection. After that delete your one-time login token and replace it with the actual login.
I don't really know whether you're asking for precise code examples or just want to have a basic concept... But anyway, storing login-data in the application itself is a security risk.
Have you look at HTTP Authentication?
I do not fully understand the download process of the QT app, but, if you use a Basic/Digest Authentication on your web server, propagating the authenticate token will be easy and safe.
Basic use a 64 base encoding, Digest a MD5 hashing. A lot of library implements those steps out there (Spring Security and Shiro in the Java world).
I saw two ways:
the server can provide a user with unique link for downloading installation package. The server patches that package by unique one-time password. So client will be able to login for a first time
the browser collects some information about a user's computer. For example, IP, MAC, OS Version, etc. Then it calulate digital sign of the computer based on these data. The C++ binary do the same. You can use that digital sign as one-time password.
I want to upload a file to a website via a desktop app and then take the user to the website. The website has a web service, but requires authentication as does the web site. Is there a way to do this without forcing the user to authenticate twice (once in the desktop app and once in the web browser)?
Unfortunately, you can't prefill an input of type file for security reasons, which makes sense since the user won't want you uploading arbitrary files from his/her computer. But if they have a desktop app, is there some way around this?
Or maybe make the user log into the web app first and then the authentication cookie can be reused?
Any other ideas?
Thanks,
Ben
I would use the dekstop app as a client to the website app via an api.
So, login via the desktop app. The api returns a authentication token (as Carlos suggested) which might be a md5 hash stored in your database for a certain period of time, possibly matched to the clients ip address.
The desktop app can then make calls on the api (like uploading a file) as a authenticated user (by using the auth token).
When loading the website, perhaps the url is http://website/login/{auth_token} where the auth token is added to the url. The api can check to see if its a valid auth token and consider the user logged in.
You could generate an authentication token that could later be used on the website.
It all depends on the type of authentication of the service and the site. Is it integrated Kerberos, WS-Auth, is it Basic/Digest HTTP, is it forms/cookie ?
This answer will most likely not work in the very general users-on-the-wide-open-web scenario, but in intranet contexts, using Windows Authentication (on an ASP .Net solution), would provide this.