[Freeipa-devel] OTP Sync Client Design

Thu May 15 11:40:15 UTC 2014

On 15.5.2014 00:23, Dmitri Pal wrote:
> On 05/14/2014 05:49 PM, Nathaniel McCallum wrote:
>> On Wed, 2014-05-14 at 17:35 -0400, Dmitri Pal wrote:
>>> On 05/14/2014 05:23 PM, Nathaniel McCallum wrote:
>>>> On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote:
>>>>> On 05/14/2014 02:08 PM, Nathaniel McCallum wrote:
>>>>>> Occasionally OTP tokens get out of sync with the server. When this
>>>>>> happens, the user or an admin need to synchronize the token. To this
>>>>>> end, we landed server-side synchronization support, which is a simple
>>>>>> bind with a custom control. This all works with my sample test
>>>>>> script.
>>>>>>
>>>>>> Client support is proving a bit more difficult. In the ideal
>>>>>> world, the
>>>>>> client would contact LDAP directly and perform the operation. This
>>>>>> would
>>>>>> make a man in the middle attack difficult and we can ensure
>>>>>> encryption
>>>>>> over the entire operation.
>>>>>>
>>>>>> However, browsers, without server-side assistance, cannot perform
>>>>>> this
>>>>>> operation from javascript. This means that, in this case, the first
>>>>>> factor and two second factors must be transmitted to the FreeIPA
>>>>>> server
>>>>>> and then proxied to 389. Is this an acceptable compromise?
>>>>> Does Javascript have a way to encrypt things?
>>>>> May be we should do some encryption before sending the values over
>>>>> the wire?
>>>>> On the other hand we are OK with the form based login so I am not sure
>>>>> if there is any value.
>>>> Yes, but I agree there is not a lot of value.
>>>>
>>>>> We might have some logic related to permissions i.e. members of the
>>>>> admin group can only sync on server but I am not sure that is
>>>>> something
>>>>> we should consider out of box.
>>>>>
>>>>> In any way IMO it should be a separate page, other than login page
>>>>> that
>>>>> can be accessed by anyone. It should be visible outside firewall like
>>>>> other OTP vendors do. This would allow to use a mobile device to
>>>>> sync up
>>>>> a token (and potentially change the password).
>>>> This would be nice.
>>>>
>>>>>> This command also needs to be accessible *without* an existing user
>>>>>> login since, if a user's token is out of sync, the user can't
>>>>>> login. Is
>>>>>> it possible to expose such an API? If so, how? Both "ipa env" and
>>>>>> "ipa
>>>>>> ping" seem to require kinit, so I don't see any obvious examples.
>>>>> IMO SSSD should probably have a way to sync the token.
>>>>>   From usability point of view it should be a part of the standard
>>>>> stock
>>>>> client software, not a part of the IPA client or ipa tools.
>>>>> It should probably have a good UI integration too if token is used to
>>>>> login into a laptop.
>>>> SSSD has direct access to LDAP right? If so, it can just do a bind with
>>>> the added control. That is actually the easiest way.  Trying to access
>>>> via a third API is probably actually more difficult.
>>>>
>>>>> So for that to happen we should probably expose this interface over
>>>>> D-BUS.
>>>>> This is what we talked about with the desktop folks some time ago.
>>>>> The attached is the doc and there are diagrams at the end that show
>>>>> what
>>>>> we decided needs to be done.
>>>>> Similar to that one can provide a simple otp-sync application that
>>>>> will
>>>>> sync using command line (but on the other hand may be it should just
>>>>> warp curl?).
>>>> How exactly we expose this in GDM is indeed a much more complicated
>>>> question and needs to be part of the next phase of integration. I've
>>>> CC'd jhrozek for this part.
>>>>
>>>>> Some thoughts came up while writing this mail:
>>>>>
>>>>> a) We can go the complex path and provide password and sync
>>>>> capabilities
>>>>> in every client. This is a lot of work based on my past experience and
>>>>> can't be done quickly. See the complexity of the diagrams and flows in
>>>>> the attached doc. And may be it should not be.
>>>> The synchronization needs to be added to whatever layer has access to
>>>> the LDAP server. How it is exposed from there is specific to each
>>>> application.
>>>>
>>>>> b) May be IPA should provide a portal/proxy to do self service token
>>>>> sync and/or password change. This can be a URL. It should be
>>>>> possible to
>>>>> access it externally outside the firewall. It should be bullet proof.
>>>>> But then we need just one interface and one call and we can use it
>>>>> from
>>>>> mobile device or some other system on the internet to self service the
>>>>> token and then pass authentication. IMO that would save us a lot of
>>>>> time
>>>>> and effort. I know other OTP vendors went this path and were quite
>>>>> successful.
>>>> +1. This solves the VPN bootstrapping problem.
>>>>
>>>> However:
>>>>
>>>> 1. It should be available by default in the FreeIPA installation with a
>>>> link from the login page. This is just a matter of product polish.
>>>>
>>>> 2. In the case of a user logging into GDM, we have a bootstrapping
>>>> problem that they can't login without a token, and they can't sync
>>>> their
>>>> token without logging into a browser. GDM/SSSD probably needs to
>>>> support
>>>> this natively.
>>> True but not from day one.
>>> This is why I mentioned a mobile device.
>>> Keeping in mind that FreeOTP is on the mobile device and there is a good
>>> chance that the person who will have a Linux laptop will have a mobile
>>> device.
>>> They can also call a helpdesk and ask the helpdesk engineer to sync the
>>> token for them.
>>> That means that there should be an admin interface that would not
>>> require the first factor just two codes.
>> Yup. Agreed. Just thinking big picture.
>>
>> Nathaniel
>>
>>
> So it looks like that we agree that:
>
> a) IPA should provide a special page to do resync and or password change.
+1

These pages should not point to our UI but they might provide a 
mechanism for redirecting to other page on success if supplied.

We already provide separate page for password reset which can be exposed.

http://pvoborni.fedorapeople.org/ui/reset_password.html

> b) This page can be linked off the login page

in addition to the separate pages, the otp-sync interface might be also 
integrated in Web UI app in a same way as password reset:

http://pvoborni.fedorapeople.org/videos/reset_pw_on_login.webm

> c) Desktop would need to be integrated (in future but not now)
> d) There should be an internal page/CLI that would allow admin or token
> owner to resync the token without providing the first factor (future).
>
> It also occurred to me that the workflow can be:
>   User can't log in
>   He calls helpdesk
>   Admin disables his token for a period of time (day, hour - policy
> defined) allowing user to log in and resync it
>   User logs with the password part
>   User goes to his portal because he knows that token will be auto
> reenabled after some time.
>   User resyncs the token
>   Token auto enables itself
>
>   IMO this would be a nice optimization in future.
>   We can also recommend always having a backup software token on the
> mobile device just in case.
>
> Bottom line: in modern world portal + backup alternative token on mobile
> device would address most of the scenarios, also people will tell us
> what problems they face and what we should address next.
>
> We probably should have a "Token owner guide" that would talk about
> these scenarios and help people to resolve them.
>
>
-- 
Petr Vobornik