[horde] ActiveSync login & client-side certificates

[Michael J Rubinsky]

Quoting "Jens-U. Mozdzen" <jmozdzen at nde.ag>:

> 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.

This is only true if using FakeBasicAuth though, right? Why don't you  
disable that in your Apache config? ActiveSync clients MUST support  
using BOTH client certificates and basic auth - it's part of the  
protocol. Exchange server explicitly allows for configuring using one,  
the other, or both together, so it's doubtful this issue is anything  
client related (assuming your client is smart enough to actually  
support client certificates to begin with).

> 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!

Again, this is only if you configure it to do so. It can also function  
without this, and can pass the certificate information to PHP in  
various environment variables. In fact, in Horde 5.2, there are  
numerous hooks available that allow you to inspect those values, check  
them against some custom data, alter authentication credentials etc...


> 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,

It should. That's what the specification requires (see above).

> but once it hits httpd with it's fake basic auth, that information  
> is lost anyhow.

It shouldn't *have* to be lost. Again, don't configure Apache to  
overwrite http basic auth.


> 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.

I have a test server that does exactly this (albeit with Horde 5.2,  
but that shouldn't matter for this discussion).

> 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.

Exactly. This is what the X509 auth driver allows.


-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5869 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/horde/attachments/20140528/a3f165d2/attachment-0001.bin>