Difference between revisions of "Authentication methods"
(→Authentication Methods) |
(→Database based) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 6: | Line 6: | ||
The difference is in the way, the users password is checked and stored. | The difference is in the way, the users password is checked and stored. | ||
| − | |||
| − | |||
Both methods can be mixed, the database based method is always activated. This allows to manage users based on an LDAP or Active directory as well as application specific users. | Both methods can be mixed, the database based method is always activated. This allows to manage users based on an LDAP or Active directory as well as application specific users. | ||
| + | == Database based == | ||
| + | |||
| + | The username, email and password are stored in the userAccount entity. The password is encrypted in the "shiro" way. | ||
| + | |||
| + | The user can be assigned to a userGroup, which makes it easier to manage common settings for several users. | ||
| + | |||
| + | The existence of an activated, non locked entry with the username in the userAccount entity and the match of the entered and the stored password leads to a successful login to the application. | ||
| + | == LDAP based == | ||
| − | '''LDAP''' | + | The '''LDAP''' settings need to be configured in the preferences file or via the perferences dialog: |
<code>shiro/org.eclipse.osbp.authentication.shiro.extensions.LDAPRealm/contextFactoryUrl=ldap\://ldap.company.com\:389 | <code>shiro/org.eclipse.osbp.authentication.shiro.extensions.LDAPRealm/contextFactoryUrl=ldap\://ldap.company.com\:389 | ||
| Line 19: | Line 25: | ||
shiro/org.eclipse.osbp.authentication.shiro.extensions.LDAPRealm/userDnTemplate=CN\={0},CN\=Users,DC\=company,DC\=com</code> | shiro/org.eclipse.osbp.authentication.shiro.extensions.LDAPRealm/userDnTemplate=CN\={0},CN\=Users,DC\=company,DC\=com</code> | ||
| + | The binding is done against the distinguishedName attribute of the LDAP. The <code>userDnTemplate</code> is used to build the distinguished name, <code>{0}</code> is replaced with the username entered in the login dialog. A successful binding with the distinguishedName and the password and the existence of an activated, non locked entry with the username in the userAccount entity leads to a successful login to the application. | ||
| + | To facilitate the user management, the user record for a LDAP based user is created automatically when the user tries to login the first time with the correct password. | ||
| + | The Admin needs to enable the user after he assigned either a role or a user group (with an assigned role) to the user. This has to be done through the user adminstration perspective in the application. | ||
| − | + | The cn and mail LDAP attributes are used for the username and email entries in the userAccount. The password is '''not''' stored in the database. | |
Another way might be to add a bpm process which automates the user enablement based on some criteria, eg. the users email domain leads to a template user for the domain and then, the user will have the settings from the template user. | Another way might be to add a bpm process which automates the user enablement based on some criteria, eg. the users email domain leads to a template user for the domain and then, the user will have the settings from the template user. | ||
Latest revision as of 09:22, 24 September 2019
Authentication Methods
OS.bee offers 2 ways to manage user authentication: database based and LDAP based authentication.
Both methods use the userAccount and userGroup entities to control the users, manage access rights and store user settings.
The difference is in the way, the users password is checked and stored.
Both methods can be mixed, the database based method is always activated. This allows to manage users based on an LDAP or Active directory as well as application specific users.
Database based
The username, email and password are stored in the userAccount entity. The password is encrypted in the "shiro" way.
The user can be assigned to a userGroup, which makes it easier to manage common settings for several users.
The existence of an activated, non locked entry with the username in the userAccount entity and the match of the entered and the stored password leads to a successful login to the application.
LDAP based
The LDAP settings need to be configured in the preferences file or via the perferences dialog:
shiro/org.eclipse.osbp.authentication.shiro.extensions.LDAPRealm/contextFactoryUrl=ldap\://ldap.company.com\:389
shiro/org.eclipse.osbp.authentication.shiro.extensions.LDAPRealm/userDnTemplate=CN\={0},CN\=Users,DC\=company,DC\=com
The binding is done against the distinguishedName attribute of the LDAP. The userDnTemplate is used to build the distinguished name, {0} is replaced with the username entered in the login dialog. A successful binding with the distinguishedName and the password and the existence of an activated, non locked entry with the username in the userAccount entity leads to a successful login to the application.
To facilitate the user management, the user record for a LDAP based user is created automatically when the user tries to login the first time with the correct password. The Admin needs to enable the user after he assigned either a role or a user group (with an assigned role) to the user. This has to be done through the user adminstration perspective in the application.
The cn and mail LDAP attributes are used for the username and email entries in the userAccount. The password is not stored in the database.
Another way might be to add a bpm process which automates the user enablement based on some criteria, eg. the users email domain leads to a template user for the domain and then, the user will have the settings from the template user.
