[
https://issues.apache.org/jira/browse/OAK-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-4101:
------------------------
Attachment: OAK-4101_test.patch
OAK-4101.patch
[~baedke], [~tripod], maybe you want to review the proposed solution. The 2
patches include:
- feature patch + doc update
- separate patch for the test coverage.
Please note: while I originally planned to make external users (and their
synced membership) clearly identifiable and the membership easy to protect with
a dedicated mixin type, this was unfortunately not feasible without changing
the complete API design of the external authentication module. The current
approach therefore uses protection on the Oak level using a Validator and an
ProtectedItemImporter, which IMO should allow to proper secure the sensitive
data). The obvious benefit is full backwards compatibility of the API contract
and the existing implementation (only minor version increase for additional
utility methods in the basic-package)
> Consider separate external (group) principal management
> -------------------------------------------------------
>
> Key: OAK-4101
> URL: https://issues.apache.org/jira/browse/OAK-4101
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: auth-external
> Reporter: angela
> Assignee: angela
> Attachments: OAK-4101.patch, OAK-4101_test.patch
>
>
> Given the fact that user management is delegated to an external IDP provider,
> we might reconsider the current approach that attempts to synchronize user
> and particularly group and their membership into the repository.
> What would left with the repository is a dedicated {{PrincipalProvider}} for
> external groups (and maybe even users at a later stage), making sure that
> - the {{Subject}} is properly populated with {{Principal}} s upon login
> - access control can still be properly setup and managed in the repository
> for the principals defined in the external IDP.
> the consequences would be:
> - external groups (and potentially) users would no longer made available to
> the default user management implementation. alternatively: make them
> available as read-only stub i.e. group-membership as defined by the IDP could
> no longer be changed/manipulated in the reposiotry.
> - they are however exposed as principals to assert proper authentication +
> authorization. Note: any UI that properly reflects the fact that access
> control is being edited for principals (and not for users/groups) would not
> be affected at all; others might need to be adjusted to additionally support
> ac management based on the {{PrincipalManager}}
> will try to come up with a POC as soon as I find some time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
