[horde] ActiveSync login & client-side certificates

[Michael J Rubinsky]

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

> Hi Mike,
>
> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>> Quoting "Jens-U. Mozdzen" <jmozdzen at nde.ag>:
>> [...]
>>> When I do not impose access restrictions on  
>>> /Microsoft-Server-ActiveSync (via httpd.conf, see above), then  
>>> obviously the username from the "User" parameter of the http  
>>> request is used  
>>> ("/Microsoft-Server-ActiveSync?Cmd=OPTIONS&User=***userid***&DeviceId=**devid***&DeviceType=***devicetype***") and the password is most probably "in-band" within the requests data. In horde's log I then see the corresponding "userid at mydomain has logged on" messages (this is no quote from the actual log ;) ). Apache httpd from then on logs all ActiveSync requests with the username in its access_log - although this username is nowhere defined in Apache's user datebase, so I guess that information is somehow retrieved from the PHP side of things after a successful login per the Horde ActiveSync  
>>> module.
>>
>> If you are interested in where the username and password comes  
>> from: ActiveSync uses the data from HTTP BASIC authentication. In  
>> addition, the username is also passed in either (depending on the  
>> EAS version) the GET parameters or in a base64 encoded POSTed value  
>> that includes all of the other EAS required parameters.
>>
>>> Once I set up the above restriction (limit access to  
>>> /Microsoft-Server-ActiveSync to DNs contained in an httpd user  
>>> group), I see that Horde ActiveSync tries to log in the user via  
>>> the certificate's DN, rather than the value from the "User"  
>>> parameter of the actual request.
>>
>> Is is possible Apache is sending the DN in the HTTP Auth headers?
>
> Yes, everything seems to point in that direction. 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.

Because a number of clients don't pass that value accurately - some  
clients pass that value as ONLY the username (and not the email) even  
if the full email is entered as the username on the client. The HTTP  
Auth always contains the full username, even if it's entered as the  
email address.

> Those latter values seem more "precise", and my case does indeed  
> show the distinction between a web server authentication and the  
> ActiveSync authentication. Of course, the EAS user & password is  
> required for auth against the mail server, too.

Horde doesn't support different usernames for Horde vs IMAP server  
when using ActiveSync. The protocol only supports a single  
authentication.


> As a matter of fact, the same holds true for the standard web  
> interface: No matter if I need a ("client-side certificate"-based)  
> authentication to the web server, there's the need to log in to  
> Horde for the same reason.

That's an infrastructure issue. There are ways to do this without  
logging into Horde, but they might not be right for your situation.  
Horde 5.2 introduced support for certificate authentication, and has  
several hooks that can be used to tweak the authentication setup.

>>> What I'm looking for is a way to make Horde still use the username  
>>> from the ActiveSync request, rather than the DN, even if the  
>>> client used a certificate to successfully establish authentication  
>>> with httpd.
>>
>> I'm pretty sure this is how it works in Horde 5.2 when you select  
>> X509 certificates on top of normal HTTP Auth, but I'll have to  
>> double check.
>
> Again, I believe the right default way of doing this is to use the  
> credentials passed in the AS request and to ignore any  
> authentication established with the web server.

No, because the credentials passed in the AS request *are* the HTTP  
auth credentials. That's where ActiveSync gets the credentials from.  
There is no other place that ActiveSync sends a password.  If you want  
to ignore the web server credentials, you should tell Apache to not  
send the certificate data in the HTTP Auth headers.

Also, AS also supports X509 authentication WITHOUT credentials, and  
must be able to rely on the information passed in the certificate.

In 5.2, Horde supports the following authentication strategies with EAS:

1) "Normal" HTTP Basic auth. The credentials are taken from the HTTP  
Auth headers.

2) Certificate auth. Only the validity and information in the  
certificate are taken into consideration. This has implications for  
infrastructure that requires a unique password per user for IMAP, and  
there are hooks available that you can use to tweak the authentication  
data if needed.

3) Combination - Uses HTTP auth headers, but only if the certificate  
is valid. Again, a number of hooks are available to customize what  
constitutes a "valid" certificate.


> Allowing to use the latter at the discretion of the admin, with all  
> possible consequences, is of course something that may be helpful to  
> some. So I'm not saying using pre-authentication by the web server  
> should not be possible - just *optional*.

As stated above, it's not possible to ignore web server  
pre-authentication if the web server sends this information in HTTP  
Auth headers, since that is where the credentials are taken from, as  
per the ActiveSync specification.


> Concerning H5.2: Currently I have to stick to the PEAR releases, so  
> I cannot say anything about the upcoming new release. But I'll try  
> to find the time to look at 5.1's AS code to see if I find anything  
> concerning this topic.

There is nothing different in the ActiveSync library concerning  
certificate support. That lives Horde (the related hooks), the  
(stable) Auth pacakge, and the (not yet released) "Core" package for  
adding the ability to choose between the different authentication  
mechanisms.


-- 
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/20140527/58e2b6eb/attachment-0001.bin>