On 01/23/2014 09:41 AM, Nathaniel McCallum wrote: > 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.
While I agree that we can it would be more intuitive to the user if he does it for a specific token. So in CLI the argument ipatokenuniqueid should be token id or user id > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel