On 04/15/2011 06:35 AM, Sumit Bose wrote:
On Fri, Apr 15, 2011 at 11:22:36AM +0200, Linus Nordberg wrote:
> 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
Since the handling of OTP tokens from different vendors will be
different I think it is ok to have vendor/device specific names here,
too. The mid-term idea is, that the pre-authentication plugin will do
all the comminication as defined in the IETF OTP preauth draft and that
the plugin is able to load vendor specific code to process the data.
One of the questions we need to answer is: "Is vendor specific data
searchable and sortable"? and another "how different it is from vendor
to vendor and from account to account"
I think it should not be searchable and sortable and it is vendor specific.
Also in a general case there will be accounts that are handled by one
authentication method and accounts by another authentication method in
the same deployment.
So storing the vendor specific information in a single field/attribute
as a blob of data would probably be best and leveraging the extended
data or something similar will be a way to go. However the
authentication type or vendor type should probably be more generic.
This actually reminds me a lot of a vendor specific attribute in RADIUS.
May be we should explore it and do something like it.
And I wonder whether there should be a separate "authtype"
attribute/field that would indicate to the framework what kind of vendor
plugin should be used.
The more it think about it the more I would vote on adding two more
attributes to the KDB interface that the KDB layer would return to the
framework:
a) authtype - a string that would define the algorithm that the
framework should use:
examples:
- sent the whole value of the user provided credential to an
external auth plugin X
- split the passed in credential string and send last A symbols to
external auth plugin X while first part is a kerberos password
- split the passed in credential string between method X and method Y.
Something along those lines.
b) authmethoddata - a list of the vendor specific data blobs that will
be passed to the specific vendor plugins and handled by them.
The framework would just be able to identity which blob belongs to
each plugin and pass the right blob to right plugin.
In case of yubikey it is probably something simple like the mapping
ID, but there will be probably some other data in future so the blob
should probably consist of:
vendor id, version of the blob and then the rest of data
Here is the Vendor specific attribute spec for reference - it is in the
main RADIUS rfc.
http://wiki.freeradius.org/RFC
> 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?
The easiest way would be a generic struct in struct _krb5_db_entry_new
which has an enum which indicates the backend type and a pointer which
points to the additional backend specific data. I don't know if MIT will
like this idea.
>
> | 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!
>
> _______________________________________________
> authhub-devel mailing list
> authhub-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/authhub-devel
_______________________________________________
authhub-devel mailing list
authhub-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/authhub-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/