On 05/14/2014 05:23 PM, Nathaniel McCallum wrote:
On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote:
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.
Yes, but I agree there is not a lot of 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 would be nice.

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, not 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.
SSSD has direct access to LDAP right? If so, it can just do a bind with
the added control. That is actually the easiest way.  Trying to access
via a third API is probably actually more difficult.

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?).
How exactly we expose this in GDM is indeed a much more complicated
question and needs to be part of the next phase of integration. I've
CC'd jhrozek for this part.

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.
The synchronization needs to be added to whatever layer has access to
the LDAP server. How it is exposed from there is specific to each
application.

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.
+1. This solves the VPN bootstrapping problem.

However:

1. It should be available by default in the FreeIPA installation with a
link from the login page. This is just a matter of product polish.

2. In the case of a user logging into GDM, we have a bootstrapping
problem that they can't login without a token, and they can't sync their
token without logging into a browser. GDM/SSSD probably needs to support
this natively.

True but not from day one.
This is why I mentioned a mobile device.
Keeping in mind that FreeOTP is on the mobile device and there is a good chance that the person who will have a Linux laptop will have a mobile device. They can also call a helpdesk and ask the helpdesk engineer to sync the token for them. That means that there should be an admin interface that would not require the first factor just two codes.

Nathaniel



--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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

Reply via email to