[
https://issues.apache.org/jira/browse/CONNECTORS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13443106#comment-13443106
]
Maciej Lizewski commented on CONNECTORS-515:
--------------------------------------------
I was thinking about scenario like this:
LDAPAuthority resolves usernames and returns groups the user belongs to,
documents from repositories can have group names assigned during job execution
(there are authorization tokens already in most connectors).
I could: scan repository A and assign "groupA" as allowed to access them,
scan repository B and assign "groupB" as allowed to access them,
then user X belongs to groupA and groupB and can access all all documents, etc.
I think sticking to only SIDs and ActiveDirectory makes it less elastic and
adoptable. I think that any central authentication/authorization system (and
LDAP is one of such systems) provides some 'roles'/'groups'/etc. and maintains
connections between users and those 'roles'. Then connectors (in Manifold
meaning) should just somehow assign those roles to documents. So far - I think
Manifold follows this scenario. But it should not force repositories to provide
such information, but allow to provide them in job/connection configuration.
There some cases when you can determine roles for each document like in
Activedirectory/Windows shares case, but there are many more simpler cases when
there is only one (or few, but costant) authorization entry per repository.
Examples: samba shares, local directory (when pushed to global search index
should have authorization tokens as well). There are also cases when there are
only few possibilities, like "files matching XXX are for group X, files
matching YYY are for group Y" and those cases could be handled by providing
different jobs with different authentication tokens and different
inclusion/exclusion filters for same repository. In most cases I am aware of
(from our clients) there is no repositories that provide such fine-grained
authorization information per-document like windows shares with activedirectory.
Our vision and what we are trying to achieve is to have product with which we
could go to some company and say: hey - you have plenty of documents. there is
total mess with them, no central authentication, some primitive roles on every
files share, but thats ok. We can live with that. We will install our product,
configure X connectors, configure your users and groups in some database and
voila! there is your enterprise search". Deployed in your environment without
need to change it, every user can find only what is he allowed to. :)
following this thought - we will also need authorization connector that will
work with users/groups from database, but that can be simple and work on
constant database structure.
I hope it makes more clear my request. If not - do not hesitate to ask and
drill...
> Support also for openldap, not only activedirectory
> ---------------------------------------------------
>
> Key: CONNECTORS-515
> URL: https://issues.apache.org/jira/browse/CONNECTORS-515
> Project: ManifoldCF
> Issue Type: New Feature
> Components: Active Directory authority
> Reporter: Maciej Lizewski
> Priority: Minor
>
> Current authority supports only ActiveDirectory. Would be nice to have also
> support for plain openLDAP and three kinds of groups:
> - memberOf attribute in user (InetOrgPerson) entry
> - posixGroup entry with memberUid attribute
> - groupOfNames entry with member attribute
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
