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.

Nathaniel

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

Reply via email to