Hi David, Your case is intrigueing to the least.. :-)
Mind that the OP already admitted using a Java layer on top of MarkLogic Server. There are plenty libraries to connect to back-end systems in Java, so it saves effort to reuse those. But, things are different if you prefer putting MarkLogic Server in the middle.. > Example: > For one application you have viewers, authors, reviewers, > approvers, etc. They are over different sets of data and the > requirement specifies that they can only see or search for > what they are authorized to see as the data moves through the > content pipeline. Some need view/approve, some can > view/review, some can do it all, etc. Agree. Not much different from any other application I guess. Note that you can restrict search results by automatically adding additional search queries (for instance directory- or collection-query's) as well.. > This makes it necessary > for many combinations of these roles to be created in the > MarkLogic server. We have many apps with different fine > grained roles that can be assigned. This makes for a > "combinatorial" growth of users mapped to roles that has to > be maintained in ML. You have actually two options here: create one user for each functional role, or create a user object for each real user. The latter requires keeping them up to date. I wouldn't recommend creating a logical user for each role combination. There is no obvious benefit from doing that. Such users don't have a meaning of there own, and it would make things more complex than necessary. > If bob has 7 roles and an 8th is needed. A different user of > some kind would need to exist or be created to grant that > kind of access. When they login, all the roles from all the > apps must be combined into one user granting only what they have. Yes, if you always want a user object to have all its allowed roles, you need to either constantly update/synch the existing user, or create it on the fly on each session. But looking at individual tasks (individual query transactions), does the user object really need all those roles? I would say an individual task either belongs to a group of viewing tasks, or approval tasks, etc, so I could imagine that one role per transaction might suffice.. > Rather than somehow generate and manage users with all > possible combinations of roles, we just create a user with > that user's same username from LDAP, grant the roles on the > fly, and log them in (on a redirected call if needed) using > application-level authorization. Then on session timeout or > inactivity for a prescribed time, we remove the sessions, > profile, and user in a scheduled task, (fairly straight > forward, but with a few caveats). Nice. Instead of doing full CRUD on the MarkLogic Server Security database, you limit to C and D, and are doing just-in-time-creation (so to speak) to make sure you use the latest defintions from LDAP.. And as far as I understand you have a limited set of permissions and roles that are involves, so those are predefined I presume, only creating users on the fly? > This method also allows the app to look at who is logged in > for finer grained tracking, etc. Compared to the role based approach, yes. But it is not difficult to add additional log statements that log the real user name if you pass that as a parameter. > Some, including myself, wonder at times about the necessity > for such fine-grained access rights, but these are our requirements. Yes. The main bottle-neck is that your approach requires updating of the Security database before you can actually start the user activities, which requires a second transaction and security privileges. Right? You do benefit from the permissions on documents, which hide documents from searching and disallow certain activities if privileges are missing. But I could imagine that at least part of that can be mimiced with less advanced code, using additional search queries as mentioned earlier.. I am still charmed about the idea, though.. > There are really only two general options: > 1) Carefully organize roles and combinations of roles and map > to pre-created users for those combinations, limiting the > combinations to some fixed, organized set. This is what > MarkLogic supports without any extra work, or > 2) Go completely dynamic as described above. > > We chose 2. If you put it like this, there is a middle-way: only precreate roles and privileges, and only dynamically create (or update) users. But I have the impression that is what you are doing already. Dynamic creation of users still requires security privileges though. ;-) So yes, you could say that the Security layer of MarkLogic Server is designed for precreated users, roles, privileges etc. > I hope this was clear enough. Yes, thanks! I think I see another possible approach: I believe it should be possible to map each individual database request to some predefinable role, use xdmp:login to login as a predefined user with that role, and perform the task like that. It still uses most of the Security layer, but it allows replacing user-role relation by some custom logic, without the need to update the Security database. On the other hand, I guess this approach has pro's and con's just as well. It always comes down to finding the best trade-off between available options.. Kind regards, Geert Drs. G.P.H. Josten Consultant http://www.daidalos.nl/ Daidalos BV Source of Innovation Hoekeindsehof 1-4 2665 JZ Bleiswijk Tel.: +31 (0) 10 850 1200 Fax: +31 (0) 10 850 1199 http://www.daidalos.nl/ KvK 27164984 De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend. _______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
