implementation suggestions for this per-user scenario?

[wjcarpenter]

I'm looking for suggestions for the best way to go about using MyVD for this scenario. I've got a bunch of hare-brained ideas for how to go about it, but I'd rather do it the way that seems right for MyVD rather than stumbling about.

The scenario is mostly a typical JDBC case, with the people records in a mostly normalized MySQL database. Experimenting, I can see that MyVD does a good job of constructing inetOrgPerson records from my data. My SELECT includes multiple JOINs, and MyVD correctly finds the multi-valued attributes. (I haven't yet looked at what queries it actually does, so I don't have an opinion about the scalability of it.)

The twist to things is that the bind user is only authorized to view a subset of the data. You could think of the data as a personal address book, where a user can only see the data in their address book entries. In another application using the same data, I just involve the calling user's userid in the query, but I don't see a way to do that with the standard JDBC insert. In fact, I'm not sure I can even figure out who the bind user is when the search() method is called.

So, what are some ways to approach this problem? (I won't immediately poison the well by mentioning some of the ways I've already been thinking about.)

I have a lot of freedom here:

• I control the database schema and the other applications using the database, so I could shuffle things around.
• I'm a Java developer, so messing about with custom inserts is OK. (I will be doing a custom insert to handle authentication in any case.)
• I can also find my way around in the MyVD code without too much trouble.
• If there is some enhancement to MyVD that would be generally useful, I might be able to work up a PR.
• I have a lot of latitude in the LDAP namespaces, attributes, and so on.

Thanks in advance for any thoughts.

[wjcarpenter]

Here is my current thinking on a promising implementation of the above scenario.

Write a custom insert that is a subclass of JdbcInsert. In the subclass's search() method, clone and augment the given Filter with an AND condition to match the owner of the DB records against the bind user. Then invoke the superclass JdbcInsert.search() method with that augmented Filter. This seems to do the job of pushing the authorization check down into the SQL query, which is what I hoped for for performance.

For this to work, I do need to be able to discover the bind user DN. I still don't know how to do that, but am continuing to poke around the MyVD code. Once I have the bind user DN, I can do whatever slicing and dicing I need to get the user identity in the form my DB knows. Then a little attribute mapping in the config file, and things should work.

Comments?

[wjcarpenter]

I found this line in the StaticDNMap insert:

DistinguishedName bindDN = (DistinguishedName) chain.getSession().get("MYVD_BINDDN");

Is that a reliable way to get the bind DN? I mean reliable in the sense that it won't change without notice as an internal implementation detail? If so, I think it would be good to mention it in the docs.

[mlbiam]

1. You may want to consider an the access control insert to limit access
2. If you prefer your method (which may end up being a simpler implementation) then yes you can rely on chain.getSession().get("MYVD_BINDDN")

[wjcarpenter]

To be honest, I couldn't quite figure out how to use the ACL insert in the amount of time I could devote to it. A config example of using that might be worthwhile adding to the doc someday.

I had a secondary concern about performance using ACLs. If it's a filtering applied to the retrieved database results, it might end up filtering out a great many more results than it accepted. Many applications try to provide nifty UI type-ahead stuff. For example, Thunderbird's LDAP lookups do a query after you have typed just 2-3 characters, and the filter it sends looks like "(&(objectclass=inetOrgPerson)(|(cn=ha*)(mail=ha*)(sn=ha*)))". With lots of users and records, there could be a lot of "ha*" hits.

In the end, the augmented filter idea was pretty easy to implement. I realized I didn't need to subclass JdbcInsert because I could just swap in my augmented filter when I called chain.next(). Everything further down the chain would get the augmented filter, and the original would get restored on the way back up the chain.

Thanks for your attention and helpful info.