----- Original Message -----
From: "Martin Smith" <[EMAIL PROTECTED]>
> I wonder if it wouldn't be useful to permit a principal or a credential to
be an
> attribute in the user's (subject's) own entry, e.g., "creditbalance." (For
some
> types of data, I wonder if it may be more efficient to maintain it
"distributed"
> in subjects' entries rather than in a possibly very large and dynamic
attribute
> list.)
>
> (Perhaps it's obvious, but I'll mention that I'm a bit uncertain about the
> distinction and appropriate practical uses of "principals" versus
"credentials".
My understanding - which may not be accurate! - is that in the context of a
web application the "principal" is the entity on behalf of which a request
is processed, while "credentials" are data used to authenticate that
principal - i.e. to establish its identity. But here I think you are talking
about something different from either - i.e. an attribute of an (already
authenticated) user that is used to decide whether to authorise access to
some resource.
In principle you might be able do what you want using the current code by
setting roleSearchBase to where the users entries are held and setting
roleSearchFilter to e.g. (&(mail={0})(creditBalance > 10000)). This assumes
that you can define a "creditBalance" attribute type with a syntax that
makes the inequality work as you expect. In practice I'm not sure this is
necessarily the best approach in this particular case - perhaps it would be
better to retrieve the credit balance and make the comparison explicitly in
the application. Remember also that the role, once established, persists for
the lifetime of the session.
In general though it is certainly possible to define roles implicitly in
terms of attributes held in the user entries, and the design does support
this.
> Does this model handle "dynamic" groups, by which I mean a reference to a
> method/algorythm/formula computed at runtime, like "member of
ou=myDepartment",
> or "person entries with creditbalance > 10000" ? I understand this can be
> achieved by referring to an attribute that stores a URI that includes an
LDAP
> query string.
I *think* this is pecular to the Netscape/iPlanet directory servers. It
seems that you store an LDAP search query in the form of an LDAP URL as the
value of a "memberURL" attribute in an entry with object class
"groupOfURLs". What's not clear to me is whether the directory server
automatically executes the query when you ask for the value of such an
attribute. (This would be an extension of the LDAP standard). If so, you
could just define roleSearchFilter to be (groupOfURL={1}), thus matching the
user's DN with the list of computed DNs. But if the directory server just
returns the URL for the client to use, the model as it stands would not
handle it.
>
> In any case, this authenticator is a very exciting contribution.
Thanks! - but note that there are other offerings and this particular one
may not make it into the Catalina code.
John
