HDB layer ideas

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

HDB layer ideas

Andrew Bartlett
I've been chatting with lha on IRC about HDB, but I wanted to bring
these things to the list, for a more concrete discussion:

I've been thinking about how I would like (in my ideal world) the HDB
layer do develop, in support of Samba4's use of Heimdal.

The particular feature I'm after in extending HDB is a private pointer,
based on an encapsulation of the existing asn.1 hdb_entry:

struct hdb_container {
        hdb_entry *entry;
        void *private;
}

I would then add a new hdb_free_entry() method, to free hdb_container
(and the backend-specific private).

The reason I'm after the private structure is to store extra state
between hdb_fetch() and hdb_modify().  This state would be backend-
specific, but the intention is for it to be a handle onto the user's
record.

This is to allow something similar to what we have in Samba 3.0, where
our passdb abstraction layer uses a strategy for minimal LDAP
modifications:  We record changes to the Samba side of the record, and
using the DN from the original fetch for the modify.  This helps avoid
extra (potentially ambiguous) searches, and can even allow some
'transaction safety' in the LDAP operation.

My other reason for proposing this structure is that I want to extend
the hdb functions, to go beyond just a database layer.  To match AD
behaviour, I am going to need to extend Heimdal's access control layer,
adding something like hdb_access_check(entry, ip, ...).  

It would be good if the entry here were a reference to the search
results from hdb_fetch(), so I don't have to find the user again.  A
similar problem applies for the PAC fetch and password set:
hdb_fetch_pac(entry, &pac), and hdb_set_password(entry, password) would
likewise need to handle things in a backend specific manner.

My hope is that with these hooks, we can integrate Samba and Heimdal
closely, in the hope of avoiding logic duplication in this critical
area.

Thoughts?  Flames?  Experiences?

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HDB layer ideas

Luke Howard

For XAD, we used Love's proposal for HDB extensions (omissions for
compactness):

hdb-ext ::= CHOICE {
        pkinit-acl[0]   hdb-ext-pkinit-acl,
        pkinit-cert[1]  hdb-ext-pkinit-certificate,
...
}

hdb-extension ::= SEQUENCE {
        mandatory[0]    BOOLEAN,        -- kdc MUST understand this extension,
                                        --   if not the whole entry must
                                        --   be rejected
        data[1]         hdb-ext
}

hdb-extensions ::= SEQUENCE OF hdb-extension

hdb-entry ::= SEQUENCE {
        principal[0]    Principal  OPTIONAL, -- this is optional only
                                             -- for compatibility with libkrb5
...
        extensions[13]  hdb-extensions OPTIONAL,
...
}

The only problem with this solution is that it doesn't deal well with
types that can't be represented in ASN.1, or that need to be defined
at runtime (eg. by a loadable HDB module).

There might be some interesting solutions to this, I'll have to think
some more...

-- Luke

--
Reply | Threaded
Open this post in threaded view
|

Re: HDB layer ideas

Love Hörnquist Åstrand
In reply to this post by Andrew Bartlett

Andrew Bartlett <[hidden email]> writes:

> I've been chatting with lha on IRC about HDB, but I wanted to bring
> these things to the list, for a more concrete discussion:
>
> I've been thinking about how I would like (in my ideal world) the HDB
> layer do develop, in support of Samba4's use of Heimdal.
>
> The particular feature I'm after in extending HDB is a private pointer,
> based on an encapsulation of the existing asn.1 hdb_entry:
>
> struct hdb_container {
> hdb_entry *entry;
> void *private;
> }
>
> I would then add a new hdb_free_entry() method, to free hdb_container
> (and the backend-specific private).
So what I like about the current interface (just talking about the
interface, not content), is that each entry is free-standing from the
backend, no reference counting, no locking, no thread issues.

One idea I have is splitting the KDC into a crypto part and a protocol part
to protect the long term keys in case of a compromise, and adding stuff
like hdb_access_chec, hdb_get_pac, and hdb_verify_pac [1] might complicate
the model.

When thinking about it, it might not be that bad, and really, the KDC
should't really need to write into the HDB layer (never call ->hdb_store) ,
so there isn't much need for transaction safefy ? And to provide you with
hooks to the real entry, just create a one entry cache in the hdb backend
should do it.

Love


[1] Shouldn't these last two be hdb_{add,verify}_authorization_data ?

attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HDB layer ideas

Love Hörnquist Åstrand
In reply to this post by Luke Howard

Luke Howard <[hidden email]> writes:

> The only problem with this solution is that it doesn't deal well with
> types that can't be represented in ASN.1, or that need to be defined
> at runtime (eg. by a loadable HDB module).
>
> There might be some interesting solutions to this, I'll have to think
> some more...

So this is diffrent from what andrew what to happen, he want to modify the
API, not the storage.

I think I figured out how add support for unknown entries. The new compiler
have a feature where it store all unknown CHOICE branches into a generic
container. So the extention update code contains this comment for the known
case:

        /*
         * This is an unknown extention, and we are asked to replace a
         * possible entry in `entry' that is of the same type. This
         * might seem impossible, but ASN.1 CHOICE comes to our
         * rescue. The first tag in each branch in the CHOICE is
         * unique, so just find the element in the list that have the
         * same tag was we are putting into the list.
         */

So all you need is a tag-number from me to make sure the are unique. I can
provide that uniqueness.

I've not figure out all implication of this for the admin interface and the
propagation interfaces. Hprop is easy, just overright. Iprop is diffrent,
should an update just update one extention, or overright all data.

I've written all code, but haven't commited it yet since its missing
regression tests.

Love


attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HDB layer ideas

Andrew Bartlett
In reply to this post by Love Hörnquist Åstrand
On Tue, 2005-07-19 at 14:09 +0200, Love Hörnquist Åstrand wrote:

> Andrew Bartlett <[hidden email]> writes:
>
> > I've been chatting with lha on IRC about HDB, but I wanted to bring
> > these things to the list, for a more concrete discussion:
> >
> > I've been thinking about how I would like (in my ideal world) the HDB
> > layer do develop, in support of Samba4's use of Heimdal.
> >
> > The particular feature I'm after in extending HDB is a private pointer,
> > based on an encapsulation of the existing asn.1 hdb_entry:
> >
> > struct hdb_container {
> > hdb_entry *entry;
> > void *private;
> > }
> >
> > I would then add a new hdb_free_entry() method, to free hdb_container
> > (and the backend-specific private).
>
> So what I like about the current interface (just talking about the
> interface, not content), is that each entry is free-standing from the
> backend, no reference counting, no locking, no thread issues.
>
> One idea I have is splitting the KDC into a crypto part and a protocol part
> to protect the long term keys in case of a compromise, and adding stuff
> like hdb_access_chec, hdb_get_pac, and hdb_verify_pac [1] might complicate
> the model.
>
> When thinking about it, it might not be that bad, and really, the KDC
> should't really need to write into the HDB layer (never call ->hdb_store) ,
> so there isn't much need for transaction safefy ? And to provide you with
> hooks to the real entry, just create a one entry cache in the hdb backend
> should do it.
Are you implying that we should have a static variable in the backend
for this, or something different.  I really want to avoid that if
possible, particularly when there is perfectly adequate context variable
(the entry) that can be extended.

> [1] Shouldn't these last two be hdb_{add,verify}_authorization_data ?

Probably :-)

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment