[Freeipa-devel] OTP Sync Client Design

Dmitri Pal dpal at redhat.com
Wed May 14 20:34:54 UTC 2014


On 05/14/2014 02:08 PM, Nathaniel McCallum wrote:
> Occasionally OTP tokens get out of sync with the server. When this
> happens, the user or an admin need to synchronize the token. To this
> end, we landed server-side synchronization support, which is a simple
> bind with a custom control. This all works with my sample test script.
>
> Client support is proving a bit more difficult. In the ideal world, the
> client would contact LDAP directly and perform the operation. This would
> make a man in the middle attack difficult and we can ensure encryption
> over the entire operation.
>
> However, browsers, without server-side assistance, cannot perform this
> operation from javascript. This means that, in this case, the first
> factor and two second factors must be transmitted to the FreeIPA server
> and then proxied to 389. Is this an acceptable compromise?

Does Javascript have a way to encrypt things?
May be we should do some encryption before sending the values over the wire?
On the other hand we are OK with the form based login so I am not sure 
if there is any value.

We might have some logic related to permissions i.e. members of the 
admin group can only sync on server but I am not sure that is something 
we should consider out of box.

In any way IMO it should be a separate page, other than login page that 
can be accessed by anyone. It should be visible outside firewall like 
other OTP vendors do. This would allow to use a mobile device to sync up 
a token (and potentially change the password).


>
> This command also needs to be accessible *without* an existing user
> login since, if a user's token is out of sync, the user can't login. Is
> it possible to expose such an API? If so, how? Both "ipa env" and "ipa
> ping" seem to require kinit, so I don't see any obvious examples.

IMO SSSD should probably have a way to sync the token.
 From usability point of view it should be a part of the standard stock 
client software, ho t a part of the IPA client or ipa tools.
It should probably have a good UI integration too if token is used to 
login into a laptop.

So for that to happen we should probably expose this interface over D-BUS.
This is what we talked about with the desktop folks some time ago.
The attached is the doc and there are diagrams at the end that show what 
we decided needs to be done.
Similar to that one can provide a simple otp-sync application that will 
sync using command line (but on the other hand may be it should just 
warp curl?).


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

Some thoughts came up while writing this mail:

a) We can go the complex path and provide password and sync capabilities 
in every client. This is a lot of work based on my past experience and 
can't be done quickly. See the complexity of the diagrams and flows in 
the attached doc. And may be it should not be.
b) May be IPA should provide a portal/proxy to do self service token 
sync and/or password change. This can be a URL. It should be possible to 
access it externally outside the firewall. It should be bullet proof. 
But then we need just one interface and one call and we can use it from 
mobile device or some other system on the internet to self service the 
token and then pass authentication. IMO that would save us a lot of time 
and effort. I know other OTP vendors went this path and were quite 
successful.

Thoughts?


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: UI Integration plans rev3.odt
Type: application/vnd.oasis.opendocument.text
Size: 63051 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140514/66dea876/attachment.odt>


More information about the Freeipa-devel mailing list