On Mon, 09 Mar 2015, Martin Kosek wrote:
On 03/09/2015 02:02 PM, Nathaniel McCallum wrote:
On Mon, 2015-03-09 at 08:00 +0100, Stanislav Láznička wrote:
Hi!

My name is Stanislav Laznicka and I am a student at Brno University
of Technology. As a part of my Master's thesis, I am supposed to
design and
implement time-based account policies extensions for FreeIPA and
SSSD.

While going through the code, I noticed time-based access control
was implemented in the past, but it was pulled. I would very much be
interested to know why that was and what were the problems with that
implementation (so that I don't repeat those again).

The solution to the time-based account policies as I see it can be
divided into two possible directions - having the time of the
policies stored as a UTC time (which is what both Active Directory
and 389 Directory Server do), or it can be just a time record that
would be compared to the local time of each client.

Each of the approaches above has its pros and cons. Basically, local
time approach is much more flexible when it comes to multiple time
zones, however it does not allow the absolute control of access as
the UTC time based approach would (or at least, it does not allow it
without
some further additions). I would therefore also be interested to
hear from you about which of these approaches corresponds more to
the common use-case of the FreeIPA system.

I would be deeply worried about the unexpected security issues that
could arise if local time was used by default.

Nathaniel

My comments for the options:

* Control in UTC time: easy to evaluate on client even when user (or anyone
else) misconfigured the time zone. However, implementation is more difficult:
 - For rules like "person X can interactively log in from 8:00 to 17:00", you
would need separate HBAC rule for each time zone as UTC range would differ
HBAC rules are applied on the client anyway so applying local time
correction is fine in both cases. The problem is then with HBAC rule
testing ('ipa hbactest') which runs on IPA master and would need to gain
ability to handle local time per client too. And this is not an easy
task.

 - On the other hand, one can create simple rule "person X can use company
resources from 8:00 EST to 17:00 EST, in whichever time zone they are located)
 - FreeIPA would need some helper UI (or even zone indication stored with
host/hostgroup) that would help set up the access in local time and save in UTC
time
UI/CLI helpers are smaller issue if we can agree on the basic
functionality.

One of bigger issues we had was lack of versatile ical format parser to
handle calendar-like specification of events -- we need to allow
importing these ones instead of inventing our own.

Another issue is that often rule does depend on a details about specific
service -- it is common to have web services to use different timezone
than the rest of processes running on the server. You would get an HBAC
rule where something like apache service is defined but you'd need to
associate timezone with it and have this association to be specific to a
server or group of servers rather than just a service itself.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to