Sumit Bose <sbose(a)redhat.com> wrote
Fri, 15 Apr 2011 10:41:24 +0200:
| > I suggest we split the actual data representation in LDAP schema or
| > whatever back end is used from the data model and information needed by
| > the plugin(s) to do the work. The ID is just one piece of the puzzle.
| > IMO in a generic case there should be an attribute of the account that
| > would dictate what kind of the external authentication is required for
| > such account and then depending on the type of the external
| > authentication a blob of data that defines method specific properties
| > like a Yubikey ID in Yubikey case. It can have other information two.
| > This info will me method specific and processed by the vendor plugin.
| >
|
| yes, I think the issue is two-fold here. First we want a simple
| representation of the data relevant for the special OTP method/device.
| Here I think it would be the most easiest way that vendors will
| provide their own objectclasses for their products because with a
| common objectclasses it might get difficult if a user have multiple
| different OTP devices.
And KDC plugin(s) know the names of the attributes to look for? Sounds
good from a deployment pov too. We'd have to be OK with supporting only
LDAP as a kdb backend though i suppose.
| Second the Kerberos preauthentication plugin needs to have access to the
| data. I'm not sure if it might be possible to find a solution which will
| work with all available kdb backends, so I will concentrate on LDAP
| here. In general it would be possible to open a new connection the to
| LDAP server and read the needed attributes directly in the plugin. But
| since the KDC has already read data about the principal from the LDAP
| server I would not prefer this solution.
Agreed.
| Currently I have only found the
| tagged data stored in the krbExtraData which is suitable for arbitrary
| data, with the benefit that it will work with all kdb backends. But in
| general it would be nice if the kdb LDAP backend can be extended in a
| way that it will read all user attributes and present them to the
| pre-authentication plugin with the other Kerberos related data read from
| the LDAP server.
For not having to loop over the tl_data list? What do you think would
be a good way of presenting it to the plugin?
| If you want to do this manually you have to add
| 0x0800 before the ID, terminate it with 0x00 and encode the
| result with base64.
This is exactly how I'm doing it, except I'm doing it by hand for now.
Thanks for the nice script!