Difference between revisions of "Authentication methods"

From OS.bee documentation
Jump to: navigation, search
(Created page with "=Authentication Methods= OS.bee offers 2 ways to manage user authentication: database based and LDAP based authentication. Both methods use the user_account table to contro...")
 
(Database based)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
=Authentication Methods=
 
=Authentication Methods=
  
OS.bee offers 2 ways to manage user authentication:  database based and LDAP based authentication.
+
OS.bee offers 2 ways to manage user authentication:  '''database based''' and '''LDAP based''' authentication.
  
Both methods use the user_account table to control the users, manage access rights and store user settings.
+
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).
+
The difference is in the way, the users password is checked and stored.
  
For the database based method, the password is stored in the user_account in the "shiro" encrypted way. For the LDAP based method, no password is stored in the database. The user is authenticated against the LDAP server, which needs to be accessable during runtime of course.
+
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.
+
== Database based ==
  
LDAP needs to be configured in the preferences file or via the perferences dialog:
+
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.
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 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:
 +
 
 +
<code>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</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.

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.