 |
|
|
|
|
This page describes the standard security templates that come with Instant JChem. Most of the time one of these templates can be used with little or no customisation. We recommend that you define your security configuration before you invest too much time on loading data into the database.
Instant JChem defines 4 roles that control which operations the user can perform. A user can have any of these 4 roles. At least one role must be defined for the user to be active.
ROLE_ADMIN: Can configure security settings and manage users.
ROLE_EDIT_SCHEMA: This role is required for all Instant JChem operations that create or delete database tables and columns. This means that without this role you will not be able to add new Instant JChem Entities or Fields , nor be allowed to import data in a way that requires new Entities or Fields to be created.
ROLE_EDIT_DATA: With this role you can edit data in existing tables, add new rows or delete existing rows. You cannot add new fields or tables.
ROLE_USER: You can view all data but cannot make any changes.
As adding or, particularly, deleting tables or columns (ROLE_EDIT_SCHEMA) would have bad consequences on all other concurrent users, these changes must be made when the Schema is in single user mode. This ensures that you are the only current user of the database. When you are finished making changes you should disconnect so that other users can connect.
When you log in to a remote database with ROLE_EDIT_SCHEMA role, AND are the only current IJC user of the database then you will be asked whether you want to connect in single user mode (for a local database this step is skipped and you are always connected in single user mode so that you always have full access to local databases). Only connect in single user mode if you need to make changes to the database tables and columns as you will be preventing other users from using the database whilst you are logged in. Once they can log in they will see any changes that you have made.
For use with local databases or single user remote databases. Whilst this security model is operating you are automatically logged in with full access rights (all 4 roles are defined) and you would not notice that any security was in place unless you read this!
This is the default security model if none other is defined. Typically, no configuration is needed for this security mode, but a template is provided in case there is a need to customise.
For use where you need a very simple way to provide access control and security is not a high concern. Usernames and passwords are stored in plain text within the security configuration file which is stored inside the particular Instant JChem database.
Typically the only configuration that is needed for this security mode is to edit the usernames, passwords and roles for your users. These are found in the configuration file. A typical entry looks like this:
admin=admin,ROLE_USER,ROLE_EDIT_DATA,ROLE_EDIT_SCHEMA,ROLE_ADMIN
The first word (before the equal sign, '=' ) is the username. The first word after '=' is the password. Following the password are the roles. All entries after '=' should be separated by commas. Additionally the enabled or disabled keywords can be specified to enable or disable the user. Without a disabled keyword users are enabled by default.
Important: At least one role must be defined for the user to be active.
Usernames and passwords are stored in special Instant JChem database tables. Passwords are encoded, and a mechanism for managing users and passwords is provided. This is the recommended solution where security is a concern.
This is slightly more complex to configure, but usually only takes a few minutes. The configuration provides the ability to define usernames, passwords and roles within database tables of a particular IJC database. Initially these database tables are not present, so you would not be able to log in until you had created one account which had at least ROLE_ADMIN and ROLE_EDIT_SCHEMA roles. To get around this problem the template also includes a special user with the username and password both set to "admin". This allows you to specify this configuration, log off and then log back in with this "admin" account so that you can edit your users. Once you have added at least one user with ROLE_ADMIN and ROLE_EDIT_SCHEMA roles you should then confirm that you can connect as this user and then delete the part of the configuration that defines this special user so as to remove this potential security hole.
Step 1: Select the template and apply it. The template will work as is, but there is some configuration that can be done if you wish to change things like the way passwords are encoded.
Step 2: Log off and log back in as user "admin".
Step 3: Re-open the security configuration editor and go to the User Management tab. Add the users you need. It is important that you define at least one user who has both ROLE_ADMIN and ROLE_EDIT_SCHEMA roles. You can add additional users at a later stage.
Step 4: Log off and log back in as the user who has ROLE_ADMIN and ROLE_EDIT_SCHEMA roles that you created in the previous step. Confirm that you can log in and edit the database. If not then log back in as "admin" and edit that user. Repeat until you confirm that this user can configure the security configuration.
Step 5: Once you are sure that you have defined a user that has the ability to configure the security settings, you can then remove the special "admin" user. Do this by removing the following line from the security configuration:
<ref local="tmpAuthenticationProvider"/>This is found within the bean with the id authenticationManager. Remove this line and update the configuration. Then log off and log back in. The "admin" user will no longer be active.
Important: At least one role must be defined for the user to be active.
Lightweight Directory Access Protocol is a protocol for accessing information across a network. It is commonly used to retrieve user information from a central location in an organisation. There are specific implementations of LDAP, such as the Open Source OpenLDAP software, and several vendors provide LDAP access to their directory information (e.g. Microsoft's Active Directory and Oracle's Oracle Internet Directory).
IJC usernames and passwords are located in this external server and accessed through LDAP. This is most appropriate for large organisations who already have a large number of users configured into their systems, and do not want to duplicate information inside the IJC database. It can also provide a common mechanism to control access across multiple IJC databases. Role information can also optionally be retrieved using LDAP.
This is the most complex to configure as the content of the external LDAP server depends on your particular installation, and so IJC needs to be configured to read the appropriate values from it. IJC comes with a sample configuration that can be used as a starting point, and this includes various options and comments that illustrate how to configure it against your particular LDAP server. Before using LDAP based security it is essential that you have a good understanding of LDAP (see here for a good introduction) and of Acegi security (see here. for the Acegi documentaion).
The configuration options are too varied to be able to describe in full here. The LDAP security template contains further information about how to configure LDAP security. Please consult this, as well as the following sources of information from the Acegi security web site:
If you need more information or assistance we suggest that you ask on the Instant JChem forum.
The following things (and much more) are possible to configure for LDAP authentication and authorisation:
In the provided template the user authenticates against the LDAP server using the username and password they provide. The Distinguished Name (DN) that is used for this authentication can be generated by:
Once the user is authenticated they must be assigned appropriate roles to be able to use IJC. These are one or more of ROLE_USER, ROLE_EDIT_DATA, ROLE_EDIT_SCHEMA and ROLE_ADMIN. The template provides two alternative approaches to doing this:
Copyright © 1998-2008 ChemAxon Ltd. All rights reserved.