[Freeipa-devel] OTP Sync Client Design

[Jan Cholasta]

On 26.5.2014 18:23, Nathaniel McCallum wrote:
> On Mon, 2014-05-26 at 09:56 +0200, Jan Cholasta wrote:
>> On 23.5.2014 23:19, Nathaniel McCallum wrote:
>>> On Wed, 2014-05-14 at 14:08 -0400, 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?
>>>>
>>>> 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.
>>>
>>> Thanks everyone for your feedback. This particular feature is proving
>>> difficult to implement, even with our agreed upon design. To reiterate
>>> this design: there will be an HTTP method by which to synchronize
>>> tokens.
>>>
>>> There are two assumptions in the code which are making this difficult:
>>> 1. All cli commands are Command subclasses.
>>> 2. All Command subclasses create authenticated server methods.
>>>
>>> There are thus two ways to tackle this problem.
>>>
>>> First, I can create a standard POST method in rpcserver.py. This is not
>>> very modular. But the biggest problem is that there is no way to create
>>> the cli-side command to call it (assumption #1).
>>
>> Well, you could derive the command from ipalib.frontend.Local and
>> manually call the POST method from it.
>
> This still creates a (NoOp) server-side RPC method, right? We can
> probably just accept this as a drawback for now and move on. After a
> future refactoring of rpcserver.py, we can move the manual POST method
> into this server-side RPC method.

I agree, I think there's no harm in having a placeholder RPC method.

-- 
Jan Cholasta