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!

Nathaniel


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

Reply via email to