Sacco,
You need to use an X.509 wildcard cert for authenticated SSL.
They are easy to create/buy, and browsers work with them nicely.
If you want to experiment with this yourself, just install openssl;
when you get to the step of creating the actual certificate request,
you'll do something like this:
You'll be asked to specify the "Common Name" (or "CN") in the key
signing request; just use a wildcard at the appropriate subdomain
level (e.g.: *.your-virtualization-domain ). It's that simple.
It works like any other cert. If you want more info on creating
certs, SSL, or anything else, let me know. Would a wiki page on
this topic be helpful to you?
Did you have any other specific concerns, or was that it?
As for your questions regarding hostname vs request path
virtualization, there are many reasons why using request paths
is the "greater evil". For starters, it means that every single
integration for which you forward-proxy must embed a custom
plugin that duplicates the same logic for internal subrequests
(e.g.: SSIs). You also lose the contents of POSTS across
redirects, unless you cache these arbitrarily long POST bodies
across redirects for N clients in parallel, thereby exposing you
to a range of scalability issues & and potential security problems.
Even then, you'd *still* have to rely upon cookies because when pages
contain frames, some browsers get confused and send back bogus
"Referer" headers, thereby busting virtualization. Path-based
virtualization also uses network resources less well, due to the
large number or redirects required to keep requests in
"cannonical request-path-mangled form"; if you don't do this,
subsequent clicks end up with the wrong "Referer" if you traverse
a link of the form href="/…" (thereby propagating the wrong value
into your cookie).
Of course, there are some things that cannot be virtualized transparently
no matter what you do, such as a webapp that relies upon a singleton
(e.g.: a modifiable database table. However, all systems share this
limitation. In cases like this, you no system can be totally transparent;
you'll have to write custom code to handle it. That said, this is not
usually a big issue in practice, because if you want to do hard-core testing
of something like a personalization engine, you're probably going to
deploy your site to a testing box anyhow. Seeing the html, images,
jsps, etc. is usually plenty for the collaborative phase of development.
If you want to do something fancy like virtualize a website that contains
links of the form href="http:/…", that's quite easy to do. Your site
probably does not (and should not) contain many links of this form,
but just in case you need to deal with them, there are a few different
techniques available. Rather than re-hash these techniques here,
have a look at my earlier discussion of this topic:
http://issues.alfresco.com/browse/WCM-128
As for http://issues.alfresco.com/browse/AWC-1140 , that is an issue
with the Alfresco webapp itself, not the virtualization server.
These are different programs, and they do very different things.
You can't be "in two places at once" within Alfresco's GUI,
but you *can* be in arbitrarily many places at once when it comes
to viewing/surfing the website(s) this GUI has helped you to create.
When start providing fancier review tasks in our workflow system,
the power this gives you will become much more obvious.
At the moment, our workflows are rather simple; it's our first release,
and a lot of what's "under the hood" has not been exposed yet.
It will be.
There are a lot of subtle issues here, and I realize I'm covering them
at a brisk pace. You are asking some great questions. It might be
time to write a wiki article on wildcard SSL certs, even if my rather
terse explanation here is adequate for you; it might not be for others.
Alfresco's enterprise customers have been very happy with our
approach to virtualization, but then they have the benefit of talking
and/or meeting with its architect/developer (i.e.: me!), and getting
a guided tour. Over the next few days & weeks, I'll try to spruce up
the wiki to bring at least some of that to everybody else.
If you have any other questions, please post them.
Cheers,
- Jon
You need to use an X.509 wildcard cert for authenticated SSL.
They are easy to create/buy, and browsers work with them nicely.
If you want to experiment with this yourself, just install openssl;
when you get to the step of creating the actual certificate request,
you'll do something like this:
openssl req -new -x509 -keyout demoCA/private/cakey.pem -out demoCA/cacert.pem -days 3652
You'll be asked to specify the "Common Name" (or "CN") in the key
signing request; just use a wildcard at the appropriate subdomain
level (e.g.: *.your-virtualization-domain ). It's that simple.
It works like any other cert. If you want more info on creating
certs, SSL, or anything else, let me know. Would a wiki page on
this topic be helpful to you?
Did you have any other specific concerns, or was that it?
As for your questions regarding hostname vs request path
virtualization, there are many reasons why using request paths
is the "greater evil". For starters, it means that every single
integration for which you forward-proxy must embed a custom
plugin that duplicates the same logic for internal subrequests
(e.g.: SSIs). You also lose the contents of POSTS across
redirects, unless you cache these arbitrarily long POST bodies
across redirects for N clients in parallel, thereby exposing you
to a range of scalability issues & and potential security problems.
Even then, you'd *still* have to rely upon cookies because when pages
contain frames, some browsers get confused and send back bogus
"Referer" headers, thereby busting virtualization. Path-based
virtualization also uses network resources less well, due to the
large number or redirects required to keep requests in
"cannonical request-path-mangled form"; if you don't do this,
subsequent clicks end up with the wrong "Referer" if you traverse
a link of the form href="/…" (thereby propagating the wrong value
into your cookie).
Of course, there are some things that cannot be virtualized transparently
no matter what you do, such as a webapp that relies upon a singleton
(e.g.: a modifiable database table. However, all systems share this
limitation. In cases like this, you no system can be totally transparent;
you'll have to write custom code to handle it. That said, this is not
usually a big issue in practice, because if you want to do hard-core testing
of something like a personalization engine, you're probably going to
deploy your site to a testing box anyhow. Seeing the html, images,
jsps, etc. is usually plenty for the collaborative phase of development.
If you want to do something fancy like virtualize a website that contains
links of the form href="http:/…", that's quite easy to do. Your site
probably does not (and should not) contain many links of this form,
but just in case you need to deal with them, there are a few different
techniques available. Rather than re-hash these techniques here,
have a look at my earlier discussion of this topic:
http://issues.alfresco.com/browse/WCM-128
As for http://issues.alfresco.com/browse/AWC-1140 , that is an issue
with the Alfresco webapp itself, not the virtualization server.
These are different programs, and they do very different things.
You can't be "in two places at once" within Alfresco's GUI,
but you *can* be in arbitrarily many places at once when it comes
to viewing/surfing the website(s) this GUI has helped you to create.
When start providing fancier review tasks in our workflow system,
the power this gives you will become much more obvious.
At the moment, our workflows are rather simple; it's our first release,
and a lot of what's "under the hood" has not been exposed yet.
It will be.
There are a lot of subtle issues here, and I realize I'm covering them
at a brisk pace. You are asking some great questions. It might be
time to write a wiki article on wildcard SSL certs, even if my rather
terse explanation here is adequate for you; it might not be for others.
Alfresco's enterprise customers have been very happy with our
approach to virtualization, but then they have the benefit of talking
and/or meeting with its architect/developer (i.e.: me!), and getting
a guided tour. Over the next few days & weeks, I'll try to spruce up
the wiki to bring at least some of that to everybody else.
If you have any other questions, please post them.
Cheers,
- Jon
