I am creating a plugin in my website, where logged in users can view their emails. The Email Server I am developing against is Zimbra. So far, I have been able to successfully fetch and display user emails using PHP's imap_open function:
imap_open($server, $email, $password)
When a user clicks on an email link on the website, the user is navigated to the zimbra web client. However, the users will have to reenter their log-in credentials once more. I have checked my browser's cookie information, and have noticed that Zimbra sets a cookie, ZM_AUTH_TOKEN, when a user is logged in: I believe Zimbra uses this cookie to detect if a user is already logged in. In essence, my task is to eliminate this extra step of re-logging in; if there are open-source solutions, I would like to know about these as well.
You can check the official documentation here:
http://wiki.zimbra.com/index.php?title=Preauth
This is half of a solution -- sorry I've never programmed with Zimbra, but I've implemented single sign-on across php projects several times.
Is your domain and the domain of the zimbra webserver the same? If they are you can see and manipulate each other's cookies. Try to find the zimbra code that handles the login and sets a cookie. Then write a little web service web page and put it on the zimbra server that calls that code and returns the cookie token. Your website can then do a curl behind the scenes over to zimbra when a user logs in, get the token contents for the cookie and then set the appropriate cookie so they are logged into Zimbra. I secure the web service web page with a password that only my plugin website knows.
If they are not the same domain you can still do it. But instead of doing this through curl on the server you'll have to use frames or JavaScript on the client. Also a simple password to secure the login web service will not work since it is being accessed by the browser and everyone can see the password. You'll have to make the password more secure like hashing their email address (assuming it is the same on both servers) with a predefined secret.
Related
I'm trying to create an intranet site where, if possible, all parts of it should be SSO in a way that a user who is logged into his Active Directory account in Windows would immediately be signed on with that same account in all pages of my site through LDAP.
Now the main component of this site is built with a CMS and from there the user should be able to click the links on this site to get to the other tools we're using, like for example the ticket system.
The CMS and the ticket-system software both are able to connect through LDAP themselves but I want a SSO solution for this.
So I searched and found this for the apache server: mod_authnz_sspi
This apparently lets you use $_SERVER['REMOTE_USER'] in PHP to get the windows user signed on right now.
Now I'm stuck since I'm not really sure how to use this to automatically log the user into the sites.
What do I have to do with this to get the SSO solution that I want?
I thought about creating a simple HTML form with the same fields like the one from the ticket-system form I'm trying to log into. I would then try to send the POST-data to the form of the ticket-system and log the user in automatically. For the username I would send $_SERVER['PHP_AUTH_USER'] and for the password $_SERVER['PHP_AUTH_PW']. However, the ticket system is protected with a CSRF-Token which I would have to include into the sent POST-data but can't know in advance since it is generated in the moment of accessing the page.
So it would be really helpful if someone could tell me how to get a SSO working with the mod_authnz_sspi tool (or another).
If there isn't any other way than through using a HTML-form that sends the POST data like I tried, then it would be helpful if someone knew a workaround to the CSRF-Token problem!
You can create an AUTH application that administrate your users (details, permissions, etc.). When an user access other application if it are not logged in redirect it to the AUTH application. AUTH application check user credentials, generate an access_token and redirect user back to the application that try to access. More info you find here https://www.mutuallyhuman.com/blog/choosing-an-sso-strategy-saml-vs-oauth2/
I have created an extension for my website. It should log in user to forum after he has logged in to the website.
User session was created successfully (checked in database), but user still not logged in.
If I try to log in with external login form, it works great (the session is created and user is logged in).
I think the problem is not in my authentication extension.
I think I did something wrong with curl post and cookie.
What curl options should I set to login? Or maybe you can give me some useful links?
Take some of those phpbb3_* cookies and then send them through
[setcookie()](php.net/setcookie) to pass along to the user. It
might work, depending on your level of cookie security in phpBB (it
can't be tied to IP because curl and the user IP will be different
drew010
You won't be able to use curl and pass the cookies to the client if you >have Session IP validation turned on. I'd suggest turning that off, or, >instead of using curl, look for a plugin/module that can do 3rd party >logins, or look at the authentication handling code and replicate it. It >wouldn't take much to log a user in without requiring their phpBB password
drew010
I started to develop a web application as a major project for my degree. Purpose of app is not important. My problem is handling the login. I have no problem with setting up login with jQuery mobile, that is actualy working pretty well. Problem is I'm handling login with php script through ajax and creating session in that process. So for checking if user is logged in or not I'd normaly use a php script, but in this case I can't. I need to keep using only client side for authentication. What would be the solution for this? Can I handle authentication with some native jQuery functions or do I need to write some JS scripts? If anyone have any solution please I don't need actual code, just best solution. Thank you
You can achieve this as long as login authentication is restricted to the device. What I mean is that user-id / password combination can be stored locally on the device. You may choose local file system storage for this. Here are the steps:
1) Make user register with uid/password
2) Check uid is existing in your local storage. If not register by writing it to local storage.
3) Later when user returns, validate login credentials against the local store.
I assume you're developing a native app with a mobile web framework. In this case you have two choices:
POST the login details out to a server somewhere, authenticate and return the session, allowing the user access. This will obviously require internet access, but will be more secure.
Store the credentials in local storage using JavaScript when the user signs up. Encrypt this value and compare against it when the user logs in.
I am in need of an authentication system that would work in harmony with the current authentication system my client's server uses.
The current system works as follows:
A page requiring authentication invokes an in-house developed mod_auth Apache module in the .htaccess file.
The user is redirected to a generic log in page.
After entering valid credentials, a cookie is created, which has the IP address of the client, a public key, and other helpful info about the user, all base64 encrypted.
Any page requiring authentication after this point checks the public key and the requesting IP address. If the user's IP has changed, they are redirected to the login screen. If the cookie is tampered with, they are redirected.
The benefit of the above system is that a cookie can not be used on another machine (other than on the same LAN, but other measures check against man-in-the-middle attacks), as the IP address won't match.
The downside is that this method prevents the user's session from being extended server-side. In other words, a server-side script can't get information on behalf of the user since the IP address won't match.
This limitation makes sense under most circumstances, as it avoids allowing the server from "stealing" the user's cookie. However it also means that a Web Service can't be protected using the same authentication system, since requests will always come from the server's IP, never from the client (unless AJAX is used, which is a very limited usage of a web service).
What I would like is for the web service client (server-side) to pass the cookie to the web service server and have the web service server verify the authenticity of the cookie directly with the end-user's client.
My basis for this is how sites like Stackoveflow use Open ID to check log-in status at the browser level without the end-user being involved unless the check fails.
A quick wikipedia search leads me to understand that the underlying system involved is a protocol called Yadis.
So I would like to know if I am missing any pieces to this puzzle and if I'm leaving myself open to major security flaws:
User logs in as normal
Page user requests needs web-service
Page passes user's authentication cookie to web service
Web Service uses same cookie to request a generic "confirm authentication" page via user's browser. (without user seeing this).
"confirm authentication" page returns a "user logged in" message or the browser opens a new window with log-in page.
Upon receiving the "all clear" message above, web service returns any info requested by original page that user is logged in to.
Am I missing any details? Is Yadis just a name give to this idea or will I need to install something to make sure it works correctly?
The term "Yadis" can be a little murky because it's referred to different things over the years, but more than anything it refers to the discovery phase of the protocol. That is, it answers this question: given an identifier (like http://keturn.example.com/ or xri://=keturn*example or whatever), what is the authentication server to use for this user? What version of the protocol does it support?
Which, if I read your situation correctly, is not at all what you're trying to address.
What you describe, authorizing one web service to act on behalf of the server with another, is more the domain of what OAuth is meant to address. But if you're stuck with your client's currently implemented auth protocol, I'm not sure that helps you either. But it's probably worth a look, it's not dissimilar from the solution you propose.
If I'm trying to secure my login method. From an unsecured server the user enters their login credentials into a standard HTML form, which is POSTing to a script on a secure server. This script does all the necessary login functions, and sends the user back to the insecure server.
My question boils down to this: Is the login information encrypted through SSL before it is POSTed to the secure server, therefore preventing any man-in-the-middle packet sniffing. Or is everything still being sent in the clear, and the form doing the POSTing has to be hosted on the secure server as well?
Thanks
If you post over SSL then the information will travel over the wire encrypted and will prevent packet sniffing.
Is it possible to also host the actual login form page on the secure server? That way when the user goes to log in to your site they can see that the login page is secured and they can be confident that their login information will be posted using SSL. Otherwise, the user is presented with an unencrypted page where they are asked to enter their credentials and they have no way (short of viewing the HTML source) to know if their information will be submitted using SSL.
Another question I have is how does the unsecured server "know" that the user has actually been authenticated with the secure server? If it is being done using cookies or a browser redirect (both of which will be unencrypted since the user is being sent back to the unsecured server) then that information will be easily read by anyone on the wire. This could be a security hole where the user's credentials are actually secure but your application/web site is not protected from being accessed by individuals who have actually not authenticated themselves.