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..
Related
Currently, I'm using laravel socialite to link between facebook and my first website. I have 2 website that is already published, let say first_web.com and second_web.com.
What I'm trying to do is, after user log in(using facebook acc) into first_web.com, at any time when the user wanted to go to second_web.com, he is automatically logged in using the facebook acc.
I did my research but there is no tutorial or sample that has done this. Any idea how to achieve this?
In my opinion, it could be solved like this:
(but I must warn to say that, personally, I don't like the way to login in multiple web-sites in one auth-call and there is a better way to make this by it's needs - to use call-to-auth way like Google, when you are redirecting to their website and selecting your google account - one redirect per one call):
First of all you must to understand that you must to save the token in both clients browsers - on both of your web-sites, there is no way to share the same JWT or Cookie between multiple websites - it's unsafe and unsecure and not logical, so you need to create two tokens. (I am not talking about one domain websites, I am talking about different websites on the different domains)
You can use the JSON Web Token JWT approach. For your project you can use Laravel Passport or tymondesigns/jwt-auth according to the installation tutorial.
After the successful socialite API-call - you must to create the JWT token (using the packages from the #1 point) and store it in the client browser for the first website - Cookie or JavaScript-local Storage - choose yourself what way is better for your needs. (you will find a tons of examples in the search about this).
Then from the first website make an AJAX-call (from the JavaScript client framework you are using) to an api with the already given credentials - you will be redirected, selecting your social account e.t.c.
And now, I would make some question with the modal window - "Do you want to share your data to our website #2" and in here there is a second call to socialite API with the redirect. There is no way to prohibit the usage of multiple redirect to your social site, because of the inner security of most socialite providers.
Redirect after your api for the second website and save the
second token into the second website client-browser.
Make your redirect to your first caller-website.
My personal advice - don't do that anyway.
It's not so problematic to make differential authentication in your websites. It's more unsecure to use the way you had questioned.
Good luck!
I have multiple microsites:
https://www.samplesite.com
https://subdomain2.samplesite.com
https://subdomain3.samplesite.com
https://subdomain4.samplesite.com
https://subdomain5.samplesite.com
Once I login to one of these, it should also automatically create a logged session for other microsites just like GOOGLE.
How can I do this? Any ideas?
As I know, session is individually created for each domains and is certainly not readable for other domains.
P.S. I am using codeigniter as framework.
You should be searching the keyword "Single Sign-On". There are many ways to do it. But basically, you'd need:
A broker server for centralized login service. This server would allow user to login (through OAuth or whatever mean) and hold session information. And provide ways for other website (i.e. application) to retrieve that session information.
Adapt your websites (i.e. application) to use the broker server's session. Probably with mixed backend php and frontend js work.
A quick search for PHP library yield this result:
https://github.com/legalthings/sso
There are probably other libraries that can do the same trick.
It was required that my application uses a SSO Service called Shibboleth. So I used the existing shibboleth-bundle. Things have changed and we need to add a form authentication method for the user. So I decided to implement Shibboleth authentication with the new Guard Component. (See ShibbolethGuardBundle)
I found a problem during the development. Symfony calls the ShibbolethAuthenticator methods at the first request, creates a token and never calls any ShibbolethAuthenticator method on later requests. That means, if Shibboleth session ends the user is still authenticated using the Symfony session.
This is also a problem if you want to implement a token authentication. The user only need to send the token at the first request. Any other request is authenticated by the session.
This problem exist also with other SSO services. If you logout at Facebook you want to be logged out at any website that uses Facebook authentication. But if you implemented this with Guard you still have a valid session after the logout at facebook.
I found a quick solution by checking if the shibboleth header variables are set in my UserProvider on every request. If they are missing, an Exception is called and my ExceptionListener redirects to the login page.
I think this is not a good solution, because the ShibbolethGuardBundle should handle this problem. Does anyone has an idea how I could solve this in a more appropriate way?
The way I see it, authenticating the first time and sending the user data is to either create a user object or sign it for that website. After that, you have a session with Site A, using data from the SSO service, I think that's the intended behaviour. It is not to sync logins / logouts with the SSO service.
One workaround: In http://romain.pechayre.me/blog/2015/06/26/single-sign-out-problem/ it is described how Google might handle this (not sure if this is still current, but it's still relevant to your question):
When signing out from gmail a few days ago, I noticed my browser visited blogger.com for 0.5 second. I went back to blogger.com and realized I was logged out. Same on youtube.com. [...] The main idea is that the browser actually visits all website from Google on which I have the session and closes the session on all of them. [...] The main reason why signing out from several websites in one click is not well documented is because it is not a very common situation. When this problem arises it is probably fixed using a custom, in-house implementation.
My company has 3 applications on 3 different domains. Next thing we would like to do is to implement a single sign-on solution, so when a user is already authenticated in one app, they don't need to authenticate again in the others.
I know about OAuth2, but I don't feel confident when it comes to fully grasping its idea. Additionally, I got the impression that OAuth2 would be an overkill in our case, because the 3 application are all ours, so they're not really "third parties" to each other - they're trusted and they're all developed by us. We also don't really need a full API approach, which would be passing an access_token with every request that requires auth-access.
I see the process simply:
User comes in. First, check if they are already authenticated on one of the 3 domains.
If the user is not authenticated yet, redirect them to login
page and employ the successful login attempt to "mark" the user as
authenticated across all 3 platforms.
If the user is already authenticated on one of the 3 platforms,
simply provide the requested resource without the need to log in.
I could put a big "HOW?" after the first two points, so... How would we go about it to achieve just what we need?
I've been looking for examples online. Most of them deal with the one scenario of first page visit, in which the user is asked to log in, so the application can get an access_token to communicate on behalf of the user. That's cool, but I'm really interested in is the case that comes later, when the same user visits another affiliated domain.
I understand this is a theoretical "how-to" problem, but still I would be very grateful for any suggestions or resources that could shed some light on the kind of implementation we could (or should) use.
We started using Central Authentication Service at my company to great success. See this for a great sequence diagram for SSO in CAS. CAS supports several protocols OOTB including SAML and OAuth2, and also supports several user databases OOTB. We're using LDAP to store and authenticate users.
To answer your question, after login with the SSO provider, your client gets a cookie with a "ticket-granting ticket" (TGT). When they try to access any secure resource, they're redirected to the login page again, but if they already have that TGT, the SSO provider immediately redirects back to the secure resource with a "service ticket" (ST) in a query parameter. The ST is used by the server to validate that the user is authenticated with CAS, and it can even get attributes about the user (things like roles, name, phone number, etc.). The server then should start a session with the client so that that redirect handshake only happens the first time the client tries to access the secure resource.
CAS has a PHP client.
I need to login with my account with php curl in a website that uses facebook connect to login.
I'll take as example site one of my favourite apps: Mousehunt
As you can see, it uses facebook (of course) to login: if you are already connected to facebook, it succeeds in automatic login, otherwise it popups facebook login.
How i can login into it with php curl? I know some about curl & cookie (cookiejar, cookiefile, post etc) but not too much.
Which is the target url to post data? How can i return to that site as user logged in?
Let me explain how this sort of FB login works. There is of course the alternate method used for desktop applications, which would make it possible, but this website doesn't use it.
So heres the deal:
The login button opens a link on facebook servers containing the api key of the website and some arbitrary information. So far so good. You could simulate that easily.
Then after accepting the privacy stuff you get redirected back to the website. You can simulate that as well.
But then comes the burden:
The location you get redirected to contains an facebook token after the hashtag (#).
The website can then read this token by Javascript and use it to query the facebook api to confirm your dientity.
The reason why this is done that way is easy:
Think about it. Everyone could fake a request in the name of the website and read your private data. But everything after the hashtag is never readable by the server the request is directed to. The web browser just does not pass it and it would be violating http standards and cause an error.
The only way to access it is by javascript. And this can only be by the website serving the request (where facebook redirects to). And the domain where facebook redirects to is locked by the application key owner.
You see javascript is an essential part of the security here.
I think it is very insecure indeed because there are many possible explits, but its very easy which is a reason why this form of login is spreading so much in comparision to e.g. openid.
So to sum it up: You need simulate a fully javascript enabled browser. It is partly possible but very complex and there are no out of the box solutions for that.
well, there might be a way.
looks like facebook request don't sign the permission scope in any way.
so this basically means you can grant the application/website more permission than they even asked for.
then you could grant the website permament permission - log in the usual way - and save the cookies.
then you can send those cookies along with curl.
if the website uses servers side login authentication, which is very likely, you will still be logged in, because the access token is permament.
however there is no guarantee for that hack to stay functional.