Uploaded image for project: 'Jackrabbit Oak'
  1. Jackrabbit Oak
  2. OAK-4101

Consider separate external (group) principal management



    • New Feature
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 1.2.19, 1.4.7, 1.5.3, 1.6.0
    • auth-external
    • None


      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.


        1. OAK-4101_test.patch
          106 kB
          Angela Schreiber
        2. OAK-4101.patch
          71 kB
          Angela Schreiber

        Issue Links



              angela Angela Schreiber
              angela Angela Schreiber
              0 Vote for this issue
              1 Start watching this issue