Today Patrick got the trac plugin for openid working pretty well with the new openid service. This effectively breaks our tight bind to the fas db (and mod_auth_pgsql) from the hosted boxes.
A while back we discussed the possibility of scaling the hosted service out horizontally somewhat by being able to break the projects up into chunks of data.
We said we'd need folks to refer to their sites with something like:
projectname.fedorahosted.org
so we could direct them to the right machine via dns on the backend. And we could then more easily add capacity as needed.
One thing we've been doing is running fedorahosted behind https. Part of that is b/c we were doing a basic-auth to pgsql to auth against fas. With openid that won't be an issue anymore.
The second reason is for personal/private/confidential items in tickets or what-not - for example the board trac instance. To that I suggest we bottle up the board trac instance, stuff it somewhere we can put an ssl cert in front of it and move along.
For the rest we make them non-ssl'd. The openid login, of course would be ssl'd, but the rest of the site doesn't really need to be, does it?
So we'd still need to get people to refer to the right urls. I don't think that would be likely to happen over night but we can at least start doing so, right?
What we get: 1. we get the possibility of not having all of our eggs in the one basket of serverbeach and the two hosted instances running now 2. we can possibly gain performance by getting some of the data off of the one big gluster dastastore. 3. we gain the ability to setup a 'newhosted' server, put a few trac/git/etc instances over there and try things out w/o breaking all the rest of them. 4. If we suddenly find we have a single, extremely popular project (good problem to have imo) then we can give it a dedicate instance and maintain performance.
Does anyone like this idea? Is anyone opposed to it? Got criticisms that sould be addressed? Things I'm completely blanking about?
let me know.
Thanks, -sv
On Wed, 13 Feb 2013 01:52:15 -0500 (EST) Seth Vidal skvidal@fedoraproject.org wrote:
Today Patrick got the trac plugin for openid working pretty well with the new openid service. This effectively breaks our tight bind to the fas db (and mod_auth_pgsql) from the hosted boxes.
Hurray! Three cheers.
A while back we discussed the possibility of scaling the hosted service out horizontally somewhat by being able to break the projects up into chunks of data.
Yep. I think it's still a good idea.
We said we'd need folks to refer to their sites with something like:
projectname.fedorahosted.org
so we could direct them to the right machine via dns on the backend. And we could then more easily add capacity as needed.
One thing we've been doing is running fedorahosted behind https. Part of that is b/c we were doing a basic-auth to pgsql to auth against fas. With openid that won't be an issue anymore.
The second reason is for personal/private/confidential items in tickets or what-not - for example the board trac instance. To that I suggest we bottle up the board trac instance, stuff it somewhere we can put an ssl cert in front of it and move along.
For the rest we make them non-ssl'd. The openid login, of course would be ssl'd, but the rest of the site doesn't really need to be, does it?
I think we could also look at getting a wildcard cert and just stay with https. But I agree thats a detail... either way is probibly fine.
So we'd still need to get people to refer to the right urls. I don't think that would be likely to happen over night but we can at least start doing so, right?
Yep.
What we get:
- we get the possibility of not having all of our eggs in the one
basket of serverbeach and the two hosted instances running now 2. we can possibly gain performance by getting some of the data off of the one big gluster dastastore. 3. we gain the ability to setup a 'newhosted' server, put a few trac/git/etc instances over there and try things out w/o breaking all the rest of them.
I think we might want to setup a hosted01.stg at some point for testing things out. It would be good to be able to do that without bothering production. If we split projects out we could also have some direct to the staging instance too.
- If we suddenly find we have a single, extremely popular project
(good problem to have imo) then we can give it a dedicate instance and maintain performance.
Yep.
Does anyone like this idea? Is anyone opposed to it? Got criticisms that sould be addressed? Things I'm completely blanking about?
So, would these hosted instances be something good for persistent cloud? Or do you think they would be better as regular vhosts? I think it might be nifty to at least have the ability to spin them in cloud instances so we could rapidly move/add things to that (think of a slashdot day for a project, we could move them to a big cloud instance and then move them back to the regular vhost after it was calmed down).
kevin
On Wed, 13 Feb 2013, Kevin Fenzi wrote:
I think we could also look at getting a wildcard cert and just stay with https. But I agree thats a detail... either way is probibly fine.
<shrug> I'm fine with either way.
I think we might want to setup a hosted01.stg at some point for testing things out. It would be good to be able to do that without bothering production. If we split projects out we could also have some direct to the staging instance too.
Any reason not to do that in a cloud instance - heck doesn't even need to be called 'staging' it is just staging projects.
We can even prototype fedorahosted.org/projectname redirects in that way.
So, would these hosted instances be something good for persistent cloud? Or do you think they would be better as regular vhosts? I think it might be nifty to at least have the ability to spin them in cloud instances so we could rapidly move/add things to that (think of a slashdot day for a project, we could move them to a big cloud instance and then move them back to the regular vhost after it was calmed down).
EXTREMELY popular - could mean we dump them out to a public cloud instance and/or spread it out to other colos to get the load off of phx2, for example.
We'll need to make our dns changes a bit more agile, I suspect. And I also suspect we'll want to talk about making the mechanism for updating cloud.fedoraproject.org and fedorahosted.org more template driven and local-db-driven.
So instead of editing a file by hand you just add a projectname and a hostname to a db/file and git commit/push.
so much to do.
-sv
On Wed, Feb 13, 2013 at 01:52:15AM -0500, Seth Vidal wrote:
For the rest we make them non-ssl'd. The openid login, of course would be ssl'd, but the rest of the site doesn't really need to be, does it?
I guess if fedorahosted is not used via HTTPS, attackers could easily make users not use HTTPS for the openid login by tampering the response from fedorahosted. Also there is probably a session cookie involved that is validated via openid, this could still be used by attackers to access fedorahosted with the privileges of the original user.
Regards Till
On Wed, Feb 13, 2013 at 10:58 PM, Till Maas opensource@till.name wrote:
On Wed, Feb 13, 2013 at 01:52:15AM -0500, Seth Vidal wrote:
For the rest we make them non-ssl'd. The openid login, of course would be ssl'd, but the rest of the site doesn't really need to be, does it?
I guess if fedorahosted is not used via HTTPS, attackers could easily make users not use HTTPS for the openid login by tampering the response from fedorahosted.
The only way an attacker could make users not use HTTPS would be by sending them to another OpenID provider, which the authopenid plugin, and thus trac, then won't allow (it will only allow FAS-OpenID). It would be possible to launch a phishing attack indeed, but that can happen with any website, and that is already limited because with OpenID, the user can check the URL in the address bar, as there will be only one domain (id.fedoraproject.org) that will ask for username/password, instead of many.
Also there is probably a session cookie involved that is validated via openid, this could still be used by attackers to access fedorahosted with the privileges of the original user.
There is no session cookie validated by OpenID: the OpenID server provides a signed response to the relying party (hosted in this case), which the relying party checks with the provider itself without the user's (or attacker's) control. Stealing a cookie would still be possible indeed, but that's also not induced by the use of OpenID, just (again) because the cookie is sent in the clear.
Regards Till
I hope this clears it up, and if it doesn't, you can always ping me on IRC or email.
Yours sincerely, Patrick Uiterwijk
On Wed, Feb 13, 2013 at 11:18:27PM +0100, Patrick Uiterwijk wrote:
Stealing a cookie would still be possible indeed, but that's also not induced by the use of OpenID, just (again) because the cookie is sent in the clear.
I agree here. But this does mean that trac should still be accessed via ssl. There's no way around that unless the application itself (trac) didn't rely on its own session cookie.
-Toshio
On Wed, Feb 13, 2013 at 11:18:27PM +0100, Patrick Uiterwijk wrote:
On Wed, Feb 13, 2013 at 10:58 PM, Till Maas opensource@till.name wrote:
On Wed, Feb 13, 2013 at 01:52:15AM -0500, Seth Vidal wrote:
For the rest we make them non-ssl'd. The openid login, of course would be ssl'd, but the rest of the site doesn't really need to be, does it?
I guess if fedorahosted is not used via HTTPS, attackers could easily make users not use HTTPS for the openid login by tampering the response from fedorahosted.
The only way an attacker could make users not use HTTPS would be by sending them to another OpenID provider, which the authopenid plugin, and thus trac, then won't allow (it will only allow FAS-OpenID). It would be possible to launch a phishing attack indeed, but that can happen with any website, and that is already limited because with OpenID, the user can check the URL in the address bar, as there will be only one domain (id.fedoraproject.org) that will ask for username/password, instead of many.
Actually it is admin.fedoraprojet.org that will ask for the password. I assumed that if username.id.fedoraproject.org is used as OpenID ID, there would be some plain HTTP request from the user's browser to username.id.fedoraproject.org, but this does not seem to be the case (anymore?). Nevertheless, at least trac will probably not connect via HTTPS to username.id.fedoraproject.org, because the certificate for that host name is not valid. Nevertheless, an attack might not be that likely for that as as MITM attacks near a user's client are.
Regards Till
On Thu, Feb 14, 2013 at 10:13 PM, Till Maas till.maas@till.name wrote:
...
Actually it is admin.fedoraprojet.org that will ask for the password.
Well, if you see admin.fedoraproject.org requesting the password, you are probably using id.fedoraproject.org currently, which is still the current FAS module. FAS-OpenID (which is available as <username>.id.stg.fedoraproject.org) does not use admin.fedoraproject.org at all.
I assumed that if username.id.fedoraproject.org is used as OpenID ID, there would be some plain HTTP request from the user's browser to username.id.fedoraproject.org, but this does not seem to be the case (anymore?).
No, the user's browser won't request username.id.fedoraproject.org but only id.fedoraproject.org, but trac does this to verify that the OpenID endpoint indeed controls that specific URL.
Nevertheless, at least trac will probably not connect via HTTPS to username.id.fedoraproject.org, because the certificate for that host name is not valid.
That's also not used: for connection between trac and the OpenID provider, plain HTTP is used for verification.
Nevertheless, an attack might not be that likely for that as as MITM attacks near a user's client are.
Regards Till _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Well, if you see admin.fedoraproject.org requesting the password, you are probably using id.fedoraproject.org currently, which is still the current FAS module. FAS-OpenID (which is available as <username>.id.stg.fedoraproject.org) does not use admin.fedoraproject.org at all. There is only SSL in place for the login page, all other pages do not need SSL (because of the certificate wildcard level).
infrastructure@lists.fedoraproject.org
-
Kevin Fenzi -
Patrick マルタインアンドレアス Uiterwijk -
Seth Vidal -
Till Maas -
Till Maas -
Toshio Kuratomi