Sign on several sites - php

i have 2 sites (example.com, ex2.com). Fisical is a 1 site with 1 db. When user sing in ex2.com, he was sing in example.com too. How do this?
P.S. Can do this with ZF?
I found a very interesting article on this topic. The author gives some ideas how to implement Multidomain authentication.
http://codeutopia.net/blog/2008/09/25/sharing-authentication-over-multiple-sites-single-sign-on/

Have you looked into OpenID? You could lock OpenID consumer "ex2" to allow logins only from your "example.com" OpenID provider.
I am also digging the subject. Some time ago, I already did my own implementation and got it terribly wrong.
At the moment I am wondering whether to setup an own OpenID provider and locking consumer sites to accept only it. Another alternative would be yet another own implementation with a CAS style setup, where only a hash is passed via the browser, and the user verification is done server-to-server in the background using the hash as a disposable key.
I am not yet sure which one to pick or would some third alternative be better.

You could take a look into something like http://cosign.sourceforge.net/. Cosign enables you to create a single point of login for multiple sites. It's not specific to Zend but should work.

Related

ASP.NET authentication for custom API

I know this is a pretty discussed topic but i'm struggling in finding a solution for my case.
I have done an already working API service in ASP.NET (c# 4.5.1). My clients uses php pages to call a page.aspx on my server and sending via POST a string. This string contains an ID and a cypher message. Every user have a different key (AES 256) and, since i have the ID i get from my DB the correct key to decypher the message and do what its request contains. I also check the IP, every client have only a list of approved IPs (when they are not using the debug mode for testing)
I like this method but now i have to let my users do some purchases. I already implemented it (thank you PayPal) and it works, but i feel my security weak.
So i wanted to add some already known and already wrapped authentication system, without re-writing any of the already working and debugged code.
Since is used from lot of big internet services i thought about OAuth 2.0 (and i know nothing about it), but looks like everyone who talks about it is for creating a login that uses services like Facebook, Google, Twitter and go on.. not my case. I have my own database with my user list and i need to know with 100% security who is calling my API service.
I tried creating a new Web API 2 project (MVC.. damn) but i cannot understand if i can use for my service without rewriting the logic for API calling (and from what i saw looks like no is the answer)
So the question is: What authentication method can i use that is easy to implement without rewriting the already working code and can be usable from clients with PHP?
I was watching "ASP.NET MVC 5 Fundamentals" tutorial on Pluralsight by Scott Allen where he explains it quite nicely. But before watching that tutorial, for one App I worked on, we had a table in the database with tokens that were issues at Login. Then the client would send the token with their request. At server side, I did a custom attribute called [CheckToken] inside which I would check if the token exists in the database and if it is stil valid (not expired, etc.) I went a step further and sometimes swap the token so that even if the token gets stolen, it would not be valid for long. That way, the user does not have to keep login in all the time.

Tips for reliable OpenID with your own domain

I'm trying to build a personal OpenID-based online identity using my domain name as identifier. I want to be able to accomplish all this:
Make http://alvaro.es/ my identifier.
Be able to switch providers transparently.
Log into any third-party site that accepts OpenID.
Be able to provide personal details (e-mail, time zone, avatar...) and get prompted whether to send them or not to sites that request them.
Accept OpenID in my own (PHP-powered) sites without the need of purchasing SSL hosting.
I've read the usual doc and I've been evaluating several OpenID providers (Google, Yahoo, myOpenID... and even running my own server). The fact is that I've been using OpenID for a while and:
Providers offer very scarce documentation or none at all.
No matter what provider I choose, there are always sites where log-in fails (typically without an error message).
I have little control (or none at all) on the identifier returned by the provider.
I still can't understand how all this really works.
I'm looking for general advice but I understand that can be subjective so I'll make a few specific questions.
So far, I'm trying out myOpenId as provider and LightOpenID as consumer. My questions are:
My URL provides an HTTP header:
X-XRDS-Location: http://kalvaro.myopenid.com/?xrds=1
... and the following HTML tags:
<link rel="openid.server openid2.provider" href="http://www.myopenid.com/server">
<link rel="openid.delegate openid2.local_id" href="http://kalvaro.myopenid.com">
Is it correct? Is it enough?
myOpenID provides Your Domains, a feature to register your own domain name but I haven't dared to test it (it needs changes to the DNS) and the configuration form suggests I have to choose between http://openid.alvaro.es/username and http://username.alvaro.es/ as identifier (not http://alvaro.es/). However, Stackoverflow still reports alvaro.es as my identifier without this feature. Do I need to use it?
When implementing LightOpenID, I match the local user against $openid->identity (where $openid is the instance of the LightOpenID object). This attribute appears to be the URL supplied by the user. Is it correct?
Are there more adequate providers or consumer libraries than the ones I chose?
It is correct. It is more than enough. While providing an X-XRDS-Location is a good thing, as it sepeeds up the discovery process, it isn't sctrictly necessary.
As far as I understand it, "Your Domains" is useful when you want to have multiple accounts in your domain. Anyway, you don't need to use it at all.
It is correct. The url is also called a Claimed Identifier, i.e. what the user claims to be.
As the author of LightOpenID, my answer is obvious and possibly biased -- I've created it, because I couldn't find a good, existing library.
Other things you might want to know:
Delegation won't work with Google, and any other provider who uses select_identifier (i.e. each account has the same url, and then the provider asks you for your login).
Your delegation, as shown in 1., will let you switch providers transparently and log in to any site that supports OpenID, just as you want.
As for the personal details, it depends completely on the provider, whether it sends them or not, what kind of personal information it supports, etc.. For example, Google doesn't let you choose what to send, only whether to send something (and everything the website claims to require) at all.
Some implementations are buggy and indeed fail. Try logging in for a second time, it works sometimes.
The identifier returned by your provider shouldn't matter if you use delegation. The website you're logging into should use your claimed identifier.
As for how the openid works, see some answers to that question on SO.

OpenID -- getting user information?

I am wondering if it is possible to request more information besides email from Google and get the name of the user also?
Am using JanRain OpenID PHP script.
Thank you
No, it isn't possible. Google only releases the user's email address. Their server is set up to never give out any more information than that:
See their OpenID page for developers to learn more:
http://code.google.com/apis/accounts/docs/OpenID.html
Search for OpenID Attribute Exchange -- that's what you want.
basic overview
formal specification
We haven't looked at it in a while (6 months?) but it was quite rough when we did. Hopefully things have improved since then.
More resources:
http://www.google.com/search?q=openid+attribute+exchange
I normally read the manual only when truly defeated. For 3 days, I have tried different ways to fetch user attributes from those two giant OpenID providers, but only managed to fetch the "email" attribute from Google and absolutely nothing from Yahoo. And then I had to read the dreaded manual, even those vague OpenID specifications.
So why implement a standard and not fully support it? Why pretend that there is any viability to OpenID if the big parties will not cooperate with the smaller parties when it comes to information exchange.
I guess the basic sign up and sign in process wins after all... Who really needs to know about XRIs and URLs anyway?
You're not supposed to rely on any user information anyway. See if it's part of the OP's reply, and if it isn't, provide the user with a form where he can complete the required fields.

Best Way to handle/consolidate multiple Logins?

this is the scenario:
multiple web systems (mostly lampp/wampp) exist, most of them with separate login information, (some share it). We're considering the benefits/disadvantages of unifying them somehow, or at least making handling the user administration parts easier.
Due to the nature of some systems (its a mixed bag of custom OSS systems,internally developed software and 3rd party commercial software) we can't unify all login-screens into a single screen.
A idea passed around is a sort of login master brain were we can control all user name creation,permissions,inactivation, etc. This will still make people have to manually log in into every system, but at least it'll make the administrative load of user management easier.
Are there any known solutions to this kind of problem that involves (necesarily, it could be considered) changing the least amount of code/systems possible?
Edit: OpenID doesnt work for us since we have different login needs and some systems we cant directly control how they handle the login process (but we can control the users/passwords).
What we did was to centralise all login details in one repository (Active Directory for us), then wrote a c# library to authenticate with wrappers for all the languages we programmed in (PHP, C, .NET, etc). and then just wrote some glue code in the appropriate place for each application. Aside from our in-house apps, we successfully logged into Mediawiki, Subversion, ActiveCollab and Apache this way.
It does involve writing a reasonable amount of code, but not ridiculous amounts, and it will work for the future as well. I can't see a practical solution which would be easier than this.
Reading your question I note that this is more-or-less what you're thinking anyway, but it will work!
There is a big industry around it and it is called IAM - Identity Access Management. The IAM solutions basically do what You want - manager users, user permissions and translate their internal state to the multitude of systems. Depending on possibility of integration, You might have a "SSO" - Single Sign On for some software or You could have Single Source of Authentication. The former differs from later in the fact that with SSO user needs in to punch the credentials once, while the in the later he only has same login and password combo.
Also IAM would manage to extent of its possibilities user rights. For example, a network equipment can only support one user/password. Then IAM solution would automatically open a terminal and log on the user, when he/she requests it; assuming the user is in the right security group.
Implementing an IAM solution could go a long way to ease systems management.
I can't recommend any particular solution, just bear in mind that transition from current method to IAM will require more than integration with different software, but also some change in corporate culture as one system will bind all others.
A lot of people seem to like OpenID for this sort of thing. I'm not sure on it's intranet capabilities though.
Another idea is using your "brain" system to pass authenticated username to the sister/brother applications as a form post, then handle authentication on that system and create their security tickets with what was sent.
Hope you find what you're looking for!
Cheers!

Login Integration in PHP

In my host, I currently have installed 2 wordpress applications, 1 phpBB forum and one MediaWiki.
Is there a way to merge the login so that all applications share the same credentials?
For instance, I want to register only in my phpBB and then I want to access all other applications with the given username and password.
Even if you don't know a unified way, what other login integration do you know of? Pros and cons of each?
when you integrate the system. Just remember 2 things:
Login to system
Check username/password with both systems.
Change of Password
Update the password on both systems.
I don't know how to share the session cookies, but you can easily share the same login.
i.e. People will need to log separately into both sites, but will be able to use the same username and password.
In the mediawiki file "LocalSettings.PHP", you can tell it to use a different (wordpress) database for authentication:
e.g.
require_once('includes/AuthPlugin.php');
require_once('extensions/AuthPress.php');
$wgAuth = new AuthPress();
$wgAuth->setAuthPressTablePrefix('evo_');
# Only include the following if you aren't using the same db as MediaWiki
$wgAuth->setAuthPressDBServer ('localhost');
$wgAuth->setAuthPressDBName('yourWordPressDB');
$wgAuth->setAuthPressUser('mySQL user for same');
$wgAuth->setAuthPressPassword('The password');
See http://bbpress.org/forums/topic/mediawiki-bbpress-and-wordpress-integration
One option is OpenID, which you can integrate into phpBB, WordPress, and MediaWiki.
A second option is to set up an LDAP server, which you can also integrate into phpBB, WordPress, and MediaWiki.
If the sites are all on the same root domain, a third option is to modify the registration, login, and logout code so that these actions are replicated on every site at the same time. This gets messy, but it may be the easiest short-term solution if you're in a hurry. Once you track down the account code in each site, it's just a matter of copying and pasting and changing a few cookie parameters.
If you're integrating a bunch of different apps, and you really just want a bridge, I've had good success with the bridge from Single-Signon.com. You can see there supported apps here:
http://www.single-signon.com/en/applications.html
I've also used a MediaWiki extension for phpBB integration:
http://www.mediawiki.org/wiki/Extension:PHPBB/Users_Integration
I once did a phpBB/MediaWiki login integration from the phpBB end.
Check it out.
Having tried to do this some years ago I remember it not being very easy.
The way I did it was to create totally new table to user/pass and then replace these columns in the respective software with foreign keys to your new table - this required a lot of custom tweaking of core files in each application - mainly making sure all SQL requests to this data have the extra join needed for your new table. If I find the time I will maybe try and provide a step by step of the changes needed.
There are some pretty big drawbacks to this approach though. The main one being from now on your gonna have to hand update any patches
If you have no content or users yet look at http://bbpress.org/documentation/integration-with-wordpress/ which will make things a lot simpler for you.
I can't quite remember but I believe that I big problem I had was that MediaWiki requires usernames formatted a certain that conflicted with phpBB.
Of course, a totally different approach would be to mod each piece of software to use OpenID _ I believe plugins/extensions are readily available for all the applications you mentioned.
I personally think that integration login systems is one of, if not the, hardest job when utilizing multiple prebuilt applications. As a fan of reuse and modularity, I find this disappointing. If anyone knows of any easy ways to handle this problem between random app X and random app Y, I would love to know.
You can write a custom login hook for mediaWiki. I've done it for LibraryThing so that login credentials from our main site are carried over to our mediaWiki installation. The authentication hook extends mediaWiki's AuthPlugin.
There are several small issues:
mediaWiki usernames must start with initial caps (so if you allow case sensitive user names it could be a problem if two users have colliding wiki names)
underscores in usernames are converted to spaces in mediaWiki
But if you can deal with those then it is certainly possible to use your own user/password data with mediaWiki.
Advantages:
The user doesn't have to login to each area separately. Once they login to the main site they are logged into the wiki also.
You know that usernames are the same across the systems and can leverage that in links, etc.

Categories