[Freeipa-devel] OTP Sync Client

Petr Viktorin pviktori at redhat.com
Thu Jan 23 19:00:20 UTC 2014


On 01/23/2014 07:33 PM, Nathaniel McCallum wrote:
> On Thu, 2014-01-23 at 16:27 +0100, Jan Cholasta wrote:
>> Hi,
>>
>> On 23.1.2014 16:19, Rob Crittenden wrote:
>>> Nathaniel McCallum wrote:
>>>> On Wed, 2014-01-22 at 15:59 -0500, 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?
>>>>>
>>>>> Nathaniel
>>>>
>>>> Thanks for the responses so far!
>>>>
>>>> Does anyone have any suggestions on how to translate IDs to DNs? Should
>>>> I just pass IDs to the directory server and do the translation
>>>> internally? Thanks!
>>>
>>> Each plugin defines a get_dn() method. I'm not sure I've ever called
>>> this on the client side though you probably need an LDAP connection for
>>> this to work.
>>>
>>> The call would look something like:
>>>
>>> api.Object['user'].get_dn('admin')
>>
>> This returns "DN(('uid', 'admin'), api.env.container_user,
>> api.env.basedn)" by default, you can use that if get_dn does not work
>> for you.
>
> The problem is that we only need to convert the ID to DN when we *don't*
> have a connection to LDAP. Thoughts?
>
> Nathaniel

What Honza meant is that get_dn is preferable if you could use it, but 
since you can't, you can just use:
     DN(('ipatokenuniqueid', $TOKENID), api.env.container_otp, 
api.env.basedn)

This works since ipatokenuniqueid is the attribute used in the RDN (it 
has primary_key=True, and the otptoken object has rdn_is_primary_key=True).

-- 
Petr³




More information about the Freeipa-devel mailing list