Menu
▾
▴
openportalguard-devel — Open Portal Guard development list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
(29) |
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(11) |
Oct
(5) |
Nov
(9) |
Dec
(5) |
| 2008 |
Jan
(8) |
Feb
(19) |
Mar
(26) |
Apr
(18) |
May
(11) |
Jun
(9) |
Jul
(9) |
Aug
(3) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bud P. B. <bu...@co...> - 2005-04-26 14:45:03
|
Thanks to help from the Apache users mailing list, here is a setup for
authenticating with a reverse proxy (i.e., OpenPortalGuard gate keeper).
Objective:
A reverse-proxy handles all the authentication for multilple application
servers behind the proxy. The application servers behave as if they had
handled the authentication themselves (with HTTP BASIC).
Requirements:
The described setup requires Apache 2.0 or higher on the remote proxy
(because only apache 2 adds the RequestHeader directive in
mod-headers). Currently, only Apache 1.3 has been tested as application
server--but higher versions of Apache should work too. It should be
independent on what application server is run (tested with cgi, but also
tomcat via mod-jk, php, quixote via mod-scgi, ecc. should work--this has to
be verified)
Authentication Methods:
Currently, the described setup has been tested with straight HTTP BASIC
Authentication. But I believe it should equally work for more useful
authentication methods including:
- HTTP BASIC over ssl with user DB on LDAP (mod-ssl with mod-ldap or
mod-auth-ldap)
- SSL with client-cert-auth and +fakeBasicAuth
ReverseProxy Setup:
the following directives are a simple test of a reverse proxy:
<Location /test1>
Allow from all
RewriteEngine on
#
AuthType Basic
AuthName "testRealm"
AuthUserFile /path/to/PwdFile
Require user bud ezio
#
# Set a HTTP request-header "OPG_USER" with the
# name of the authenticated user (REMOTE_USER)
#
RewriteCond %{REMOTE_USER} (.*)
RewriteRule .* - [E=OPG_USER:%1]
RequestHeader add OPG_USER "%{OPG_USER}e"
#
RewriteRule ^(.*) http://test1.myDomain.it/$1 [P,L]
</Location>
Application Server Setup:
The following directives make the Apache server behind the proxy set the
REMOTE_USER environment variable to the value set in the HTTP Header "OPG_USER"
RewriteEngine on
RewriteCond %{HTTP:OPG_USER} (.*)
RewriteRule .* - [E=REMOTE_USER:%1]
-b
-------------------------------------------------------------------------------------------------
Ing. Bud P. Bruegger, Ph.D. +39-0564-488577
(voice), -21139 (fax)
Servizio Elaborazione Dati e-mail: bu...@co...
Comune di
Grosseto http://www.comune.grosseto.it/cie/
Via Ginori,
43 http://OpenPortalGuard.sf.net
58100 Grosseto (Tuscany, Italy) jabber: bu...@am...
Free Software in Public Administration: not just a good idea, but a necessity
Perfection is attained, not when there is nothing more to be added, but
when there is nothing more to be taken away -- Antoine de Saint-Exupery
|
|
From: Bud P. B. <bu...@co...> - 2005-04-14 12:53:11
|
Not sure how much of an eID card the German eCard is (see http://europa.eu.int/idabc/en/document/4011/194). Does someone know? But its spec seems to follow a full disclosure approach: http://www.dimdi.de/de/ehealth/karte/download/egk_spezifikation_teil1_v1-2.pdf http://www.dimdi.de/de/ehealth/karte/download/egk_spezifikation_teil2_v1-0.pdf http://www.dimdi.de/de/ehealth/karte/download/egk_spezifikation_teil3_v0-9.pdf -b |
|
From: Bud P. B. <bu...@co...> - 2005-04-14 07:53:50
|
[I cross post to both, the opensc and the openportalguard lists since Amir's message was posted to both, and I copy to Jan who may be interested in the discussion] Hi Amir, thanks for starting an interesting topic! One thing that I would like to point out for people who didn't read the full paper (http://openportalguard.sourceforge.net/idabc2005.pdf) is that we are talking of a short to medium term solution for interoperability in which the middleware absorbs the diversity of national solutions. In the long term, standardization that achieves homogeneity of solutions in Europe should replace this and much simplify the problem of interoperability. Please read on below where I try to respond to some of the issues you raise. At 17.18 13/04/2005 +0200, Amir Hayat wrote: >Hello, > >I am doing a comparative study of OSS and Proprietary software used for >eID cards. In EU, we have about nine member states who are issuing eID >cards (though Malta and Denmark are not using smartcards in their >approach). These member states have their proprietary applications and >unfortunately these applications work only for their eID cards and are not >interoperable. I read a paper 'Open Source Solutions for Interoperability >in the eID domain' in which OSS is proposed as a better solution to >eliminate the interoperability issues. Besides the advantages, I am trying >to understand the limitations of this approach. I have figured out few >items for e.g. > >1. it needs a disclosure of the eID card specifications which some member >states are not willing to do at the moment. To harvest the full (mostly organizational) benefit of open source, you are correct that the card specifications need to be public. They already are for many countries: Belgium: http://www.rijksregister.fgov.be/eik/technische_specificaties/belgian_electronic_identity_card%20_content_v2.8.a.pdf . The official pkcs11 is based on OpenSC and has been released under the LGPL. Estonia: http://www.id.ee/pages.php/03021003,87 and it is already supported in OpenSC Finland: http://www.fineid.fi/download/S1v110.pdf, http://www.fineid.fi/download/S4-1v100.pdf, http://www.fineid.fi/download/S4-2v09.pdf, http://www.fineid.fi/download/s5-v09.pdf and this is the card for which OpenSC was first developed Italy has published the spec of the APDUs http://www.servizidemografici.interno.it/cnsd/settori/cie/competenze/apdu_110100.pdf but only the general structure of the file system http://www.servizidemografici.interno.it/cnsd/settori/cie/competenze/Schema_file_system_carta.pdf However, we (the Town of Grosseto) have officially requested the permission from our Ministry of the Interior to develop a multi-platform pkcs11 for the card under the LGPL (based on OpenSC). We received the permission to do so under an Non Disclosure Agreement and the Ministry will, after due verification, publish the code on their Open Source Repository. I don't have detailed information about the other countries and would be very grateful if you could add what you know. I believe that Spain keeps their specifications secret. One of the Austrian cards by A-Trust seems to refrain from publishing the spec but I heard that a person at A-Trust has the permission to develop and publish OpenSC support for the card and release it under the LGPL. On the standards side, to my knowledge there is full disclosure in both the European CEN TC224 WG 15 European Citizen Card (still work in progress but will be published) and the American NIST Integrated Circuit Card for Personal Identity Verification; see NIST Special Publication 800-73, http://csrc.nist.gov/publications/drafts/SP800-73-2ndDraft.pdf For the countries who refrain from publishing their specification but provide binary-only pkcs11 modules, I believe that OpenSC can already use these (can someone confirm this believe?). This would allow to support also "secret" cards. The problem with the approach is the complexity of managing binary modules for many cards in several versions for multiple operating systems (windows, linux, various BSDs, Mac OS X, ..) and multiple processors (intel, ia64, ppc, arm...). Maybe binary compatibility also depends on the versions of some main libraries (glibC...). So if we really want a single eID card per citizen for all purposes, the number of possible platforms to support is just enormous. This binary module "work around" would guarantee completeness of the solution. I'm also quite convinced that if enough countries go ahead with a the good example of following the full disclosure approach, considering that also standards bodies follow this route, and when the benefits of avoiding the huge complexity of managing binary modules will become evident in practise, then the other countries will eventually follow suite. A serious issue that I see with binary modules is trust and liability. I believe that most governments will want to issue official (integrated binary) distributions (for the various platforms) of the interoperable middleware. This means that they must trust that the included third-party (foreign) software deserves the official approval that is implicitly or explicitly given. I believe that the availability of source code makes it much easier to verify that all components of a distribution are really trustworthy. One advantage of source is that auditing is maybe easier and more thorough than running tests on a binary. The other advantage is that it is enough to audit a single source instead of multiple binaries (one for every platform and version). In this context, I would be interested in your opinion on whether there are dangers in publishing the specification of eID cards. >2. it needs the collaboration of all the member states which may take a while I believe that this issue is not specific to open source. If a country is unwilling to collaborate on an interoperable solutions, I believe it is excluded, no matter whether the solution is open or closed. I believe that the open source approach actually eases this issue: instead of "all member states collaborating", this is eased to "someone from all remember states collaborating". This greatly increases the chances of collaboration actually happening since it largely increased the number of potential collaborators. Consider, for example, that the Linux pkcs11 for (at least) the Estonian and Finish cards were not provided by the member state (i.e., government) itself but by interested third parties. Open source further avoids the need for formal agreements and for common timing. In my experience from international organizations, officially signing agreements with other organizations and involvement of the legal department was a nightmare that could delay projects sometimes for years. Would this be easier between member states? >3. the application size may be big as it has to support eID cards from >all the MS and on different platforms OpenSC currently supports 12 card operating systems and a much larger number of cards (not necessarily eID cards). Antonino has checked on Windows and it seems that the OpenSC pkcs11 with supporting libraries is about 530K. This is quite comparable to a single-card pkcs11 of the Italian RUPA card of about 500K and better than the 860K of the Italian Infocamere card. >4. the issuance of eID card may not be limited to the public sector alone >(In Austria, there are 4 different kind of smartcards that can be used as >an eID). As a result the numbers of eID cards may grow significantly and >providing support for all of them may become difficult. True that this increases the number of cards. I very much feel with you since in Italy, we have two official government issued cards, the CIE and the CNS that are fairly different in some respects. CIE and CNS always come with a certificate for authentication, but the certificate for digital signature is optional and can be added at any time after the issuance of the base card. The certificates for digital signature are not issued by government but are acquired on a free private sector market of government accredited CAs. Currently, there are 14 (or more?) such CAs. For the case that official authentication is not needed, these same CAs also issue their own cards for legal digital signature. Each CA has a free choice of how to make these cards (card os, file system layout). Some CAs have many different kinds of cards (Infocamere has four, I believe--all with different card-os and different file system layout). This large number of cards and the diversity of solutions is definitely a significant difficulty. In my judgement, only standardization can reduce the diversity and thus complexity--and this takes a significant amount of time to happen (maybe 10 years before standards are adopted by all governments and until the last non-standard cards have expired). So if we want interoperability before that (in the short and medium term), I believe the only solution is middleware that absorbs the diversity. But I believe again that this issue is not specific to open source solutions. Any middleware, no matter whether open or closed, has to face this problem. Open source in my view makes the task easier because it permits third parties (instead of only govs and CAs) to provide the code and since a single source works for all platforms. >5. different eID cards may use different encryption algorithms and >providing support for all of them may again be an issue. Hmm. Not sure about this. What do other people think? > To make it easy for me, or for anyone who is also interested in this > topic, would you please highlight some more issues related to the use of > OSS for the eID cards. Well, personally, I much prefer to focus on the advantages of the open source approach than its issues ;-). But more seriously, I would be very interested in your (and other's) opinion on whether there are holes in my reasoning and where other (closed source) approaches can bring benefits over open source or can resolve issues that open source has. Maybe it would be helpful if you could briefly describe the closed source interoparability scenario that you compare to. kind regards -bud > >Regards, > >Amir >_______________________________________________ >OpenSC-devel mailing list >Ope...@op... >http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. +39-0564-488577 (voice), -21139 (fax) Servizio Elaborazione Dati e-mail: bu...@co... Comune di Grosseto http://www.comune.grosseto.it/cie/ Via Ginori, 43 http://OpenPortalGuard.sf.net 58100 Grosseto (Tuscany, Italy) jabber: bu...@am... Free Software in Public Administration: not just a good idea, but a necessity Perfection is attained, not when there is nothing more to be added, but when there is nothing more to be taken away -- Antoine de Saint-Exupery |
|
From: Amir H. <ha...@sb...> - 2005-04-13 15:18:54
|
Hello,=20 I am doing a comparative study of OSS and Proprietary software used for = eID cards. In EU, we have about nine member states who are issuing eID = cards (though Malta and Denmark are not using smartcards in their = approach). These member states have their proprietary applications and = unfortunately these applications work only for their eID cards and are = not interoperable. I read a paper 'Open Source Solutions for = Interoperability in the eID domain' in which OSS is proposed as a better = solution to eliminate the interoperability issues. Besides the = advantages, I am trying to understand the limitations of this approach. = I have figured out few items for e.g. 1. it needs a disclosure of the eID card specifications which some = member states are not willing to do at the moment. 2. it needs the collaboration of all the member states which may take a = while 3. the application size may be big as it has to support eID cards from = all the MS and on different platforms 4. the issuance of eID card may not be limited to the public sector = alone (In Austria, there are 4 different kind of smartcards that can be = used as an eID). As a result the numbers of eID cards may grow = significantly and providing support for all of them may become = difficult.=20 5. different eID cards may use different encryption algorithms and = providing support for all of them may again be an issue. To make it easy for me, or for anyone who is also interested in this = topic, would you please highlight some more issues related to the use of = OSS for the eID cards. Regards, Amir |
|
From: Bud P. B. <bu...@co...> - 2005-04-07 11:57:12
|
Wow! I just found that the Belgians officially use the reverse proxy architecture based on apache! http://www.belgium.be/zip/Belgian_eID_Authentication_Reverse_Proxy_Users_Guide.pdf exactly what OPG wants to do! we add some things, however: * multiple tokens * token ID to principal mapping * declarative access control but very nice!!! -b ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. +39-0564-488577 (voice), -21139 (fax) Servizio Elaborazione Dati e-mail: bu...@co... Comune di Grosseto http://www.comune.grosseto.it/cie/ Via Ginori, 43 http://OpenPortalGuard.sf.net 58100 Grosseto (Tuscany, Italy) jabber: bu...@am... Free Software in Public Administration: not just a good idea, but a necessity Perfection is attained, not when there is nothing more to be added, but when there is nothing more to be taken away -- Antoine de Saint-Exupery |
|
From: Bud P. B. <bu...@co...> - 2005-04-06 14:55:35
|
Hi Jens, how are things going? Today, I've made some steps forward in the OpenPortalGuard idea. Particularly, I realized that I can reuse some modules for username password authentication instead of rewriting it... Namely, auth-ldap should be quite ok... So to be more modular, I thought to develop two new modules: * mod_principal that maps RemoteUser to some name; for example: - username to social security no - cut social security number that is included in the CN of one smartcard - look up social security number from the CN of another smartcard * mod_DAC (declarative access control) that used Roles, time, ip, and whatever What I don't understand to fit in this picture at the moment is how to manage different levels of authentication security, where every URL-pattern requires a different level of security. Say we have these levels: 1: username/password 2: client-cert-auth with untrusted CA and keys on file system 3: client-cert-auth with trusted CA and keys on secure token so if I'm already authenticated al level 3, I want to see 2 and 1 URLs without re-authenticating; but if I'm only logged in at level 1, i have to be asked to re-authenticate for level 2 and 3 URLs. I suppose this is further complicated by the fact that (I believe at least) ssl with client-side-auth and ssl w/o client-side-auth cannot easily run on the same (virtual) host/port ??? I believe you looked into possibilities of controlling mod-ssl behavior from inside an apache module??? Is there a way of asking to redo the handshake (if the security level is insufficient) or to require client-certs only for some URLs (i.e., in retrospect)??? Any ideas how to handle this? many thanks in advance -b ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. +39-0564-488577 (voice), -21139 (fax) Servizio Elaborazione Dati e-mail: bu...@co... Comune di Grosseto http://www.comune.grosseto.it/cie/ Via Ginori, 43 http://OpenPortalGuard.sf.net 58100 Grosseto (Tuscany, Italy) jabber: bu...@am... Free Software in Public Administration: not just a good idea, but a necessity Perfection is attained, not when there is nothing more to be added, but when there is nothing more to be taken away -- Antoine de Saint-Exupery |
|
From: Bud P. B. <bu...@co...> - 2004-12-15 10:05:38
|
This is a very interesting approach to add a second line of defense for very critical transactions: http://www.smh.com.au/news/Breaking/NZ-bank-adds-security-online/2004/11/08/1099781306318.html?oneclick=true -b ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. +39-0564-488577 (voice), -21139 (fax) Servizio Elaborazione Dati e-mail: bu...@co... Comune di Grosseto http://www.comune.grosseto.it/cie/ Via Ginori, 43 http://OpenPortalGuard.sf.net 58100 Grosseto (Tuscany, Italy) jabber: bu...@am... Free Software in Public Administration: not just a good idea, but a necessity Perfection is attained, not when there is nothing more to be added, but when there is nothing more to be taken away -- Antoine de Saint-Exupery |
|
From: Bud P. B. <bu...@co...> - 2004-12-09 12:15:59
|
This may be interesting to some people on the list (I also added the link to the wiki) Matt Bishop (Computer Science Dept., University of California at Davis): Chapter 13, "Design Principles" (<http://nob.cs.ucdavis.edu/book-aands/aands13.pdf>http://nob.cs.ucdavis.edu/book-aands/aands13.pdf) extracted from Computer Security: Art and Science, Addison-Wesley (<http://nob.cs.ucdavis.edu/book-aands/index.html>http://nob.cs.ucdavis.edu/book-aands/index.html) ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. +39-0564-488577 (voice), -21139 (fax) Servizio Elaborazione Dati e-mail: bu...@co... Comune di Grosseto http://www.comune.grosseto.it/cie/ Via Ginori, 43 http://OpenPortalGuard.sf.net 58100 Grosseto (Tuscany, Italy) jabber: bu...@am... Free Software in Public Administration: not just a good idea, but a necessity Perfection is attained, not when there is nothing more to be added, but when there is nothing more to be taken away -- Antoine de Saint-Exupery |
|
From: Bud P. B. <bu...@co...> - 2004-12-01 18:07:05
|
Salut Pierre, many thanks to you and Fred for the reply. May I ask you to check my current understanding in a second round? In the case of a HTTP POST profile, I understand a possible overall SSO scenario works as follows: 1. the user decides to federate her identity and acquires a permanent cookie from the ID-Provider (IdP), login.idp1.com, that is valid for some agreed on domain, trustNet1.com, and specifies the idP responsible for the user. 2. the user visits some service provider (SP) www.sp1.com who sees that the user has not logged in yet (by lack of session cookie from www.sp1.com) 3. the service provider redirects the user to the corresponding host on the agreed on domain, sp1.trustNet1.com to get the cookie that specifies the IdP responsible for that user. Sp1.trustNet1.com redirects back to www.sp1.com with the IdP address in the redirect URL or in a self-submitting HTTP form 4. www.sp1.com replies with a self-submitting form that contains an authentication request of a given level (say username/password...) that submits to the now known login.idp1.com. 5. login.idp1.com sees that the user isn't logged in yet, sets a transient session cookie for its own domain and presents a html login form 6. the user fills in username and password and submits the form to login.idp1.com. 7. login.idp1.com verifies the credential and sends an authentication assertion as a self-submitting form for www.sp1.com. Q: does it also update the cookie for itself with some login-credential or does it keep all the login information as server-side session data? 8. www.sp1.com receives the self-submitting form (as post data) and verifies the signature of the authentication assertion. The assertion contains all necessary user information necessary. www.sp1.com now sets a session cookie for its own domain that allows to link the user with the identity data or alternatively sets a cookie for www.sp1.com that contains some (HMAC) signed login credential. In the case of the HTTP Post profile where the information is not limited, no SOAP communication between www.sp1.com and login.idp1.com is needed. Is this correct? If so, this is very similar to what other SSO systems do (PubCookie, Cosign, etc.) Many thanks for your help!!! amicalment -b |
|
From: Pierre C. <pc...@en...> - 2004-12-01 14:53:49
|
Ciao a tutti, My colleague Fred Peters helped me to answer your questions. Bud P. Bruegger a écrit : > * page 32 mentions a Common Domain Cookie and states that "Common > domain established within the identity federation network for use with > introduction protocol". Does this mean that both Id-providers and > service providers must be in the same domain (such that cookies can be > set and seen by all collaborating hosts)? Yes. Cf Liberty ID-FF Bindings and Profiles Specification P.57 www.projectliberty.org/specs/ liberty-architecture-*bindings*-*profiles*-v1.1.pdf « The introduction profile relies on a cookie that is written in a domain that is common between identity providers and service providers in an identity federation network. » > * on page 48, Browser Post Profile: It seems that the ID-Provider > sends the Authentication Assertionin a HTML form that submits to the > Service Provider (SP). Does this mean that the user must submit the > form explicitly (click the button) to federate the identity? What > isn't clear to me is how the SP then manages the identity. Does it > set some kind of a signed session cookie? Or is there some cookie > that can be shared between SP and IDP? Yes, the user has to submit the form explicitly. But as it is not very convenient you can use javascript to to automate the validation. One can use the following hint (Cf Liberty ID-FF Bindings and Profiles Specification, P.23) : <html> <body onLoad="document.forms[0].submit()"> <form action="https://<Identity Provider Single Sign-On Service host name and path>" method="POST"> <input type="hidden" name="LAREQ" value="<base64 encoded AuthnRequest>" > </form> </body> </html> Then the authentication mechanism is the same than the artifact based one : The IDP send an Artifact to the SP, the SP send a SOAP Request to the IDP which responds with a SAML authentication assertion (with the name identifier included). Hope this helps Pierre Cros |
|
From: Bud P. B. <bu...@co...> - 2004-12-01 12:00:50
|
Ciao Pierre and others, I'm reading up on Liberty Alliance things a little and was wondering whether you could help me answer some questions relative to the tutorial http://www.projectliberty.org/resources/tutorial_draft.pdf * page 32 mentions a Common Domain Cookie and states that "Common domain established within the identity federation network for use with introduction protocol". Does this mean that both Id-providers and service providers must be in the same domain (such that cookies can be set and seen by all collaborating hosts)? * on page 48, Browser Post Profile: It seems that the ID-Provider sends the Authentication Assertionin a HTML form that submits to the Service Provider (SP). Does this mean that the user must submit the form explicitly (click the button) to federate the identity? What isn't clear to me is how the SP then manages the identity. Does it set some kind of a signed session cookie? Or is there some cookie that can be shared between SP and IDP? many thanks in advance for you help! -b ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. +39-0564-488577 (voice), -21139 (fax) Servizio Elaborazione Dati e-mail: bu...@co... Comune di Grosseto http://www.comune.grosseto.it/cie/ Via Ginori, 43 http://OpenPortalGuard.sf.net 58100 Grosseto (Tuscany, Italy) jabber: bu...@am... Free Software in Public Administration: not just a good idea, but a necessity Perfection is attained, not when there is nothing more to be added, but when there is nothing more to be taken away -- Antoine de Saint-Exupery |
|
From: Bud P. B. <bu...@co...> - 2004-11-17 09:43:51
|
http://europa.eu.int/ida/en/document/3472/194 ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice) Servizio Elaborazione Dati 0564- 21139 (fax) Comune di Grosseto e-mail: bu...@co... Via Ginori, 43 jabber: bu...@am... 58100 Grosseto icq: 249-858-685 Collaborazione Open Source per la CIE e CNS http://www.comune.grosseto.it/cie/ Software Libero/Open Source in P.A.: Non solo una buona idea, ma una necessita' |
|
From: Jens B. J. <jen...@ta...> - 2004-11-11 17:00:38
|
Yes, very unusual. But what did the requests to twisted do? Did it actually serve up a page? I've never installed twisted so I'm not sure how it works. Bud P. Bruegger wrote: > Antonino has run some benchmarks using 'ab' on both Apache 2 and > Twisted. Results below. > Twisted seem rather slow! Any comments, interpretations? > > -b > > -------------100 concurrent connections > --------------------------------------------- > > [15.10.25] <aiacono> Requests per second: 15.48 [#/sec] (mean) > Time per request: 6461.00 [ms] (mean) > Time per request: 64.61 [ms] (mean, across all concurrent requests) > Transfer rate: 22.04 [Kbytes/sec] received > > Connnection Times (ms) > min mean[+/-sd] median max > Connect: 240 1133 347.7 1090 1853 > Processing: 2028 4493 1285.8 5116 5173 > Waiting: 929 4474 1305.4 5116 5172 > Total: 2028 5626 1457.1 6215 6325 > > [15.10.36] <aiacono> apache > [15.10.37] <aiacono> Requests per second: 613.50 [#/sec] (mean) > Time per request: 163.00 [ms] (mean) > Time per request: 1.63 [ms] (mean, across all concurrent requests) > Transfer rate: 1270.55 [Kbytes/sec] received > > Connnection Times (ms) > min mean[+/-sd] median max > Connect: 12 31 7.6 36 37 > Processing: 50 67 22.6 61 113 > Waiting: 36 66 23.0 60 113 > Total: 50 98 29.2 98 149 > > > ------------- 300 concurrent connections > ---------------------------------------------------- > > [15.17.05] <aiacono> Server Software: TwistedWeb/1.3.0rc1 > Server Hostname: localhost > Server Port: 80 > > Document Path: / > Document Length: 1278 bytes > > Concurrency Level: 300 > Time taken for tests: 19.430 seconds > Complete requests: 300 > Failed requests: 0 > Broken pipe errors: 0 > Total transferred: 431460 bytes > HTML transferred: 391068 bytes > Requests per second: 15.44 [#/sec] (mean) > Time per request: 19430.00 [ms] (mean) > Time per request: 64.77 [ms] (mean, across all concurrent requests) > Transfer rate: 22.21 [Kbytes/sec] received > > Connnection Times (ms) > min mean[+/-sd] median max > Connect: 0 1040 2300.8 0 9000 > Processing: 163 1451 1888.8 929 10005 > Waiting: 151 1450 1888.9 928 10005 > Total: 163 2491 3749.3 953 18554 > > [15.17.20] <aiacono> e ora apache > [15.17.35] <aiacono> Server Software: Apache/2.0.52 > Server Hostname: localhost > Server Port: 80 > > Document Path: /apache2-default/index.html.it > Document Length: 1789 bytes > > Concurrency Level: 300 > Time taken for tests: 0.401 seconds > Complete requests: 300 > Failed requests: 0 > Broken pipe errors: 0 > Total transferred: 621300 bytes > HTML transferred: 536700 bytes > Requests per second: 748.13 [#/sec] (mean) > Time per request: 401.00 [ms] (mean) > Time per request: 1.34 [ms] (mean, across all concurrent requests) > Transfer rate: 1549.38 [Kbytes/sec] received > > Connnection Times (ms) > min mean[+/-sd] median max > Connect: 1 36 12.2 41 56 > Processing: 55 138 55.2 149 231 > Waiting: 38 137 55.5 149 230 > Total: 55 174 53.5 192 271 > > > > > ------------------------------------------------------------------------------------------------- > > Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice) > Servizio Elaborazione Dati 0564- 21139 (fax) > Comune di Grosseto e-mail: > bu...@co... > Via Ginori, 43 jabber: > bu...@am... > 58100 Grosseto icq: 249-858-685 > > Collaborazione Open Source per la CIE e CNS > http://www.comune.grosseto.it/cie/ > Software Libero/Open Source in P.A.: Non solo una buona idea, ma una > necessita' > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Openportalguard-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openportalguard-devel -- Jens B. Jorgensen jen...@ta... "With a focused commitment to our clients and our people, we deliver value through customized technology solutions" |
|
From: Bud P. B. <bu...@co...> - 2004-11-11 16:52:36
|
Antonino has run some benchmarks using 'ab' on both Apache 2 and
Twisted. Results below.
Twisted seem rather slow! Any comments, interpretations?
-b
-------------100 concurrent connections
---------------------------------------------
[15.10.25] <aiacono> Requests per second: 15.48 [#/sec] (mean)
Time per request: 6461.00 [ms] (mean)
Time per request: 64.61 [ms] (mean, across all concurrent requests)
Transfer rate: 22.04 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 240 1133 347.7 1090 1853
Processing: 2028 4493 1285.8 5116 5173
Waiting: 929 4474 1305.4 5116 5172
Total: 2028 5626 1457.1 6215 6325
[15.10.36] <aiacono> apache
[15.10.37] <aiacono> Requests per second: 613.50 [#/sec] (mean)
Time per request: 163.00 [ms] (mean)
Time per request: 1.63 [ms] (mean, across all concurrent requests)
Transfer rate: 1270.55 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 12 31 7.6 36 37
Processing: 50 67 22.6 61 113
Waiting: 36 66 23.0 60 113
Total: 50 98 29.2 98 149
------------- 300 concurrent connections
----------------------------------------------------
[15.17.05] <aiacono> Server Software: TwistedWeb/1.3.0rc1
Server Hostname: localhost
Server Port: 80
Document Path: /
Document Length: 1278 bytes
Concurrency Level: 300
Time taken for tests: 19.430 seconds
Complete requests: 300
Failed requests: 0
Broken pipe errors: 0
Total transferred: 431460 bytes
HTML transferred: 391068 bytes
Requests per second: 15.44 [#/sec] (mean)
Time per request: 19430.00 [ms] (mean)
Time per request: 64.77 [ms] (mean, across all concurrent requests)
Transfer rate: 22.21 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 0 1040 2300.8 0 9000
Processing: 163 1451 1888.8 929 10005
Waiting: 151 1450 1888.9 928 10005
Total: 163 2491 3749.3 953 18554
[15.17.20] <aiacono> e ora apache
[15.17.35] <aiacono> Server Software: Apache/2.0.52
Server Hostname: localhost
Server Port: 80
Document Path: /apache2-default/index.html.it
Document Length: 1789 bytes
Concurrency Level: 300
Time taken for tests: 0.401 seconds
Complete requests: 300
Failed requests: 0
Broken pipe errors: 0
Total transferred: 621300 bytes
HTML transferred: 536700 bytes
Requests per second: 748.13 [#/sec] (mean)
Time per request: 401.00 [ms] (mean)
Time per request: 1.34 [ms] (mean, across all concurrent requests)
Transfer rate: 1549.38 [Kbytes/sec] received
Connnection Times (ms)
min mean[+/-sd] median max
Connect: 1 36 12.2 41 56
Processing: 55 138 55.2 149 231
Waiting: 38 137 55.5 149 230
Total: 55 174 53.5 192 271
-------------------------------------------------------------------------------------------------
Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice)
Servizio Elaborazione Dati 0564- 21139 (fax)
Comune di Grosseto e-mail: bu...@co...
Via Ginori, 43 jabber: bu...@am...
58100 Grosseto icq: 249-858-685
Collaborazione Open Source per la CIE e CNS http://www.comune.grosseto.it/cie/
Software Libero/Open Source in P.A.: Non solo una buona idea, ma una
necessita'
|
|
From: Bud P. B. <bu...@co...> - 2004-11-09 12:34:06
|
Here are some very interesting examples for Twisted: http://divmod.org/svn/Nevow/sandbox/tv/ -b ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice) Servizio Elaborazione Dati 0564- 21139 (fax) Comune di Grosseto e-mail: bu...@co... Via Ginori, 43 jabber: bu...@am... 58100 Grosseto icq: 249-858-685 Collaborazione Open Source per la CIE e CNS http://www.comune.grosseto.it/cie/ Software Libero/Open Source in P.A.: Non solo una buona idea, ma una necessita' |
|
From: Bud P. B. <bu...@co...> - 2004-11-08 15:42:32
|
Thanks, Jens! Antonino has started to look into ways of benchmarking to be more confident about the assessment (see also http://openportalguard.sourceforge.net/wiki/index.php/Specification/BenchmarkDesign). He had a quick go with Apache's flood that isn't all that straight forward to use and has now found a version of "ab" that supports ssl (http://www.deny-all.com/en/solsecu/tech/ab-ssl.html). But a first quick test showed a limit at 150 simultaneous users (and that was expected since max-child in the config file, max-children was set to 150 ;-). The other problem was that the test seemed to reuse a single SSL session. We'll have to tune a little to try to get something meaningful out... -b At 09.25 08/11/2004 -0600, you wrote: >This sounds like a valid assessment to me. It seems RSA operations have a >pretty good probability of being the bottleneck. In particular since we >would only authenticate once or a few times per session with a user SSL >session caching wouldn't come into play either to ease the burden of RSA >operations and speed up that negotiation. > >Bud P. Bruegger wrote: >>Jens and all, >> >>I just came across a very nice illustration of the scalability problem of >>both pre-forking and multi-threading servers: >><http://www.acme.com/software/thttpd/serverperf.gif>http://www.acme.com/software/thttpd/serverperf.gif >> >>(at the end of >><http://www.acme.com/software/thttpd/benchmarks.html>http://www.acme.com/software/thttpd/benchmarks.html). >> >> >>If you look at Apache (pre-forking, green), and Roxen (threading, light >>blue), it handles up to a certain number of contemporary connections and >>then, due to resource exhaustion, basically collapses (i.e., fails to >>serve requests). You can tell that there is not much difference between >>treading and pre-forking. >> >>In contrast, if you look at the single process, select-based servers, >>their performance (hits/sec) are basically constant independently of the >>number of concurrent users (at least in the range shown in the diagram). >> >>The point of collapse in the diagram (surley depending on the hw >>configuration, version, and type of content served) is at around 120 >>simultaneous users. I believe that the resource that is exhausted first >>is Memory (some evidence in >><http://www.apache.org/%7Eerikabele/httpd/docs/LinuxTag-2004-MPMs-Light.pdf><http://www.apache.org/%7Eerikabele/httpd/docs/LinuxTag-2004-MPMs-Light.pdf><http://www.apache.org/~erikabele/httpd/docs/LinuxTag-2004-MPMs-Light.pdf>http://www.apache.org/~erikabele/httpd/docs/LinuxTag-2004-MPMs-Light.pdf), >>but am not sure about this... >> >>Assuming that this applies to our situation (which I'm not sure), How >>does this compare to how many concurrent connections can be handled by >>the CPU for ssl processing? It seems from very rapid scanning of >><http://www1.cs.columbia.edu/~angelos/teaching/COMS6998/websecurity/Gupta.pdf>http://www1.cs.columbia.edu/~angelos/teaching/COMS6998/websecurity/Gupta.pdf, >>section 5, that the main cost of SSL processing is in the public-key >>decryption, not the symmetric encription of the traffic. Thus, the cost >>is mostly determined by the number of ssl-sessions, not http requests >>within a session. >> >>Now I'm trying to understand overall scalability (http processing and ssl >>processing). If I naively (uncomparable hw...) look at figure 5, things >>start to degrade at about 30 concurrent ssl-sessions (with RSA >>1024). This seems to indicate that CPU-exhaustion for SSL-processing >>occurres well below the scalability limit of Apache (120 simultaneous users). >> >>So if the naive comparison was valid, using Apache instead of Twisted or >>Squid (both more scalable in terms of concurrent http requests sans ssl) >>doesn't lose anything in scalability since the real bottleneck is ssl >>processing and that is the same for Twisted and Squid. Obviously, this >>may change if the hw changes (e.g., with hardware accellerated RSA >>processing)... >> >>But anyhow, from this point of view, Apache seems a valid choice. >> >>I'm looking forward to your comments and hope you can either confirm or >>reject my reasoning. >> >>thanks >>-b >> >> >> >>------------------------------------------------------------------------------------------------- >> >>Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice) >>Servizio Elaborazione Dati 0564- 21139 (fax) >>Comune di >>Grosseto e-mail: >><mailto:bu...@co...>bu...@co... >>Via Ginori, >>43 jabber: >><mailto:bu...@am...>bu...@am... >>58100 Grosseto icq: 249-858-685 >> >>Collaborazione Open Source per la CIE e CNS >><http://www.comune.grosseto.it/cie/>http://www.comune.grosseto.it/cie/ >>Software Libero/Open Source in P.A.: Non solo una buona idea, ma una >>necessita' >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: >>Sybase ASE Linux Express Edition - download now for FREE >>LinuxWorld Reader's Choice Award Winner for best database on Linux. >><http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click >> >>_______________________________________________ >>Openportalguard-devel mailing list >><mailto:Ope...@li...>Ope...@li... >> >>https://lists.sourceforge.net/lists/listinfo/openportalguard-devel > > > > >-- >Jens B. Jorgensen ><mailto:jen...@ta...>jen...@ta... > >"With a focused commitment to our clients and our people, we deliver value >through customized technology solutions" ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice) Servizio Elaborazione Dati 0564- 21139 (fax) Comune di Grosseto e-mail: bu...@co... Via Ginori, 43 jabber: bu...@am... 58100 Grosseto icq: 249-858-685 Collaborazione Open Source per la CIE e CNS http://www.comune.grosseto.it/cie/ Software Libero/Open Source in P.A.: Non solo una buona idea, ma una necessita' |
|
From: Bud P. B. <bu...@co...> - 2004-11-05 10:23:50
|
Ciao Pierre, It would be interesting to see what it takes to integrate the two at a=20 later point and keep this in mind to not block future integration. Does=20 Lasso already have a component that does ssl client authentication? If so,= =20 it would be interesting to look at it more closely. If not, and if this is= =20 something useful, maybe OPG could do the job... many thanks -b At 11.00 05/11/2004 +0100, you wrote: >Ciao Bud, > >Bud P. Bruegger a =E9crit : > >>You seem to argue with a future need and assume that the external=20 >>requirement will be compatibility with Liberty Alliance. > > >Yes I do. Even Microsoft is about to give up Passport and to join Liberty= =20 >Alliance. > >>But if that was not the case (being the most reasonable solution does=20 >>not always mean that government requirements choose it ;-) > > >This is perfectly true, I might be a bit too much optimistic. >Sorry for not responding in details to your questions but I would need to= =20 >be more aware of what is at stake in OPG. And as you said, Liberty=20 >Alliance maybe too complex according to your needs for now. > >If, at a later stage, you think about a LA enabled solution, I will be=20 >happy to collaborate more efficiently. > >Cheers, > >Pierre > > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Sybase ASE Linux Express Edition - download now for FREE >LinuxWorld Reader's Choice Award Winner for best database on Linux. >http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick >_______________________________________________ >Openportalguard-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openportalguard-devel ----------------------------------------------------------------------------= --------------------- Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice) Servizio Elaborazione Dati 0564- 21139 (fax) Comune di Grosseto e-mail: = bu...@co... Via Ginori, 43 jabber: = bu...@am... 58100 Grosseto icq: 249-858-685 Collaborazione Open Source per la CIE e CNS= http://www.comune.grosseto.it/cie/ Software Libero/Open Source in P.A.: Non solo una buona idea, ma una=20 necessita' =20 |
|
From: Pierre C. <pc...@en...> - 2004-11-05 10:00:18
|
Ciao Bud, Bud P. Bruegger a écrit : > You seem to argue with a future need and assume that the external > requirement will be compatibility with Liberty Alliance. Yes I do. Even Microsoft is about to give up Passport and to join Liberty Alliance. > But if that was not the case (being the most reasonable solution does > not always mean that government requirements choose it ;-) This is perfectly true, I might be a bit too much optimistic. Sorry for not responding in details to your questions but I would need to be more aware of what is at stake in OPG. And as you said, Liberty Alliance maybe too complex according to your needs for now. If, at a later stage, you think about a LA enabled solution, I will be happy to collaborate more efficiently. Cheers, Pierre |
|
From: Bud P. B. <bu...@co...> - 2004-11-05 09:11:09
|
Jens and all, I just came across a very nice illustration of the scalability problem of both pre-forking and multi-threading servers: http://www.acme.com/software/thttpd/serverperf.gif (at the end of http://www.acme.com/software/thttpd/benchmarks.html). If you look at Apache (pre-forking, green), and Roxen (threading, light blue), it handles up to a certain number of contemporary connections and then, due to resource exhaustion, basically collapses (i.e., fails to serve requests). You can tell that there is not much difference between treading and pre-forking. In contrast, if you look at the single process, select-based servers, their performance (hits/sec) are basically constant independently of the number of concurrent users (at least in the range shown in the diagram). The point of collapse in the diagram (surley depending on the hw configuration, version, and type of content served) is at around 120 simultaneous users. I believe that the resource that is exhausted first is Memory (some evidence in <http://www.apache.org/%7Eerikabele/httpd/docs/LinuxTag-2004-MPMs-Light.pdf>http://www.apache.org/~erikabele/httpd/docs/LinuxTag-2004-MPMs-Light.pdf), but am not sure about this... Assuming that this applies to our situation (which I'm not sure), How does this compare to how many concurrent connections can be handled by the CPU for ssl processing? It seems from very rapid scanning of http://www1.cs.columbia.edu/~angelos/teaching/COMS6998/websecurity/Gupta.pdf, section 5, that the main cost of SSL processing is in the public-key decryption, not the symmetric encription of the traffic. Thus, the cost is mostly determined by the number of ssl-sessions, not http requests within a session. Now I'm trying to understand overall scalability (http processing and ssl processing). If I naively (uncomparable hw...) look at figure 5, things start to degrade at about 30 concurrent ssl-sessions (with RSA 1024). This seems to indicate that CPU-exhaustion for SSL-processing occurres well below the scalability limit of Apache (120 simultaneous users). So if the naive comparison was valid, using Apache instead of Twisted or Squid (both more scalable in terms of concurrent http requests sans ssl) doesn't lose anything in scalability since the real bottleneck is ssl processing and that is the same for Twisted and Squid. Obviously, this may change if the hw changes (e.g., with hardware accellerated RSA processing)... But anyhow, from this point of view, Apache seems a valid choice. I'm looking forward to your comments and hope you can either confirm or reject my reasoning. thanks -b ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice) Servizio Elaborazione Dati 0564- 21139 (fax) Comune di Grosseto e-mail: bu...@co... Via Ginori, 43 jabber: bu...@am... 58100 Grosseto icq: 249-858-685 Collaborazione Open Source per la CIE e CNS http://www.comune.grosseto.it/cie/ Software Libero/Open Source in P.A.: Non solo una buona idea, ma una necessita' |
|
From: Bud P. B. <bu...@co...> - 2004-11-05 08:36:19
|
Hi Jens, thanks for the input. Some reaction below.. [I cc that to the list, maybe it is an important point] >After reading that article you forwarded me I know now that at least with >the traditional model apache uses a single process per request (unless the >client keeps the connection alive). This was a bit of a shock to me! There >is not insignificant overhead involved with forking a process and cleaning >up after the process is done. I would think that an architecture that has >a re-usable thread pool for requests would be much faster and better. It >sounds like this is how Twisted works. In my understanding, the Apache 1.3 pre-forking model has a pool of processes (max-children controls how many) and reuses these (so little clean-up overhead). The trouble starts when max-children isn't enough and basically things start to fall apart very rapidly (no graceful reaction to overload). Apache 2.0 has multi-threading in addition to multi-processing. So that's the thread pools you mentioned. It is possible to use only thread pools, or multiple pre-forked processes with thread pools (a mixed model). The drawback of thread pools is robustness--if one tread dies it may bring down all other threads of the process. Twisted and Squid (not sure about Pound) are a single process and single thread. This is the Reactor Pattern that is particularly suited for high scalability. You may have come across it in the form of Python's asyncore, Medusa, or Zope's asyncore approach. Also, there are many super fast web servers that imprement this (see http://www.acme.com/software/thttpd/benchmarks.html). This approach makes use of the select, poll, epoll, etc. system calles and non-blocking IO. For scalability (memory and scheduler limits, don't think CPU limits), this approach is surely the best approach. Note that if you look at <http://bulk.fefe.de/scalable-networking.pdf>http://bulk.fefe.de/scalable-networking.pdf, it seems that threads are not that much better than processes (but they probably alleviate scheduler limitations). >In any case if we go about it with care we could probably code the >solution such that a minimal amount of code would be wasted should the >decision to switch be made later on. Going with Apache to start would >certainly I think be the more expedient route to follow. This sounds reasonable. At least unless we find someone with Twisted experience who could verify the feasibility and point us in the right direction... (Let me try to work on this today). many thanks -b >-- >Jens B. Jorgensen ><mailto:jen...@ta...>jen...@ta... > >"With a focused commitment to our clients and our people, we deliver value >through customized technology solutions" ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice) Servizio Elaborazione Dati 0564- 21139 (fax) Comune di Grosseto e-mail: bu...@co... Via Ginori, 43 jabber: bu...@am... 58100 Grosseto icq: 249-858-685 Collaborazione Open Source per la CIE e CNS http://www.comune.grosseto.it/cie/ Software Libero/Open Source in P.A.: Non solo una buona idea, ma una necessita' |
|
From: Jens B. J. <jen...@ta...> - 2004-11-04 21:26:14
|
Although from the sound of it the spirit of the design is to fulfill a very simple task--adding code to it to get it to do what OPG will do would definitely add code and complexity. It sounds like Pound is meant to be a poor man's F5 BIG-IP box. Bud P. Bruegger wrote: > Pound http://www.apsis.ch/pound/ sounds like an interesting > alternative to Apache/Squid/Twisted: > > Here some excerpts from the home page: > > The Pound program is a reverse proxy, load balancer and HTTPS > front-end for Web server(s). Pound was developed to enable > distributing the load among several Web-servers and to allow for a > convenient SSL wrapper for those Web servers that do not offer it > natively. Pound is distributed under the GPL - no warranty, it's free > to use, copy and give away. > WHAT POUND IS: > > 1. a reverse-proxy: it passes requests from client browsers to one > or more back-end servers. > 2. a load balancer: it will distribute the requests from the client > browsers among several back-end servers, while keeping session > information. > 3. an SSL wrapper: Pound will decrypt HTTPS requests from client > browsers and pass them as plain HTTP to the back-end browsers. > 4. an HTTP/HTTPS sanitizer: Pound will verify requests for > correctness and accept only well-formed ones. > 5. a fail over-server: should a back-end server fail, Pound will > take note of the fact and stop passing requests to it until it recovers. > 6. a request redirector: requests may be distributed among servers > according to the requested URL. > > Pound is a very small program, easily audited for security problems. > It can run as setuid/setgid and/or in a chroot jail. Pound does not > access the hard-disk at all (except for reading the certificate file > on start, if required) and should thus pose no security threat to any > machine. > WHAT POUND IS NOT: > > 1. Pound is not a Web server: by itself, Pound serves no content - > it contacts the back-end server(s) for that purpose. > 2. Pound is not a Web accelerator: no caching is done - every > request is passed "as is" to a back-end server. > > > SIMILAR SYSTEMS > > Quite a few people asked "What is wrong with Apache/Squid/ > stunnel/your_favorite? Do we really need another proxy system?". The > simple answer is that there is nothing wrong - they are all excellent > systems that do their jobs very well. The reasoning behind Pound is > however slightly different: > > * In my experience, a load-balancer may easily become a > bottle-neck in itself. If you have a heavily loaded site, there are > few things more depressing than seeing your "load-balancer" slow down > the entire network. This means that the load-balancer should be kept > as light-weight as possible. > * Security: auditing a large system for security issues is a major > undertaking for anybody (ask Bill Gates about it). This implies that > in order to avoid introducing new vulnerabilities into a system (after > all, your installation is only as secure as its weakest component) the > proxy/load-balancer should be kept as small as possible. > * Protection: I assume Pound will be the only component exposed to > the Internet - your back-end servers will run in a protected network > behind it. This means that Pound should filter requests and make sure > only valid, correctly formed ones are passed to the back-end servers, > thus protecting them from malicious clients. > > Taking these criteria into consideration, it is easy to see why the > other systems mentioned above do not fit: > > * Apache (with mod_proxy and mod_backhand): great system, but very > large. Imposes a significant load on the system, complex set-up > procedure (and it is so easy to get it wrong: check how many Apache > servers allow proxying from and to external hosts). While Apache has > proven remarkably exploit free, I wouldn't wish to go into a security > audit for the tens of thousands of lines of code involved, not to > mention all the additional modules. > * Squid: great caching proxy, but even should load-balancing > features become available in the future, do you really need caching on > the load-balancer? After all, Pound can easily run on a disk-less > system, whereas with Squid you'd better prepare a high throughput > RAID. Squid is still perfectly usable as a caching proxy between Pound > and the actual Web server, should it lack its own cache (which Zope > happily has). > * stunnel: probably comes closest to my understanding of software > design (does one job only and does it very well). However, it lacks > the load balancing and HTTP filtering features that I considered > necessary. Using stunnel in front of Pound (for HTTPS) would have made > sense, except that integrating HTTPS into Pound proved to be so simple > that it was not worth the trouble. > > > > > ------------------------------------------------------------------------------------------------- > > Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice) > Servizio Elaborazione Dati 0564- 21139 (fax) > Comune di Grosseto e-mail: > bu...@co... > Via Ginori, 43 jabber: > bu...@am... > 58100 Grosseto icq: 249-858-685 > > Collaborazione Open Source per la CIE e CNS > http://www.comune.grosseto.it/cie/ > Software Libero/Open Source in P.A.: Non solo una buona idea, ma una > necessita' > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Openportalguard-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openportalguard-devel -- Jens B. Jorgensen jen...@ta... "With a focused commitment to our clients and our people, we deliver value through customized technology solutions" |
|
From: Bud P. B. <bu...@co...> - 2004-11-04 14:35:40
|
Ciao Pierre,
you get me thinking... details below...
At 14.26 04/11/2004 +0100, Pierre Cros wrote:
>Bud P. Bruegger a =E9crit :
>
>>So I don't see the federation issue nor the need to communicate trust=20
>>(via SAML or similar) to third parties. In the OPG architecture, the=20
>>service provider and authentication provider are always the same.
>
>
>Yes. And that could become a problem, according to me, when it comes to=20
>make the OPG architecture communicate with some external web services.
Web services as in SOAP or as in HTTP+HTML (or REST)?
>We have developped many web services for different administrations and=20
>communes in France. We've seen that sooner or later, the solutions we=20
>developped had to interact with other services (from a different=20
>administration) developped by other people. This as to be taken into=20
>account especially in a european context. Liberty Alliance appeared to be=
=20
>the most efficient protocol to make those different services communicate=20
>together, preserving the Single Sign On functionality.
Thinking aloud:
If the other service is a webservice (as in SOAP), OPG doesn't deal with=20
the issue at all and we'd need some local proxy to get that content and=20
then wrap it into a web page. This is probably outside the scope of OPG=20
and I personally am quite comfortable with this. It seems independent=20
enough to add later.
If the other service is HTTP+HTML (or REST) and it trusts our town to do=20
the authentication, why not simply send them a proxied HTTP (over ssl)=20
request with the RemoteUser HTTP header already set? They can verify the=20
request comes from our server via an SSL handshake and then they can simply=
=20
trust us on who the user is. Too simple? Obviously, if the other site=20
insists in doing things more complicated (and governments usually do), then=
=20
we have to adapt. But I don't see the inherent need for complexity. Is=20
there something I'm missing out of?
>As long as all the SPs are within OPG, no problem. But if tomorrow the=20
>italian government decides that each town has to connect their website to=
=20
>its own server to interact to... whatever service (that's exactly what=20
>happens in France right now). It would then be far easier to do it with a=
=20
>Liberty Alliance enabled solution. And after the government decision we=20
>will probably have to cope with european directives. The EU has already=20
>said that Liberty Alliance was the only authentication and SSO protocol=20
>able to respect users private life ("Working document on online=20
>authentication services" january 2003, written by =AB Data Protection=20
>Working Party =BB=20
>_http://europa.eu.int/comm/internal_market/privacy/docs/wpdocs/2003/wp68_en=
.pdf_=20
>)
You seem to argue with a future need and assume that the external=20
requirement will be compatibility with Liberty Alliance. But if that was=20
not the case (being the most reasonable solution does not always mean that=
=20
government requirements choose it ;-)
>Of course a Liberty Alliance enabled solution is much more complicated=20
>than OPG as it stands now and I don't want to interfere too much with a=20
>project I quite don't know :-). But you explained your interest in=20
>standards and in having a great number of users, the ease of integration=20
>with other services allowed by LA is significant from these points.
It is exactly this complexity that scares me away... But really, thinking=
=20
in terms of collaborative modules, wouldn't a Liberty Alliance system still=
=20
need a component that actually authenticates users via their=20
smartcards? Or in other words, couldn't OPG be seen as a reusable=20
component of an overall system, as a first step?
What would the interfacing requirements be to integrate OPG with Lasso? Do=
=20
you see this as a possibility? If so, maybe this would be a synergy of our=
=20
projects to exploit...
thanks for the input
cheers
-b
>Pierre Cros
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
>_______________________________________________
>Openportalguard-devel mailing list
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openportalguard-devel
----------------------------------------------------------------------------=
---------------------
Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice)
Servizio Elaborazione Dati 0564- 21139 (fax)
Comune di Grosseto e-mail: =
bu...@co...
Via Ginori, 43 jabber: =
bu...@am...
58100 Grosseto icq: 249-858-685
Collaborazione Open Source per la CIE e CNS=
http://www.comune.grosseto.it/cie/
Software Libero/Open Source in P.A.: Non solo una buona idea, ma una=20
necessita'=20
|
|
From: Bud P. B. <bu...@co...> - 2004-11-04 14:29:05
|
Pound http://www.apsis.ch/pound/ sounds like an interesting alternative to Apache/Squid/Twisted: Here some excerpts from the home page: The Pound program is a reverse proxy, load balancer and HTTPS front-end for Web server(s). Pound was developed to enable distributing the load among several Web-servers and to allow for a convenient SSL wrapper for those Web servers that do not offer it natively. Pound is distributed under the GPL - no warranty, it's free to use, copy and give away. WHAT POUND IS: 1. a reverse-proxy: it passes requests from client browsers to one or more back-end servers. 2. a load balancer: it will distribute the requests from the client browsers among several back-end servers, while keeping session information. 3. an SSL wrapper: Pound will decrypt HTTPS requests from client browsers and pass them as plain HTTP to the back-end browsers. 4. an HTTP/HTTPS sanitizer: Pound will verify requests for correctness and accept only well-formed ones. 5. a fail over-server: should a back-end server fail, Pound will take note of the fact and stop passing requests to it until it recovers. 6. a request redirector: requests may be distributed among servers according to the requested URL. Pound is a very small program, easily audited for security problems. It can run as setuid/setgid and/or in a chroot jail. Pound does not access the hard-disk at all (except for reading the certificate file on start, if required) and should thus pose no security threat to any machine. WHAT POUND IS NOT: 1. Pound is not a Web server: by itself, Pound serves no content - it contacts the back-end server(s) for that purpose. 2. Pound is not a Web accelerator: no caching is done - every request is passed "as is" to a back-end server. SIMILAR SYSTEMS Quite a few people asked "What is wrong with Apache/Squid/ stunnel/your_favorite? Do we really need another proxy system?". The simple answer is that there is nothing wrong - they are all excellent systems that do their jobs very well. The reasoning behind Pound is however slightly different: * In my experience, a load-balancer may easily become a bottle-neck in itself. If you have a heavily loaded site, there are few things more depressing than seeing your "load-balancer" slow down the entire network. This means that the load-balancer should be kept as light-weight as possible. * Security: auditing a large system for security issues is a major undertaking for anybody (ask Bill Gates about it). This implies that in order to avoid introducing new vulnerabilities into a system (after all, your installation is only as secure as its weakest component) the proxy/load-balancer should be kept as small as possible. * Protection: I assume Pound will be the only component exposed to the Internet - your back-end servers will run in a protected network behind it. This means that Pound should filter requests and make sure only valid, correctly formed ones are passed to the back-end servers, thus protecting them from malicious clients. Taking these criteria into consideration, it is easy to see why the other systems mentioned above do not fit: * Apache (with mod_proxy and mod_backhand): great system, but very large. Imposes a significant load on the system, complex set-up procedure (and it is so easy to get it wrong: check how many Apache servers allow proxying from and to external hosts). While Apache has proven remarkably exploit free, I wouldn't wish to go into a security audit for the tens of thousands of lines of code involved, not to mention all the additional modules. * Squid: great caching proxy, but even should load-balancing features become available in the future, do you really need caching on the load-balancer? After all, Pound can easily run on a disk-less system, whereas with Squid you'd better prepare a high throughput RAID. Squid is still perfectly usable as a caching proxy between Pound and the actual Web server, should it lack its own cache (which Zope happily has). * stunnel: probably comes closest to my understanding of software design (does one job only and does it very well). However, it lacks the load balancing and HTTP filtering features that I considered necessary. Using stunnel in front of Pound (for HTTPS) would have made sense, except that integrating HTTPS into Pound proved to be so simple that it was not worth the trouble. ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice) Servizio Elaborazione Dati 0564- 21139 (fax) Comune di Grosseto e-mail: bu...@co... Via Ginori, 43 jabber: bu...@am... 58100 Grosseto icq: 249-858-685 Collaborazione Open Source per la CIE e CNS http://www.comune.grosseto.it/cie/ Software Libero/Open Source in P.A.: Non solo una buona idea, ma una necessita' |
|
From: Pierre C. <pc...@en...> - 2004-11-04 13:26:28
|
Bud P. Bruegger a écrit :
> So I don't see the federation issue nor the need to communicate trust
> (via SAML or similar) to third parties. In the OPG architecture, the
> service provider and authentication provider are always the same.
Yes. And that could become a problem, according to me, when it comes to
make the OPG architecture communicate with some external web services.
We have developped many web services for different administrations and
communes in France. We've seen that sooner or later, the solutions we
developped had to interact with other services (from a different
administration) developped by other people. This as to be taken into
account especially in a european context. Liberty Alliance appeared to
be the most efficient protocol to make those different services
communicate together, preserving the Single Sign On functionality.
As long as all the SPs are within OPG, no problem. But if tomorrow the
italian government decides that each town has to connect their website
to its own server to interact to... whatever service (that's exactly
what happens in France right now). It would then be far easier to do it
with a Liberty Alliance enabled solution. And after the government
decision we will probably have to cope with european directives. The EU
has already said that Liberty Alliance was the only authentication and
SSO protocol able to respect users private life ("Working document on
online authentication services" january 2003, written by « Data
Protection Working Party »
_http://europa.eu.int/comm/internal_market/privacy/docs/wpdocs/2003/wp68_en.pdf_
)
Of course a Liberty Alliance enabled solution is much more complicated
than OPG as it stands now and I don't want to interfere too much with a
project I quite don't know :-). But you explained your interest in
standards and in having a great number of users, the ease of integration
with other services allowed by LA is significant from these points.
Pierre Cros
|
|
From: Bud P. B. <bu...@co...> - 2004-11-04 11:41:29
|
Here a progress report on looking at Squid as possible base for GateKeepers: * a difficulty: squid is not a web server, so we need an additional package to create login pages etc. * a possible show stopper: is it possible to write cookies from within Squid? Without cookies, it may just not work... -b ------------------------------------------------------------------------------------------------- Ing. Bud P. Bruegger, Ph.D. 0564-488 577 (voice) Servizio Elaborazione Dati 0564- 21139 (fax) Comune di Grosseto e-mail: bu...@co... Via Ginori, 43 jabber: bu...@am... 58100 Grosseto icq: 249-858-685 Collaborazione Open Source per la CIE e CNS http://www.comune.grosseto.it/cie/ Software Libero/Open Source in P.A.: Non solo una buona idea, ma una necessita' |
141 messages has been excluded from this view by a project administrator.