I want to log onto Stack Overflow using OpenID, but I thought I'd set up my own OpenID provider, just because it's harder :) How do you do this in Ubuntu?
Edit: Replacing 'server' with the correct term OpenID provider (Identity provider would also be correct according to wikipedia).
You might also look into setting up your own site as a delegate for another OpenID provider. That way, you can use your own custom URL, but not worry about security and maintenance as mentioned already. However, it's not very difficult, so it may not meet your criteria :)
As an example, you would add this snippet of HTML to the page at your desired OpenID URL if you are using ClaimID as the OpenID provider:
<link rel="openid.server" href="http://openid.claimid.com/server" />
<link rel="openid.delegate" href="http://openid.claimid.com/USERNAME" />
So when OpenID clients access your URL, they "redirect" themselves to the actual provider.
I've actually done this (set up my own server using phpMyID). It's very easy and works quite well. One thing that annoys me to no end is the use of HTML redirects instead of HTTP. I changed that manually, based on some information gotten in the phpMyID forum.
However, I have switched to myOpenId in the meantime. Rolling an own provider is fun and games but it just isn't secure! There are two issues:
More generally, you have to act on faith. phpMyID is great but it's developed in someone's spare time. There could be many undetected security holes in it – and there have been some, in the past. While this of course applies to all security-related software, I believe the problem is potentially more severe with software developed in spare time, especially since the code is far from perfect in my humble opinion.
Secondly, OpenID is highly susceptible to screen scraping and mock interfaces. It's just too easy for an attacker to emulate the phpMyID interface to obtain your credentials for another site. myOpenId offers two very important solutions to the problem.
The first is its use of a cookie-stored picture that is embedded in the login page. If anyone screen-scapes the myOpenId login page, this picture will be missing and the fake can easily be identified.
Secondly, myOpenId supports sign-in using strongly signed certificates that can be installed in the web browser.
I still have phpMyID set up as an alternative provider using Yadis but I wouldn't use it as a login on sites that I don't trust.
In any case, read Sam Ruby's tutorial!
I personnally used phpMyID just for StackOverflow. It's a simple two-files PHP script to put somewhere on a subdomain. Of course, it's not as easy as installing a .deb, but since OpenID relies completely on HTTP, I'm not sure it's advisable to install a self-contained server...
Take a look over at the Run your own identity server page. Community-ID looks to be the most promising so far.
I totally understand where you're coming from with this question. I already had a OpenID at www.myopenid.com but it feels a bit weird relying on a 3rd party for such an important login (a.k.a my permanent "home" on the internet).
Luckily, It is easy to move to using your own server as a openID server - in fact, it can be done with just two files with phpMyID.
Download "phpMyID-0.9.zip" from http://siege.org/projects/phpMyID/
Move it to your server and unzip it to view the README file which explains everything.
The zip has two files: MyID.config.php, MyID.php. I created a directory called <mydocumentroot>/OpenID and renamed MyID.config.php to index.php. This means my OpenID URL will be very cool: http://<mywebsite>/OpenID
Decide on a username and password and then create a hash of them using: echo -n '<myUserNam>:phpMyID:<myPassword>' | openssl md5
Open index.php in a text editor and add the username and password hash in the placeholder. Save it.
Test by browsing to http://<mywebsite>/OpenID/
Test ID is working using: http://www.openidenabled.com/resources/openid-test/checkup/
Rerefence info: http://www.wynia.org/wordpress/2007/01/15/setting-up-an-openid-with-php/ , http://siege.org/projects/phpMyID/ , https://blog.stackoverflow.com/2009/01/using-your-own-url-as-your-openid/
The above answers all seem to contains dead links.
This seems be a possible solution which is still working:
https://simpleid.org/
Related
I'm working on a little node.js-project, and while googling alot, I kinda got a bit confused, but maybe some of you are able to point me towards the road again.
Several websites are generated by DocPad (excellent piece of software), and hosted on different domains.
All these websites shall now get a "login module" (which is also written in Node.js, using passport). Visually, it will look similar to the excellent login-slider from Web-Kreation (Here a demo). My plan was to use nginx and route all the /login-requests to the login-app, which is working fine.
The problem is rather related to the multiple domains, and the clientside implementation of it all. All logins use the same database.
Can I somehow use both together, and create the session-cookies from the Login-Module (which could use the same domain all the time)?
I'm answering my own question for reference, in case someone else comes across the same problem.
In the end, I solved my problem by having a bit of a different setup. Instead of a module, using the dns of each page, I use a central login-application for all sites. The sites itself do not require to access any personal information, so that's not a problem.
DocPad is still being used to generate the different websites (works excellent - I know I say this very often, but if there's a brilliant piece of software out, there's no reason to not mention it once in a while) statically, and all static content is delivered to the user using a CDN.
The login-system is a node.js-application using Redis as the only database. It is integrated via a simple iframe on all pages rendered by DocPad on login.example.com.
After successful login in 'login-app' you can create encrypted string with info about current user. You can pass this string back in get/post parameter with redirect to necessary domain. Encription key is known only to the 'login-app' and your websites. You can trust this encrypted data. It is necessary to make sure that every time the key is different for the same user. For example you can add the information about the time of login or random. After decrypting the data you can set authorization cookie for a particular domain.
I have a (legit) edge case where I would like to download a web page using any command line tool, but the web page needs an OpenID login to show the content I need.
wget supports basic auth and FTP, but I can't think of a sane way to use it in conjuction with an OpenID login. The only way I can think of
Perform an OpenID login using wget
Somehow store the resulting session cookie
Try to fetch the page using another wget call, and --load-cookies the cookies from the last call
this seems complex to build, though, as IIRC the OpenID login process is not entirely as straightforward as your plain old web site login. Does anyone either
know a less complex way (performing the OpenID login manually somewhere else would be completely acceptable)
know a ready-made implementation of what I describe above? I'm keen on avoiding having to build this from scratch if at all possible.
Other inspirations are welcome as well.
I can work either on Linux or on Windows. Linux would be preferred from an infrastructure point of view but either platform is fine.
performing the OpenID login manually somewhere else
Well the best I can think of is to use any browser for logging in to whatever service you want. The service will then preserve your "state" somehow in a cookie at your browser.
Get that cookie, e.g. store it at cookie.txt and pass it in the header
wget --header="Cookie: $(cat cookie.txt)" http://...
as long as the session is valid, you can use the wget script. Should work for 99% of all cases, thought probably not for online banking (if it does... switch banks immediately :-P)
I own this website : http://www.[my site].com/ and I have a forum for it : http://www.[my site].com/vb
I want to mix both so ... if somebody logged in from the website he will login in the forum.
my problem is that the forum user login ... uses an md5 password encoding but it is different than the md5 password incoding in my website ... how I can make both of them use the same encoding ? btw ... the forum template is too complicated.
note : I did combine both templates on one database.
One approach is use the "Proxy Connect" approach pioneered by Vanilla forums:
http://vanillaforums.org/docs/singlesignon
Another approach, since I assume the VB in your forum's link stands for vBulletin, is to look for an SSO (sing sign on) plug in or a developer to assist with this process.
You say that you "combined both templates on one database". I'm not sure what this means but you should be able to delve into the code and encrypt passwords in the same way....or combine/mirror the password for each user's forum password with the password on the main site. The proxy connect approach outlined above is probably better.
Finally, you could do nothing at this time and wait to see if your forum catches on. If you are able to get traction then perhaps it warrants an investment in time/money to streamline the sign on. However, in my experience, users have no qualms about creating a separate account to join a forum provided with fresh and compelling content. I'd focus your energy on seeding the forum and making it interesting/active/lively.
Good luck!
I would like to cache my website with memcache as much as possible. There are rare modifications (somewhat like in a forum) which I am perfectly ok with re-caching once change is made. My only concern is login information (similar to how stackoverflow has a bar on top). This is how I am doing it right now:
$('div#user_bar').load('/login-info/');
(jQuery on a fully cached page loads up userinfo)
However, I think I can do without dynamic pages completely. My idea is this:
On login: create cookie `logged_in`:true
On each page: if JS finds cookie is set: show links to logout, settings, etc
if not: show link to login page
On logoff: delete cookie
No actual userinfo is stored in cookies, not even username.
How secure, reasonable, sane is this? Any ideas? Am I missing something? Thank you.
Disclaimer: This is more of an exercise than a production environment. But I am trying to keep security and performance in mind nonetheless.
About your main target: Caching dynamic pages is reasonable. If you work on the ASP.NET platform, you might want to have a look at the output cache feature which does exactly this, even including dynamic substitutions. 4 Guys from rolla.com have a nice starter article with links to all the details.
Regarding the non-userspecific pages: I doubt that this can work for anything but the most simple pages. Web applications usually allow different operations for different users, and if it's only the change of your password. You probably have to pass specialized content to the client at some point, and that's where the dynamic substitutions of the ASP.NET output cache come into play.
What are some good suggestions or resources to look at to help me secure a single click URL based authentication?
Essentially, the situation is a third party system which accepts an HTTPS request, through the browser, where you supply authentication information (un, pw, authkey, etc...). The service then, upon authenticating the provided credentials, will allow or deny login access. The point being, that if someone clicks on the link, they're automatically granted access to this third party system.
Currently, there isn't a whole lot of security surrounding the whole process, (which isn't a big deal because the product isn't in production yet) and the third party is willing to make some modifications to secure this up a bit.
I've already determined I need to hash the information, and probably even submit it via a POST to prevent it from showing information in the browser history. But I'd like a little input on how you all would handle something like this.
[Edit: Requests are and will continue being sent via HTTPS. I also modified the HTTP previously used to be HTTPS]
Don't think about "secure this up a bit". It's either secure from the ground up, or it's got holes that will cost you dearly.
Look at HTTP Digest Authentication. It's simple, reliable and works well under most circumstances.
Look at the OWASP.org top-10 vulnerabilities. Be sure you understand and address each one.
You should probably use HTTPS to avoid the credentials being eavesdropped upon while in transit to the third party web server.
Protect yourself from using stale link to gain access to the application. Make the link be dependent on current time value