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

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

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.

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

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.

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.

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)

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)

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

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)

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