[
https://issues.apache.org/jira/browse/CONNECTORS-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689156#comment-13689156
]
Karl Wright commented on CONNECTORS-703:
----------------------------------------
It is possible to add significant new functionality without harming backwards
compatibility, as follows:
(0) UserRecord is pretty general; I'm thinking a nested
<domain_key>:(<userrecord>|<string>) hash
(1) We extend IAuthorityConnector.java to include new method that takes a user
record, getUserAccessTokens(UserRecord)
(2) BaseAuthorityConnector has an implementation of
getUserAccessTokens(UserRecord), which extracts the "activedirectory" result
and passes that to getUserAccessTokens(String)
(3) The authorityservice servlet has two entry points: UserACLs, and
RecordACLs. The RecordACLs is new, and has username and domain_key arguments,
maybe even multiple of these.
(4) The biggest change: Solr and ElasticSearch plugins need to be updated to
work with the RecordACLs side of the API rather than the UserACLs.
(5) Initially, ManifoldCF will include only one user mapper: a regexp-based one.
(6) Order of operation: Each mapper should be able to specify its
prerequisites, e.g. "I run after XXX". Then we can get maximum parallelism.
This assumes that everyone writing an authority connector used best practices
and extended the BaseAuthorityConnector - but I think that is likely. It also
means that existing authorities need to be ported so that their primary method
is the UserRecord one, not the String one. I'm still trying to work out what
the convention should be for finding the appropriate information for a given
authority in the user record.
> add username mappers functionality
> ----------------------------------
>
> Key: CONNECTORS-703
> URL: https://issues.apache.org/jira/browse/CONNECTORS-703
> Project: ManifoldCF
> Issue Type: Improvement
> Components: Authority Service
> Affects Versions: ManifoldCF 1.3
> Reporter: Maciej Lizewski
> Assignee: Karl Wright
> Priority: Minor
> Fix For: ManifoldCF next
>
>
> If we deal with many auth sources there will be for sure need to map provided
> username to user id specific for particular auth source. As I remember - in
> book there is a note that this is the auth connector responsibility, but it
> means that in different scenarios we need different connectors (for example:
> in one scenario provided username is e-mail, in other - just login. You
> cannot use same auth connector in both cases).
> we should be able to configure "username mapper" for auth connector which may
> be simple regexp mapper or custom class providing mapping interface with more
> complex logic.
--
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
