[horde] ActiveSync login & client-side certificates

[Jens-U. Mozdzen]

Hi Mike & all,

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
> Quoting "Jens-U. Mozdzen" <jmozdzen at nde.ag>:
>> [...] I just don't understand why Horde's AS module uses that,  
>> instead of the username as passed in the GET parameter or POST value.

I have done some debugging and would like to report back my results,  
so that maybe others looking for this information can take a shorter  
path.

My original problem was that I was unable to set "client-side  
certificate"-based access restrictions on  
htts://my.horde.com/Microsoft-Server-ActiveSync without losing the  
ability for my client to log in successfully via username and password.

It seems to me that the client actually tries to log in via HTTP  
mechanics ("basic authentication").

The basic auth username and password are passed on unvalidated from  
httpd to mod_php, which puts these values in the list of server  
variables (PHP_AUTH_USER and PHP_AUTH_PW), where they are read by  
Horde, passed on to the configured authentication mechanism and there  
checked for validity. (I have no idea how the validity state is passed  
back to the PHP and then web server layer, probably implicitly via  
HTTP status codes - if 4xx, the credentials are invalid, if not 4xx,  
then they are)

Using client-side certificates with Apache httpd 2.2 does conflict  
with this: At least from httpd to mod_php (maybe already starting at  
the client) CSCs are treated as a special case of basic auth. In the  
Apache configuration, you specify the CSC's DN as the username and set  
a dummy password. Once the CSC is validated via CA mechanisms, these  
two values (DN and dummy pw) are those that are passed on to mod_php!

As my stock Android email EAS client asks for the CSC *and* a username  
*and* a password, I cannot tell if the client sends basic auth data  
(username/password as configured) in addition to the client  
certificate, but once it hits httpd with it's fake basic auth, that  
information is lost anyhow.

As a result, you cannot configure httpd access restrictions to  
/Microsoft-Server-ActiveSync at the httpd level, like you can do for  
user web access to Horde, and still have Horde log you in via your  
username and password.

But at least the DN of the CSC is passed to mod_php (in  
SSL_CLIENT_S_DN), so instead, access restrictions based on the DN  
could be implemented at the Horde level, i.e. via hooks.

Mike, thank you for your patience and guidance - I now understand why  
my attempts are failing and why I cannot do what I originally wanted  
to achieve (CSC-based access restrictions for ActiveSync clients at  
httpd level).

With regards,
Jens