[Freeipa-devel] OTP Sync Client

Nathaniel McCallum npmccallum at redhat.com
Wed Jan 22 21:07:11 UTC 2014


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?
> 
> 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




More information about the Freeipa-devel mailing list