oracle/weblogic-deploy-tooling

Use PasswordValidator in offline

gregoan opened this issue · 6 comments

gregoan commented

Hello,

We enabled the following PasswordValidator

PasswordValidator:
	SystemPasswordValidator:
		SystemPasswordValidator:
			MinAlphabeticCharacters: 1
			MinLowercaseCharacters: 1
			MinNumericCharacters: 1
			MaxConsecutiveCharacters: 2
			MinNonAlphanumericCharacters: 1
			MinUppercaseCharacters: 1
			RejectEqualOrContainUsername: true
			MinPasswordLength: 10
			RejectEqualOrContainReverseUsername: true

The default PasswordValidator seems to be used when password is created ignoring our rules (password being too weak) :

Issue Log for createDomain version 3.2.6 running WebLogic version 14.1.1.0.0.231012 offline mode:
WARNING Messages:
        1. WLSDPLY-01902: Invalid password for user DeepUsername. Must be at least 8 characters and contain one number.
Total:   SEVERE :    0  WARNING :    1

Will it be possible to use the PasswordValidator part of Model when password is created in offline (during WL domain's creation) ?

Regards.

robertpatrick commented

@gregoan Can you explain your use case? It seems like the person creating the model specifying the user passwords and the PasswordValidator could easily enforce this themselves.

gregoan commented

Hello @robertpatrick ,
In fact, we don't really have the control on password content

  • They are located inside HashiCorpVault instance
  • They are synched using ExternalSecret and represented as K8s secret (not properties)
  • An element in HashiCorpVault could be anything : not only a WL password so pattern/rule cannot be really used.
robertpatrick commented

@gregoan The PasswordValidator is a currently a runtime-only provider that only gets invoked when either new users are created (while the server is running) or if an existing user password is changed (while the server is running). It does not run in WLST offline mode when WDT creates new users in the embedded LDAP Provider (which we do by editing an LDIFT file that creating the WebLogic Domain generates and that the Admin Server loads the first time it boots).

While it is theoretically possible for WDT to try to duplicate the logic inside the WebLogic Server PasswordValidator, it doesn't feel like the right thing to do. This would set WDT up to have to try to track WLS changes and match WLS functionality bug-for-bug.

Is it not possible to set up rules in HashiCorp Vault to validate the WebLogic Server credentials stored there? If not, what about during the creation of the secrets?

gregoan commented

Hello,

I fully understand what you wrote about duplicated code (bug-to-code).

Rule in HCV:
As explained, the HCV is used for many thing so it's a bit complicated to set WL pattern policy for all the/some of elements created in it (a password is not always used inside WL).
I have to check with HCV team what could be done (I don't have access to the HCV configuration) but I don't see this as being a valid solution but to be analyzed.

Creation of secret:
I could try to amend the HelmChart validating the password with regex but if I skip invalid password, WKO shall not find the secret so error will be raised.
---> I don't see how it's possible to inform customer password is invalid (something essential for us).

Could you explain how/why the default password policy is used when the WL instance is created.
---> Is it the "default configuration" of offline ?

robertpatrick commented

@gregoan WLST offline has the default policy enforcement rules hard-coded. That's the only reason domain creation will fail if the admin password is not at lease 8 characters and has at least one non-alphabetical character.

I tested this directly in WLST offline and it definitely pays no attention to the SystemPasswordValidator settings. You could always file an enhancement request with WebLogic Server support.

In the meantime, I am looking at what is possible within WDT. If I am able to do anything, it will only work with the Create Domain tool and will only be able to validate the domainInfo:/AdminPassword password and any users' passwords specified in topology:/Security/User section of the model.