All WSO2 servers support managing users in various types of userstores such as LDAP, Microsoft Active Directory and Databases. When creating user accounts, it is important to enforce a password pattern policy to protect user data and privacy. In this post I am demonstrating how the password patterns are enforced and validated in WSO2 servers. These steps and concepts are common to any WSO2 product.
The activity diagram for password pattern validation is shown below for which is executed at the time of user creation. If the user is created through the Management Console, the front end validation is done first, and if the validation is successful, the back end validation is done afterwards. If the user is created through a service call without using the Management Console (eg. by calling RemoteUserStoreManagerService’s addUser method), the front end validation on the password pattern is skipped where only the back end validation happens.
In WSO2 servers, users are created in userstores. Therefore the password pattern policy is configured per userstore. Any WSO2 server would have one PRIMARY userstore which can be an LDAP, Microsoft Active Directory, Database or any custom developed userstore. The PRIMARY userstore configuration is defined in WSO2_SERVER_HOME/repository/conf/user-mgt.xml file. There, under the configuration of the userstore, following properties are available.
Property Name
|
Usage
|
PasswordJavaRegEx
|
Back end validation
|
PasswordJavaScriptRegEx
|
Front end validation
|
A sample is shown in the image below which shows default configuration. (Some WSO2 products have an Apche DS LDAP embedded as the default PRIMARY userstore, while other WSO2 products would have a JDBC userstore which is a database. However the property names are same for any userstore).
If the userstore is a secondary userstore, the configuration can be set in the UI of the management console as shown below, or else by directly editing the configuration file in WSO2_SERVER_HOME/repository/deployment/server/userstores/ directory that is associated with the particular userstore (more information on [1]).
Therefore different userstores can have their own password pattern policy.
For testing the password pattern policy enforcement, I’ll be using the PRIMARY userstore for adding users and therefore I will be modifying the user-mgt.xml file with particular regular expressions. This needs server restart at every modification. However if you are setting this up in a secondary userstore, you need to either modify the configuration from Management Console UI, or manually modify the particular xml file in repository/deployment/userstores/ directory. The configuration gets applied on the fly and you don’t need a server startup to apply the changes).
Testing Front End Validation of Password Pattern from Management Console
Here I would use following configuration which is a basic regex that allows any character to be present in the password. The minimum characters in the password should be 7 characters for front end validation. In back end validation I have set it to 5. If the front end validation fails, it will display an error message. This message is defined in the PasswordJavaRegExViolationErrorMsg property.
<Property name="PasswordJavaScriptRegEx">^[\S]{7,30}$</Property>
<Property name="PasswordJavaRegExViolationErrorMsg">Password length should be within 7 to 30 characters</Property>
<Property name="PasswordJavaRegEx">^[\S]{5,30}$</Property>
Now if I create a user providing a password that does not comply with the front end policy (password is less than 7 characters long). I will make the password 6 characters long so that it complies with the backend pattern policy, but not front end policy. When I try to create the user, I get the error message.
So at the first step of validation (front end validation) it fails and back end validation is not happening anyway as the flow exits.
However if I create the user through a service call without using Mangement Console UI, since the frontend validation is not happening, I can create the user only if the password matches the backend policy.
Testing Back End Validation of Password Pattern from Management Console
Now I set the minimum length of the password to be 7 characters long in back end validation, but for front end validation I’m setting it to 5 characters.
<Property name="PasswordJavaRegEx">^[\S]{7,30}$</Property>
<Property name="PasswordJavaScriptRegEx">^[\S]{5,30}$</Property>
Here, if I enter a password with 6 characters long, front end validation passes, but backend validation fails.
Testing Back End Validation of Password Pattern from User API
Here I set the minimum length of the password of the backend policy to 7 characters, but the front end policy to 5 characters long.
<Property name="PasswordJavaRegEx">^[\S]{7,30}$</Property>
<Property name="PasswordJavaScriptRegEx">^[\S]{5,30}$</Property>
Then I call the RemoteUserStoreManagerService API’s addUser method and provide a password with 6 characters. Here since this is a service call and Management Console UI is not associated, front end validation is skipped. But when the backend validation happens, since the password character length is less than 7 characters, the back end policy is violated.
Identity Management Feature Password Pattern Policy
Apart from above, if the WSO2 product you use supports the IdentityMgt feature, it has another backend password policy pattern matching extension. Using this extension, you can even write your own password policy patterns (eg: avoid using dictionary words in passwords) and engage them. For this user, the password pattern is defined in identity-mgt.properties file.
Password.policy.extensions.3.pattern=^((?=.*\\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[!@#$%&*])).{0,100}$
However this feature has some broader scope which I will discuss separately in a future post. (You can find this post in [2])
References
[2] http://tharindue.blogspot.com/2016/08/user-password-pattern-policy-extensions.html
Tharindu Edirisinghe
Platform Security Team
WSO2
No comments:
Post a Comment