[Scenario]
I already have 5 PHP5.3+ applications (eg: App-A, App-B, App-C, App-D and App-E) up and running. Here, each application has its own login user-id and password.
[New Requirement]
Now, I want to implement the single user-id and password to login to all these applications (by using App-A). Lets say: I want to login to App-A as usual and once login I should be able to click through to other application (B,C,D and E) by simply clicking on the icon on App-A (once login).
And, my user should not be apple to login through App-B or C or D or E. They always need to connect via App-A.
[Background]
-All of these application are running on different domain but on the same server.
-Admin will be able to enable/disable certain App for certain user
Does anyone has done similar or anyone has any suggestion please suggest.
This is the very good question and have done small research on your question on different ways:
OAuth:
After reading the documentation and gone through many service providers it is not possible. Oauth service provider gives the consumer key and secret and they check the request coming from the domain and thus if the same oAuth consumer key is used on different domain Names that doesn't work.
Setting Cookie Multiple domains
Simply, it is not possible to set the cookie without visiting the domain by any means
Thus, I can say that it is not possible to set cookie or use the same consumer key and secret for multiple domains
Alternative ways
Use HTML5 Web Storage for storing the information and then accessing
the information from different domains is possible.
Use AJAX/CURL for sending the request for setting the cookie for different domains such as example.com/session_cookie.php?info=xxxxx
Maintain a single sub-domain/page for all the domain for login purpose for across all the domains.
Related
In the latest version of our SAAS product, we are designing it to allow our customers to deploy multiple instances of the software.
We require the sign up and login to be tightly integrated into the primary domain - the "sells the product to new customers" website PrimaryDomain.com which features "Sign Up" and "Login" forms that use jQuery/AJAX to give responsive feedback on data submission.
When a customer successfully logs in, they are to be presented with a list of all their installed instances of our product. All installed instances of our product can be hosted across dozens of domains, but to keep this question simple, they are hosted on [subdomain].SecondaryDomain.com (code + database).
Every installed instance also features an admin panel which currently customers need to manually login to each individual instance as required.
We want the customer to be able to click on 'view admin panel' next to any of their installed instances and automatically be logged in on [subdomain].SecondaryDomain since they were logged in on PrimaryDomain.com.
SecondaryDomain.com naturally doesnt have access to the cookies or session variables of PrimaryDomain.com so what is the best way to allow SecondaryDomain.com to authorise?
We have considered a few different options, such as;
Researching some clever way that the domains can share cookie/session data?
Generate a token that is passed with the url when clicking 'view admin panel' to the second domain. The token is unique to the userid plus subdomain (such as an md5 hash) and then validating it on the receiving end.
Recording a one-time-use token into the database and sending with the url and having SecondaryDomain.com connect to PrimaryDomain.com's database to verify the one-time-use token and set appropriate session and cookie variables.
The one-time-use token seems like the right approach, but i havent been able to find any concrete answers on (a) if this is even the RIGHT approach, and (b) what the security implications are around it?
I recommend SAML for this case. SAML requires you to have an identity provider (IdP) and service providers (SP). The user will login to the IdP and present the token to any SP visited. The SPs need to be configured to assert the token against the IdP. You probably want to look into Auth0's SAML SSO offering for more information, but there are other providers out there that do the same thing.
I want to create a common logins for my php applications. My website has four and more php applications. I want to create a common login for these php applications in the same way as google uses common login for its apps. My website is new and has not be indexed much. Can I create a common login for users to use my website apps. Is it simpler and possible.
My website :http://goo.gl/d2n20q
You can. It's called Single Sing-on (SSO), there should be A LOT information about how to implement it on the web. Here's one on PHP that you could use and customize: http://www.jasny.net/articles/simple-single-sign-on-for-php/
If it's cookie based auth (you authenticate the user, then save a cookie with the user auth info), you will need to take the domain into consideration, that is all web apps should have the same domain i.e. www.finysel.com, app1.finysel.com, otherapp.finysel.com (and set the cookie accordingly).
An easy approach is just create a database/table for logins, then share common files for auth thru your PHP sites include /Path/to/shared/Login/login.php.
You can also create a web service that takes the login information and returns if the auth is valid and the auth info required. An easy way is just to implement it with JSON responses (if the user and pass are valid, then you return the User in JSON, if the user is undefined then it didn't authenticated successfully), then you can create just one Ajaxy Login that you can re-use in all your websites.
Note that SSO just Authenticates the user. To check for privileges and permissions you would need to add Authorisation layer.
Finally, PHP has an oAuth module that you could use if you decide to implement a full fledged service. You can become your own oAuth provider. That's how you'd go if you want an implementation like the one provided by "Sign with your Google/Facebook/Twitter/OpenID Account" but might be overkill for what you need.
create a database dedicated to users, and authenticate users against this database on all apps.
i have 3 différents domains domain-a.com and domain-b.com also domaine-c.com
and i want to use SSO, if you log in to one of these domains you have access to all other domains.
1 - using cookies is impossible because we can't share the same cookie with differents domains
2 - i'm thinking about using webservice, but i'm not good in that so i'm wondering if it's a good solution
If you have any suggestion or recommandation or any thing Please i need you.
You can't share cookies but you don't need to.
Let's say your SSO runs on sso.domain.com
You want to log in on a.domain.com:
Make an XMLHTTPRequest request to sso.domain.com to check if you have a session.
If you have a session and are logged in you get a login token back.
You pass the token to application A with an XMLHTTPRequest. It sends a request to sso.domain.com to verify the token and get the user credentials.
You are now logged in on a.domain.com
This setup requires Cross-Site-Resource-Sharing to be enabled on the sso domain. The CORS implementation allows you to do the login process under water, no redirect is required.
Your an indepth look at CORS see: http://fritsvancampen.wordpress.com/2013/02/03/cross-site-origin-requests-aka-cross-origin-resource-sharing/
I use SimpleSAMLPHP.. (https://simplesamlphp.org/)
This allows me to make a single place I can ask if users a logged in. The whole thing uses SAML2 which is a secure markup language(http://en.wikipedia.org/wiki/SAML_2.0).
It can be a steep learning curve to make it work but its very safe and everything is encrypted using certificates. The nice thing is that you can use all the IDP's(identity providers) you can think of. This means you can implement facebook, google etc. log-in's as well as custom log-in's.
Another great thing is that it provides SLO(single logout) as well. This will trigger log-out's in all the applications that are currently logged on..
On my site, I intend to offer users the ability to authenticate via OAuth. I don’t want to ask them to first register with me and then connect an external account; I want to offer single sign on.
I believe we’re supposed to reuse Access Tokens; certainly within sessions and even between them.
Google goes so far as to say they’ll limit the number of access tokens to 10 per user per application. (Apparently Google still supports OAuth1, but recommends Auth2 now) 10 is a pretty small number.
Using cookies (like this) seems like a good plan for identifying a user between sessions, but I’m having trouble with the scenario where a user has deleted cookies or connects from a new machine.
How do I know who the user is before I’ve requested another Access Token for them? Request tokens do not contain the userid, right?
Thanks
You will have to maintain your own user accounts anyway, no matter which protocol and which provider you choose. A token (or a URL in the case of OpenID) that you get from a provider is unique for a given user and you are supposed to associate it with your internal user account and recognize user by it.
If you don't want to provide any registration UI it's okay: just get the token, retrieve all the user info you need from the provider and store all this somewhere in your database. You will also have to issue and recognize your own cookie for your users, or else they'll be forced to go through provider auth every time they visit your site.
I'm trying to implement single sign-on for a web portal. I've written some code to send a POST request containing the user's login credentials to an external web app to log the user in. (Don't worry, this is all over SSL)
The HTTP response from the web app contains a cookie for the user's login. Is it possible for the web portal server to then pass that cookie to the user's browser? Or is that impossible since the web app is on a different subdomain? I understand there are some security measures built into cookies.
Short answer: NO.
The HTTP server can indeed log into the other service and pass the service's cookie back to the user, but the browser will set that cookie's domain to be the HTTP server's, not the remote service's. There's no way for 'server A' on 'domain A' to make a cookie appear to have originated from 'server B' on 'domain B'. If it were possible, it'd be trivial to steal everyone's authentication cookies for their bank, facebook, myspace, etc...
There are indeed things like cross-domain policies build into modern browsers.
However once upon a time, I created a single login techlology for my own website.
There is a trick you can do. First, on the main site where the users have their
login information, have them a secret generated key. With this unique secret
key to every user, pass them to the other site like
www.abc.com/secret_key
from this secret key, your other website should be able to pull the needed information
like username, profile picture & stuff like that and should create the session on that
domain. So you would have the session created for the opposite domain.
If you still need to pass something back, I would recommend you to go a way that
incorporates RPC over PHP and post something back to your major domain.
This should solve your problems. If you want I can attach some example code.
Note: The security here is in the secret key. Since it's a unique generated key
for example, a md5 hash, it's hard to replicate this. So there is no such thing
like someone could reprocude the secret_key and then login to your site as someone
else.
You should also note that, the secret_key api should only be able to get the
needed information so that not too much information is gathered on the other side.
Why reinvent the wheel? I think that you can find OpenID implementations for PHP. For the consumer and the provider.
You can restrict your OpenID-logins to your domains only if you don't want them to be used elsewhere.