Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

Introduction

MidPoint associates password policies with an attribute that it applies to. E.g. a password policy is associated with the user password property, different password policy may be associated with a Addressbook resource password attribute, etc. This approach helps midPoint to validate and generate the value. Password policies are specified in a form of value policy. Value policy is a more generic term because such policies may also be applied to other values not just the passwords.

Value policies in midPoint are almost entirely declarative and there is a good reason for it. MidPoint not only needs to validate the passwords but it often needs to generate them as well. It is very easy to construct a password policy language that is used to validate the passwords. This might even contain pieces of scripting code. But that will not work for generating the value. The password generator needs to know precisely what characters are allowed in the password, how much of them is allowed and how much is required and how they are positioned (e.g. first character must be a letter). Only then can the password generator efficiently choose and shuffle the characters to generate the password.

Password Policies

There are two types of password policy:

  • Global password policy used for user's password. This is referenced from the system configuration object.
  • Account type password policy used for resource's account. This is referenced from the resource definition.

Value Policy

Value policy definition is an object in midPoint repository that describes rules for generating and validating passwords. The simple value policy example can be expressed in the XML as:

<valuePolicy oid="00000000-0000-0000-0000-000000000003" version="0" xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-2a"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<name>Global Password Policy</name>
	<description>Global password policy</description>
	<lifetime>
		<expiration>999</expiration>
		<warnBeforeExpiration>9</warnBeforeExpiration>
		<lockAfterExpiration>0</lockAfterExpiration>
		<minPasswordAge>0</minPasswordAge>
		<passwordHistoryLength>0</passwordHistoryLength>
	</lifetime>
	<stringPolicy>
		<description>Testing string policy</description>
		<limitations>
			<minLength>5</minLength>
			<maxLength>8</maxLength>
			<minUniqueChars>3</minUniqueChars>
			<limit>
				<description>Alphas</description>
				<minOccurs>1</minOccurs>
				<maxOccurs>5</maxOccurs>
				<mustBeFirst>false</mustBeFirst>
				<characterClass>
					<value>abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ</value>
				</characterClass>
			</limit>
			<limit>
				<description>Numbers</description>
				<minOccurs>1</minOccurs>
				<maxOccurs>5</maxOccurs>
				<mustBeFirst>false</mustBeFirst>
				<characterClass>
					<value>1234567890</value>
				</characterClass>
			</limit>
		</limitations>
	</stringPolicy>
</valuePolicy>

The <lifetime> section describes policies for password expiration. Sections <stringPolicy> and <limitations> describe policies that the password must satisfy. The minimal, maximal length of the password and the minimal number of unique characters used in the password can be specified. The following example shows a very simple policy which is only limiting the password length and character uniqueness and not the characters that may be used (as the matter of fact, any character may be used):

<stringPolicy>
    <description>Testing string policy</description>
    <limitations>
        <minLength>5</minLength>
        <maxLength>8</maxLength>
        <minUniqueChars>3</minUniqueChars>
    </limitations>
</stringPolicy>

With the above definition, the password p123 would be rejected because it's too short; the password longpassword would be rejected because it's too long and the password bubub would be rejected because of the inssuficient unique characters. If the above mentioned password policy is used for generating password, the password will contain alphanumeric characters only. It's a default character class when no other is specified.

To define further restrictions, you can define character set(s) by <limit> sections. Only characters explicitly defined may be used in the password and may be further restricted. All other characters are considered to be illegal or invalid. The only exception is the very simple policy above: if there are no <limit> sections, all characters are allowed.

The following policy restricts the password to contain only digits (1234567890) with at least 1 and at most 5 digits it can be specified as in the following example:

<stringPolicy>
    <description>Testing string policy</description>
    <limitations>
        <minLength>5</minLength>
        <maxLength>8</maxLength>
        <minUniqueChars>3</minUniqueChars>    
	    <limit>
			<description>Numbers</description>
			<minOccurs>1</minOccurs>
			<maxOccurs>5</maxOccurs>
			<mustBeFirst>false</mustBeFirst>
			<characterClass>
				<value>1234567890</value>
			</characterClass>
    	</limit>
	</limitations>
</stringPolicy>

With the above definition, the password 1234 would be rejected because it's too short; the password 1234567890 would be rejected because it's too long, the password 101010 would be rejected because of the inssuficient unique characters and the password anne108 would be rejected because it contains other-than-defined characters (non-digits).

To make the password policy even more complex, you can split the character set to uppercase letters, lowercase letters, digits and special characters as in the following example:

<stringPolicy>
    <description>Testing string policy</description>
    <limitations>
        <minLength>5</minLength>
        <maxLength>8</maxLength>
        <minUniqueChars>3</minUniqueChars>    
    <limit>
        <description>Lowercase characters</description>
        <minOccurs>1</minOccurs>
        <mustBeFirst>true</mustBeFirst>
        <characterClass>
            <value>abcdefghijklmnopqrstuvwxyz</value>
        </characterClass>
    </limit>
    <limit>
        <description>Uppercase characters</description>
        <minOccurs>1</minOccurs>
        <mustBeFirst>false</mustBeFirst>
        <characterClass>
            <value>ABCDEFGHIJKLMNOPQRSTUVWXYZ</value>
        </characterClass>
    </limit>
    <limit>
        <description>Numeric characters</description>
        <minOccurs>1</minOccurs>
        <mustBeFirst>false</mustBeFirst>
        <characterClass>
            <value>1234567890</value>
        </characterClass>
    </limit>
    <limit>
        <description>Special characters</description>
        <minOccurs>1</minOccurs>
        <mustBeFirst>false</mustBeFirst>
        <characterClass>
            <value> !"#$%&amp;'()*+,-.:;&lt;&gt;?@[]^_`{|}~</value>
        </characterClass>
    </limit>
	</limitations>
</stringPolicy>

With the above definition, the password pAs1! would be rejected, because it's too short, the password pAssw0rd! would be rejected, because it's too long, the password passw0rd! would be rejected, because it does not contain at least one uppercase letter, the password PASSW0RD! would be rejected, because it does not contain at least one lowercase letter and does not start with the lowercase letter, the password Passw0rd! would be rejected, because it does not start with the lowercase letter, the password passWord! would be rejected, because it does not contain any digit, and the password passW0rd would be rejected because it does not contain at least one special character.

On the other way, with the above definition, the password p#s5worD would be accepted.

To disallow the usage of certain characters, you can either remove them from the <characterClass> definition, remove the <limit> section or you can set both the <minOccurs> and <maxOccurs> attribute values to 0.

Global password policy is specified in the "System configuration" object as in the following example:

<systemConfiguration oid="00000000-0000-0000-0000-000000000001" version="0"
                     xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-2a" >
    <name>SystemConfiguration</name>
    
    <!-- other system configuration properties -->

    <globalPasswordPolicyRef oid="00000000-0000-0000-0000-000000000003" type="c:PasswordPolicyType"/>
    
    <!-- other system configuration properties -->
</systemConfiguration>

The account type password policy is specified in the resource in the section schemaHandling as in the following example:

<c:resource oid="ef2bc95b-76e0-48e2-86d6-3d4f02d3fafe">

        <!-- Resource name. It will be displayed in GUI.  -->
        <c:name>Localhost CSVfile</c:name>

	<!-- connector configuration -->

        <!-- schema definition -->
        <schemaHandling>

            <!-- schema handling for different attributes -->
            <credentials>
                 <password>
                     
		     <!-- outbound/inbound for password -->

		     <passwordPolicyRef oid="81818181-76e0-59e2-8888-3d4f02d3ffff" type="c:PasswordPolicyType"/>
                  
		  </password>
            </credentials>

		...

            </accountType>
        </schemaHandling>
    </c:resource>

Different account types in resource can have different password policies. If there is no password policy for the account type, the global password policy is used to validate the account password.

Check Expression

Since midPoint 3.6

Additional check expression can be specified in the string policy limitations. The value will be accepted only if the expression returns true. Additional failure message may also be specified.

There are two variables available to the expression:

variable namecontent
inputPassword to be validated. Or generated password candidate in password generation scenarios.
objectUser in case that the user password is changed/generated. Shadow in case account password is changed/generated.

If the expression returns true then the password is accepted. If the expression returns false (or anything else) then the password is refused.

The following example is checking password for the presence of several user properties:

    <stringPolicy>
        <limitations>
            ...
            <checkExpression>
                 <script>
                     <code>
                         if (object instanceof com.evolveum.midpoint.xml.ns._public.common.common_3.UserType) {
                             return !basic.containsIgnoreCase(input, object.getName()) &amp;&amp; !basic.containsIgnoreCase(input, object.getFamilyName()) &amp;&amp; !basic.containsIgnoreCase(input, object.getGivenName()) &amp;&amp; !basic.containsIgnoreCase(input, object.getAdditionalName())
                         } else {
                             return true
                         }
                     </code>
                 </script>
            </checkExpression>
            <checkExpressionMessage>must not contain username, family name and given name and additional names</checkExpressionMessage>
            ...
        </limitations>
    </stringPolicy>
  • No labels