I am planning on creating a number of web applications that allows the user to share an account between these applications. I am using apache, php and mysql.
My question is, is it possible for the user to login on one server and then be able to use all the applications with these login details. I was thinking of using some kind of web service/api that can be accessed by the other applications but I am not entirely sure that this is the best way.
Thanks in advance.
You might want to go for the popular OpenID:
OpenID is an open standard that
describes how users can be
authenticated in a decentralized
manner, obviating the need for
services to provide their own ad hoc
systems and allowing users to
consolidate their digital identities.
There is also OAuth authentication system:
OAuth (Open Authorization) is an open
standard for authorization. It allows
users to share their private resources
(e.g. photos, videos, contact lists)
stored on one site with another site
without having to hand out their
credentials, typically username and
password.
Yes I would build an authentication service. Then I would register within that service which applications the user can use.
Related
I have two websites, one is Wordpress and other is PHP. How to login Wordpress and my PHP app with the same credentials.
I need that when a user registers on my WordPress site he automatically appears registered on the PHP site.
I would suggest using OAuth 2.0 Server , a package by thephpleague.
It will allow you to turn one of your applications into an oauth-server, the second one being the client.
The oauth-server application would grant an api key to the client so that its users can login from the client application.
The same thing happens when for instance you login to Stackoverflow using your google/facebook account : google/facebook is the server, and stackoverflow the client.
I think using oauth would be cleaner, more secure and standard compliant than duplicating your users datas accross two web apps for the following reasons :
you would need to replicate each new user on any of your website;
compromising any of your websites would give the attacker your users credentials(login, password) for the two web apps, whereas with oauth he can't get the passwords of the oauth-server users while being on the client;
etc;
There are many other reasons but there a more experienced developers able to give you deeper explanations.
There's also a wordpress plugin that would fit your needs that you can find here for JSON Web Token Authentication.
I have 2 sites:
SITE A - an asp.net site
SITE B - a php site
We have all the user information in an asp.net site (which is actually a Kentico site).
Now, there is a business requirement that users should be able to log-in with the same credentials in Site B. Ideally, we would need that users who log-in Site A, and navigate to Site B, the authentication would be automatic.
Is there a way to achieve this form of authentication. Or is it not possible?
This is not an authentication problem, but an authorization one. Once you have authenticated your user, in whichever way you want, with whichever technology you want, you probably will grant them some sort of token that you will then use to grant authorization to the different resources in your sites.
In your case you have two different technologies, which only means that you won't be able to use the out of the box asp.net or php session management, but all you need to do is have a common place to check that the session tokens are valid, they belong to a legitimate user and that user has permissions to access this resource.
If the above is trivial, sorry, maybe your question is more oriented to the sites being in two different domains, and therefore not being able to use a domain cookie to store the session information. is that the case?
The canonical solution to this is to use a protocol like OpenID. OpenID allows a website to ask a user to authenticate themselves using a different site, and then honour those credentials; using a protocol called "attribute Exchange", the authentication provider can provide additional data about the user.
OpenID is how StackExchange manages to log you in with your Google account (or whatever you're using), and how sites in the SO network recognize your identity without you logging in everywhere.
The benefit for OpenID is that it's a widely used protocol, so it's likely to be highly secure and well-tested; you don't risk weaving your own solution and accidentally exposing your users to security risks. It's well-documented, and widely supported.
There's an OpenID framework for .Net which allows you to create your own OpenID provider; it appears Kentico supports OpenID as an authentication mechanism. There are several OpenID libraries for PHP (Google is your friend here).
Exactly how you implement this depends on how your Kentico authentication works right now, but in principle it should be fairly easy to glue the Kentico user database to an OpenID provider you write; getting Kentico to use that for authentication appears to be a configuration setting. You'd have to re-write the PHP site to use OpenID; again, not clear how that currently works, but I can't imagine it would be harder than any other solution you might try.
I had a similar issue on a .net platform where I didn't have the option to put them on one subdomain. In that case you could pass the username and a token (that signified the user was already authenticated by site B) and perhaps the encrypted password to re-authenticate against an external DB, then redirect them to the site. In my case I needed to do this as I was redirecting to the corresponding site CMS for site admins.
We have an app hosted on our domain. All users are required to first log in through a POST form. Once login has happened, then form redirects to dashboard page on our site automatically.
Is it possible to allow some clients to host their own login forms (on their site), that POSTS to our app? Is cross-domain posting considered bad practise in any way? Are there any pitfalls to be aware of? And lastly, how is SSL taken care of given that our site always runs on HTTPS, but client sites may not? Can this be circumvented with an iframe?
What you are trying to reinvent is called openid.
What you need to do is provide a openid service, and then users can make there own login forms that connect to your open id server.
I have a great example of such a site: http://www.stackoverflow.com that uses google and others as openid service to log in, making there own login form.
What you're trying to do is generally referred to as Single Sign-On (SSO). This can be implemented using a variety of technologies.
The general idea is to separate the Service Provider (SP) (also sometimes called Resource Provider), which is what provides the actual service the user is going to use, from the Identity Provider (IdP), which is where the user's identity is verified.
The simplePHP library provides implementations for both IdP and SP authenticating layer using a number of SSO standards: SAML, Shibboleth (also SAML-based), OpenID, ...
Note that if you're using a standard, the IdP shouldn't need to be implemented using the same implementation as the one you've chosen for your service. It could be possible to have an IdP implemented in Java using the Shibboleth libraries and use it in conjunction with an SP that uses simplePHP, for example.
Which of these techniques you use will depend on the kind of information your require after authentication, for example if extra attributes are required, and how trust is managed between the IdPs and the SPs.
Typically, a simple OpenID system will be rather straightforward to integrate, from an SP point of view, but it will be quite limited in what it can assert about the user. In contrast, Shibboleth has a number of options to specify which SP can see which user attributes and what IdPs are meant to release or not, but it requires a more substantial infrastructure: this is typically done in a federation, where all the parties exchange a set of metadata configuration that comprises X.509 certificates they use to trust each others' assertions.
Since the authentication will happen outside your administrative boundaries, you can't really control how the users will have authenticated (unless this is part of a more formal agreement, such as in a Shibboleth federation). The OpenID provider could potentially let users authenticate over plain HTTP even if your service requires HTTPS. (This being said, most serious OpenID providers do it securely, and it's up to the user to pick one their trust anyway.)
Never embed the IdP page in your service: make the user go to a their IdP page instead. For an authentication system to be secure (as far as the user is concerned), it is essential that the user be able to see what they're typing their passwords in. By using an iframe, you would effectively hide the real site behind (and logos are easy to grab/forge). (The StackExchange OpenID provider has some problems in that respect.)
I have written an API for my latest project. Written entirely in PHP, it currently supports web and mobile applications. We would like to expand that to desktop applications as well, but I'm not exactly sure how to enable to user to login through the desktop application, while still protecting the username and password from said application.
There are many brilliant developers on Stackoverflow, so shoot me some brilliant answers!
The application will be developed by 3rd parties, so I want to ensure they aren't able to store usernames and passwords
If the application has to send usernames and passwords, then it has to be able to have access to them, so don't use them inside the application at all.
Use OAuth. This is the solution used by quite a lot of large organisations, including Twitter.
There are many possibilities. What comes to mind:
Issue a Certificate signed by your CA and verify later, eg via the OpenSSL lib or Apache.
Use Public key encryption, eg via GnuPG lib, and grant access only to known pub keys.
Use any kind of Token based authentication or any other two factor authentication..
Just give them another set of API credentials (Secret Key, API Key)
its a desktop application, it has full access to the users keyboard and memory. if the application should have a login form where end users type in their usernames and passwords, the application has this data by definition.
the only solution would be to distribute the login-application yourself which does some sort of toked based authentication and provide the 3rd party applications a login token via your api.
oauth and other singe-sign-on systems on the web usually use an iframe or popup which comes from the system-to-login-to itself. no 3rd party website or application should be allowed to provide this input fields.
Hi guys I'm building a Google Apps based solution. Basically I'm setting it up such that:
When a Google Apps account holder installs it he/she enters the authentication details for a single Googles Apps account to be used - that account would be used by all users of the instance of the installed system for uploading to Google Docs associated with that account and managing Google Calendar entries associated with that Google Apps account.
The user as mentioned can create other users and invite them to sign in from a separate login screen and they should be able to interact with the system's facilities which allow interaction with the services associated with the Google Apps account used to install the system.
Any other user of the same domain as the original user can also install the system and be automatically associated with the instance created by the user of the same domain.
I got parts one and three all set up but the second part is where I'm stuck - I'm storing the credentials for the centralised Google Apps account in a database and would need a way to authenticate seamlessly using the details i.e. I don't want the users to have to add in the sign in details nor have to go through the process of having to be asked for permission to allow the application to access the Google Apps services - I wish that when the users log in they are automatically transparently also signed into the Google Apps account as well and be able to use its services.
How can I do that I wish to do away with the process of 'asking the user for which account to sign in or the Google Apps login screen' and the second step asking for permission to allow the application access to the account.
I know it can be done - I've installed loads of applications and none of them require me to go through this two pronged process of authentication which I find quite unnecessary - what do I do? - Help please!
Have you seen the Zend Frameworks' Zend_Gdata? It's a PHP 5 interface for accessing Google Data, at first glance it seems to do all the things you want.
http://framework.zend.com/manual/en/zend.gdata.introduction.html
You will need to take over the authentication process to handle authentication of Web sessions. The good news is that you can indeed do that (SSO / SAML), bad news is that it can be a lot of work.
Essentially you'd build your own SSO provider, stick it in front of your domain (so it handles all auth), and let it handle the login process so it's as seamless as you need it.
At a higher level, it sounds like you are using a single account to proxy multi-user access into Google Apps; you might want to check the TOS as I'm pretty sure that's frowned upon (kills traceability).