Password Clauses for the Add Person Command

The use of passwords is similar to the way that passwords work on most systems. Passwords are an effective means of preventing unauthorized access to business objects. Without passwords, any user could set their context to that of any other user. This would essentially make policies and states meaningless since you could easily bypass access restrictions by pretending to be someone else. Therefore, a password should be required to ensure that the person who is logging in is indeed that person. In particular you should thoroughly consider the option of passwords for Business and Systems Administrators.

This page discusses:

Syntax

These clauses use passwords to restrict access to a person’s context:

  • Password clause assigns a password to the person you are defining (as described below).
  • Disable Password clause restricts access to the user whose system ID or login matches the person ID (for more information, see Disable Password Clause).
  • No Password clause specifies that no password is required to set context (for more information, see No Password Clause).

Only one password-related clause (Password, Disable Password, or No Password) should be given.

add person dave
   no password
   access checkin, create, delete, read, modify, checkout, connect;

Each user can redefine his/her own password using the Preferences (password) option in the web app.

Password Clause

The Password clause assigns a password to the person you are defining. The password will be required whenever someone wants to access this person’s business objects. When a password is assigned, anyone who knows the password can set their context to this person.

For example, the following command defines a person with a password value:

add person chris
   password SaturnV;

If you wanted to set your context to Chris, you would need to know the password SaturnV.

The defined password is not visible to anyone. As a Business Administrator, you can change a password without seeing or knowing it. For more information, see About Administrative Object Names.

By default, passwords are limited to 8 significant characters, in which case a password of 12345678xxxx is the same as password 12345678. The number of significant characters can, however, be controlled using the Cipher Clause of the set password command.

Disable Password Clause

The disable password clause lets you use the security for logging into the operating system as the security for setting context. When a user whose password is disabled attempts to set context, the system compares the user name used to log into the operating system with the list of persons defined. If there is a match, the user can set context without a password. (The context dialog puts the system user name in as default, so the user can just hit enter.) If they do not match, the system denies access.

When disable password is chosen for an existing person, this clause modifies the password so that others cannot access the account. This means that the user with the disabled password can only log into the 3DEXPERIENCE Platform from a system where the O/S ID matches the 3DEXPERIENCE Platform ID. This is similar to the way automatic SSO-based user creation is handled. To re-enable a password for such a person, create a new password for the person as you normally would.

No Password Clause

The no password clause specifies that no password is required to access the person’s business objects. When No Password is specified, other users can set their context to that of the person you are defining. Once the context is set to the person, the user can act as that person with all applicable access privileges.

The no password clause generally is not recommended since removing the password requirement permits other users to set context as that user. However, if a person leaves the company, for example, or if you are setting up a guest account, you might want to remove the password requirement.

Passwordexpired Clause

When the passwordexpired clause is included in a person’s definition, the system requires the person to define a new password the next time that person attempts to log in. The system will not allow the person to log in without entering a new password. After the user defines a new password, the clause is removed from the person definition.

For example, you could use the following command to ensure that Jordan defines a new password on next login:

add person jordan passwordexpired;

This option allows you to require users to establish a password without requiring you to assign them one now. Having users establish their own passwords helps them remember their password. It also prevents you from having to enter an initial password for every new user, which you would then have to communicate to users. You can also use this clause if you suspect that a person’s password has been compromised.

Neverexpire Clause

You can allow a user to be exempt from password expiration with the neverexpire clause. This can be used when the system is setup to use expiring passwords, but the implementation has the need for “secret agents” or automatons that generally perform work programmatically. To remove the necessity for updating these kinds of programs for expiring passwords, the user agent’s password can be set to neverexpire as follows:

add person “User Agent” neverexpire;

This command unsets the passwordexpired option on the person if it was set. If a business administrator attempts to set the passwordexpired option on a person that is set to neverexpire, an error will occur.