TAGPMA Twiki

1. TAGPMA Twiki http://tagpma.es.net dhiva@es.net & helm@es.net

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

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 • https://tagpma.es.net • 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

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 a 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???