[Freeipa-devel] OTP Sync Client

[Petr Vobornik]

On 22.1.2014 22:07, Nathaniel McCallum wrote:
> On Wed, 2014-01-22 at 16:03 -0500, Rob Crittenden wrote:
>> Nathaniel McCallum wrote:
>>> In attempting to write an OTP synchronization client, I've noticed it
>>> doesn't fit into the framework very well. The job of the client is to
>>> perform the synchronization extended operation. The format of the
>>> request is this:
>>>
>>>        OTPSyncRequestValue ::= SEQUENCE {
>>>            userDN            OCTET STRING,
>>>            tokenDN      [0]  OCTET STRING OPTIONAL,
>>>            firstFactor  [1]  OCTET STRING OPTIONAL,
>>>            firstCode         INTEGER,
>>>            secondCode        INTEGER
>>>        }
>>>
>>> In all cases, the user MUST provide two token codes and MAY provide the
>>> DN of a token to sync.
>>>
>>> >From here two cases exist: bound and unbound.
>>>
>>> In the unbound case, both the userDN and firstFactor fields are required
>>> and authentication is performed internally.
>>>
>>> In the bound case, the client has already bound (usually via a kerberos
>>> ticket). In this case, the client must provide userDN only. There are
>>> two options here. First, the client can generate the userDN
>>> automatically from the kerberos ticket metadata. Second, the extop
>>> plugin can make the userDN field optional and simply rely on the
>>> internal bind DN. This is my preferred route, and will require a new
>>> revision of the otp sync patch (no problem). In this second case, if the
>>> user is bound, the DS plugin would ignore the values of
>>> userDN/firstFactor.
>>>
>>> Assuming the second case to be true, how do I write a command in the
>>> framework that will attempt a krb5 bind and then prompt for
>>> username/password if the bind fails? Also, how do I, on the client side,
>>> without any bind to LDAP translate the username to the userDN? The same
>>> is true for the token ID to DN translation? Would it be better to write
>>> this code independently of the FreeIPA client command framework?

Look at ipaserver.rpcserver.login_password class. IMO the code shares a 
lot of similarities with your intentions.

>>
>> You can override the forward() command in the plugin to do client-side
>> work. There are a few examples, see service_show and
>> automountlocation_import. I just wonder how this would work in the UI.

>
> I believe the intention in the UI is to just handle the unbound case
> with no tokenDN option. It would essentially be a login screen that
> would look like this:
> Username: _______________
> Password: _______________
> First Token: _______________
> Second Token: _______________
>
> Nathaniel
>

+1 It could be further extended to a simple "token portal" where one 
could login via first factor and then list tokens and sync a selected 
token. The only issue is that it's quite hard to achieve this without 
binding(sending psw) in each request - IPA framework is not designed for 
such task. The issue is getting a session. If we were able to get a 
session we could use the method described below.


Second Web UI use case might be:

When user is logged in - via other "working" token or different auth 
method (i.e., password auth is enabled), he can:
- open OTP tokens page
- open some token details
- select 'sync' action
- enter OTP1, OTP2, confirm

This would require standard IPA command; something like `otptoken_sync 
ipatokenuniqueid --otp1=key1 --otp2=key2`
-- 
Petr Vobornik