Uploaded image for project: 'OpenDJ'
  1. OpenDJ
  2. OPENDJ-6053

Create service account during setup

    Details

    • Type: New Feature
    • Status: Done
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 7.0.0
    • Fix Version/s: None
    • Labels:
      None
    • Story Points:
      0

      Description

      All DJ peer-to-peer communication should be secured using mutual TLS (mTLS) and system accounts where possible.
      This includes:

      • replication protocol: DS-RS and RS-RS
      • proxy: for discovery and proxying requests
      • crypto-manager: using "get symmetric key" request for distributing symmetric keys.

      The goal is to prevent using a login/password to authenticate during machine to machine communications.

      This story needs OPENDJ-5866 to be resolved since it relies on the new deployment model (deployment key and CA cert).
      It also depends on OPENDJ-4702 in order to be able to configure the proxy to use SASL External authentication in configuration.

      Acceptance criteria

      This issue could be closed once:

      • The setup tool will create a "service account" in a single entry backend containing attributes similar to the one below:
        dn: cn=service
        objectClass: top
        objectClass: applicationProcess
        objectClass: ds-certificate-user
        cn: service
        ds-certificate-subject-dn: <SSL certificate subject DN>
        ds-certificate-issuer-dn: <CA subject DN>
        ds-privilege-name: config-read
        ds-privilege-name: proxied-auth
        ds-privilege-name: monitor-read 
        
      • ds-proxy-profile will configure the replication discovery mechanism to use SASL External in order to bind to the backend servers with the cn=service account

      Below are former acceptance criteria from OPENDJ-5866 description from which this story has been moved:

      Note: we should have stronger validation of the CA cert, see OPENDJ-4712 and OPENDJ-4716.
      To be confirmed: should the account entry a) be mutable, nor b) replicated? Only if we want to maintain password policy state and support lockout, but I'm not sure we do.

      The SASL mechanism default configuration should refer to an additional "Subject DN to User Attribute" which maps to system accounts in private backends

      Regarding b), as discussed with Matt, the service account should not have to be replicated, at least in a first time.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                matthew Matthew Swift
                Reporter:
                gaetan Gaetan Boismal [X] (Inactive)
                Dev Assignee:
                Matthew Swift
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: