[Freeipa-devel] OTP Sync Client

[Dmitri Pal]

On 01/23/2014 09:41 AM, Nathaniel McCallum wrote:
> On Thu, 2014-01-23 at 10:28 +0100, Petr Vobornik wrote:
>> 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.
> Thanks!
>
>>>> 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
> I'm not quite sure what the purpose of this is. Why do we have to bother
> the user with selecting which token to synchronize when we can easily do
> this algorithmicly? The user doesn't pick which token to use when
> logging in. I'm not sure why syncing should be any different.

While I agree that we can it would be more intuitive to the user if he
does it for a specific token.

So in CLI the argument ipatokenuniqueid should be token id or user id

>
> Nathaniel
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/