7.13 LimaxKey

LimaxKey is called Lmk for short, and supports certificate-based client login. The client login process uses a private key certificate package that is signed by convention. The signer information is included in the certificate content, and the user source can be traced very easily. In fact, Lmk provides a decentralized third-party login mechanism.


  • 7.13.3 Sign LmkBundle

    • Run Lmk Signing Service


      java -jar limax.jar pkix lmk [path to lmkserver.xml]
      

      Refer to lmcserver.xml for configuration instructions


      LmkServer top-level element

      Seven attributes:

      certificateAlgorithm: the public key algorithm used by LmkServer to automatically sign the HTTPS server certificate.

      certificateLifetime: the lifetime in days that LmkServer automatically signs HTTPS server certificate.

      constraintNameLength: the length limit of the user name.

      domain: the HTTPS server domain name of the LmkServer.

      port: HTTPS server running port, the default is 443.

      Please refer to the "Key distribution system" server operation section for revocationCheckerOptions and trustsPath.


      LmkBundle element:

      Two attributes:

      certificateLifetime: the lifetime in days of the signed LmkBundle.

      rsaBits: RSA private key length of LmkBundle.


      The configuration of other elements is the same as that of the caserver.xml, please refer to "PKIX Support".

      The location of CAService can point to LmkCA, and can also point to a generic CA. The specific difference is reflected in requesting LmkBundle.


    • Request LmkBundle

      Use the HTTP/GET method to request the HTTPS service that requires client authentication. Use JSON to organize the query parameters. After the JSON encoding, URL encoding is required.

      The JSON request style is: { "u":"username", "p":"passphrase" }

      Among them:

      u is the user name. It must be a non-empty string. The length is less than or equal to the constraintNameLength of the Lmk signature service configuration, and the user name is converted to a lowercase to sign LmkBundle.

      p is the encrypted password of LmkBundle.

      The Limax framework provides a java implementation:


      limax.pkix. LmkRequest.createReqeustor(SSLContextAllocator sslContextAllocator, String host);
      

      After initializing a requestor, calling requestor.fetch("user"); can request LmkBundle for subsequent users.


    • Renew LmkBundle

      Switcher and Auany are usually used to help the client renew the LmkBundle.

      The Limax framework provides a java implementation to renew LmkBundle from LmkServer directly :


      limax.pkix.LmkBundleUtils.renew(Path path, char[] passphrase);
      

      The LmkBundle renew implementation flow is a little different from the request LmkBundle, where:

      The JSON request style is: {"p":"passphrase"}, and only the password is required.

      Use the LmkBundle's own certificate to perform HTTPS client authentication. If the certificate is not valid for more than half, the update fails.


    • Matters need attention

      1. Switcher and Auany will also visit LmkSignServer to renew certificate. The service port must be open to Switcher and Auany.

      2. LmkServer must run NTP service to guarantee the clock synchronization, and avoid signing invalid LmkBundle.


  • 7.13.4 Limax service operation

    • Configuration

      Switcher is exempt from configuration. All configuration information is pushed by Auany. Add an lmk element to the Auany configuration.

      Five attributes:

      location: the location of the certificate that the CA signs for the current limax operation environment.

      passphrase: the enable password of the private key of the location. In actual operating, this attribute should not be filled in, but should be entered when the server starts.

      Please refer to the "Key distribution system" server operation section for revocationCheckerOptions and trustsPath.

      validateDate: configures whether the current operation environment needs to detect the expiration state of the LmkBundle.


    • Virtual machine parameters

      limax.auany.LmkManager.defaultLifetime, if the LmkBundle expiration state detection is turned off in the current operation environment, the credentials created through LmkBundle use this parameter to determine the expiration time. The default value is 8640000000, that is, 100 days. As long as the LmkBundle is used to create the credential, the expiration time must be set regardless of whether the current environment detects expiration. The closed expiration state may also be reopened.

      limax.auany.LmkManager.renewConcurrency, this parameter determines the number of threads used by the individual Auany and Switcher servers to initiate LmkBundle renew requests. The default is 16.


    • Matters need attention

      1. If the current operation environment is configured to not detect LmkBundle expiration state, it will not help the client to perform certificate renew. This problem must be noticed when the same LmkBundle is used in multiple Limax operation environments.

      2. In an environment where expiration detection is enabled, Switcher and Auany must run NTP services to ensure clock synchronization.


Prev Next