[Freeipa-devel] OTP Sync Client

[Nathaniel McCallum]

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?

Attached is a first attempt at implementing a sync client. It works, but
isn't ready for merger. Please help me suggest ways to overcome the
various problems:

1. This requires a krb5 TGT in order to perform the command. I am
assuming that everything in execute() is happening on the server-side
and the server wants authentication. Obviously, we can't require a TGT
to sync the token.

2. If a TGT *is* present, it would be really nice to bypass the
username/password options entirely and do a SASL bind (from the client?
Is 389DS guaranteed to be available to the client?

3. There has to be a better way to get the LDAP URI than what I'm doing.

4. I have concerns about passing the password over the wire. We are
doing this two places:
  A. client => freeipa
  B. freeipa => 389DS

Thoughts?

5. What should I do about the return value of the command?

Nathaniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-First-stab-at-sync-client.patch
Type: text/x-patch
Size: 5294 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140220/02eae21b/attachment.bin>