[Freeipa-devel] [PROPOSAL] Kerberos flags

[Simo Sorce]

On Tue, 2013-03-12 at 18:31 +0100, Jan Cholasta wrote:
> On 12.3.2013 18:01, Simo Sorce wrote:
> > On Tue, 2013-03-12 at 17:31 +0100, Jan Cholasta wrote:
> >> On 12.3.2013 17:24, Simo Sorce wrote:
> >>> On Tue, 2013-03-12 at 17:02 +0100, Jan Cholasta wrote:
> >>>> Why can't we set the bitfield (krbTicketFlags) directly? (There is an
> >>>> ACI preventing that, I'm just wondering what is the reason for this.)
> >>>
> >>> If you tell me who 'we' is (as in what user would set it) I can tell you
> >>> why it is/isn't possible.
> >>
> >> Why no IPA user (including admins) can set the attribute?
> >
> > I guess admins should be allowed to.
> >
> > Users can't, as ticket flags change the behavior of the principal in
> > ways only admins should allowed to. (preauth required or not, AS
> > requests disabled or not, etc...)
> 
> Thanks. For normal users it's obvious, but it seemed a little bit 
> strange to disallow admins to set the flags.
> 
> So, can the krbTicketFlags attribute be used internally in IPA plugins 
> to set/unset the flags, given that the ACI is changed to allow admins to 
> modify the attribute?

The problem is determining if all the flags can be set by the same set
of admins or if we need to be able to delegate some of them. In the
second case we have only 2 options:
1) break the flags out in multiple attributes so we can set separate
ACIs
2) create a plugin that can intercept and filter modifications to the
attribute so only the allowed flags are changed

The first option has the problem that we are going to change the schema.
The second option has the problem that the check will be less flexible
than with regular ACIs (unless we use some sort of virtual ACI) and
duplicates access control points.

Anyway we need to find out if we really need fine grained access control
per flags or not before wrapping our heads.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York