1. dhiva@es.net & helm@es.net
TAGPMA Twiki
&

2. Agenda ESnet Web hosting environment Certificate based authentication
Registration Automation
Problems&/Solutions
Suggestions&/Contribution

3. Virtual Web Server
ESnet webmaster been doing the Twiki hosting for other internal/external services
ESnet uses a particular version of Twiki & template to produce new Twikis
04 Sep 2004 $Rev: 1742 $
Wants to maintain 1 version across the Enterprise
TAGPMA is one of them
Same set of Security features imposed on all the TWikis
ESnet Web master told that its time upgrade all the TWikis.

4. Architecture http://tagpma.es.net readonly mode
Open for anyone
Variables in use & Modified TWiki modules
SSL Client Authentication
“%Remote User”
$WikiName, WikiUsername
TWikiRegistration.txt
~/lib/TWiki.cfg
~/lib/TWiki.pm
Edit & Add
IGTF Accredited CAs
Open to IGTF community
Pre-Registration script, which populates the .htpasswd file for Apache
%RemoteUser
%Certificate

5. Certificate Based Authentication
RCS(Revision Control System) check-in problem
$SubjectDN is not the same as the $username
Spaces in SubjectDN caused problem
So modified ~/lib/Twiki/Store/RcsWrap.pm
Side effects
SubjectDN is not in compliance with WikiName format, so dead link for that SubjectDN.
The original SubjectDN also not in compliance with WikiName
Every page will have Main.DC=org, DC=doegrids, OU=People,CN=FirstName_LastName_98765 instead of Main.FirstnameLN
There are actually 2 problems here.
1.The RCS requires the USERNAME to be without any space.
fix: That was fixed by changing the RcsWrap.pm module to replace ‘space’ with’_’.
2. The subjectDN itself is not a wikname.

6. Certificate Based Authentication
Fixes
DN in reverse order
Show only the CN for.eg Main.CN=FirstName_LastName_98765
Preferably WikiName instead for
RCS checkin in
Showing page owner or modified by
…..these are still in progress. Because we have already seen a TWiki plug-in not working. For Eg. Table creation.

7. Registration Automation
Pre-Registration and Twiki Registration
certificates for Pre-Registration
then Twiki registration
We couldn’t extract the SubjectDN, if we simply accept the the certificate based on the trust anchors, without Pre-Registration
We need to have a .htpasswd at apache level to extract the SubjectDN for Twiki Registration
Initially we had a separate web server just to do the SSL Client authentication to generate the .htpasswd file (Pre-Registration)

8. Registration Automation
Then we were able to extract the SubjectDN and pre-fill the Twiki registration
We were able to combine the Pre-Registration Script with Twiki (in a single web server)

9. Problems&/Solutions The trust anchors created few problems
Apache doesn’t throw error messages, if there is a problem with the config; it just skip the the config and continue to load the rest.
What if the user wants to use a certificate, which was issued by untrusted CA?. The error message wasn’t helpful.
Pre-registration and Twiki registration is not complete
The SubjectDN can have special characters which causes the pre-registration to fail
Still needs filter special characters at the Twiki registration
Still needs to map the SubjectDN to WikiName

10. Problems&/Solutions
Any error in apache configuration for Certificate authentication causes a pop-up window for the end user asking for userid/password. The error message are not configurable for certificate based authN.
Strange behavior in using +OptRenegotiate with SSLOptions (in apache config).
This flag was used to stop the certificate re-authentication pop-up with Mozilla/Firefox family browser.
undesired behavior for the clients those who uses external token like aladdin’s eToken. Those users often get ‘permission denied’ error, and they have to refresh, every page they go-to. One can also fix this problem by selecting ‘Select One automatically’ option with the browser in the Certificate Options.
We have also noticed the same behavior with few other users who don’t use external tokens.
Twiki shows a ‘?’ and a dead link for any name which is not in compliance with defined Regular Expression for all the names (~/lib/Twiki.pm)

11. Suggestion&/Solutions
May be we need a different technology to map the SubjectDN to WikiUserName; something like openid???