[Freeipa-devel] OTP Sync Client Design

[Dmitri Pal]

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.
b) This page can be linked off the login page
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.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.