Difference between revisions of "Authentication methods"
(→Authentication Methods) |
(→Authentication Methods) |
||
Line 9: | Line 9: | ||
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. | 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. | + | 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. |
− | |||
+ | |||
+ | '''LDAP''' needs 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 | ||
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> | ||
+ | |||
+ | |||
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. | 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. | ||
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. |
Revision as of 09:09, 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.
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.
LDAP needs 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
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.
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.