Authentication and authorization
Both authentication and authorization are optional in IS5 but of course authentication needs to be activated to achieve authorization
Authentication
Preparation
Make sure that you start IS5 with authentication turned off and then create one (or more) users belonging to the (implicitly defined) group “administrators” then turn authentication on and then restart IS5
It’s usually better to administrate accesses before creating users because then those groups are visible when creating users
Notes
Passwords are not mandatory and perhaps an administrator can create users without password and then the user could update (i.e. set) a password them self
Authorization
Current user is authorized if the user belongs to a group (UserGroup) the current action and resource demands
Action
An action is in practice a service or a (HTTP) request and can be found in the http-directory with the rq-extension
UserGroups
An action may have direct groups attached to it self
Actions that have direct groups attached is typically those where folder structure is irrelevant e.g. create_user.rq that have predefined group “administrators”
It is possible to add and/or change those defined declarative groups (but perhaps not recommended)
ServiceCategory
An action may have categories attached to it self (typically just one)
Actions that have categories attached is typically those when where folder is relevant e.g. create_item.rq that have predefined category “operate”
It is possible to add and/or change those defined declarative groups (but perhaps not recommended)
As for now ISM can only handle 4 categories for access administration
- read
- write
- operate
- execute
IS is transparent to any existing category
Access
If an action is performed, the system tries to figure out what groups are permitted to perform the action
Either the action is configured with groups (UserGroups) or category (ServiceCategory) and in the latter case the system knows what resource the action is handling and tries to find out the closest access configuration to determine what groups are granted to perform current action
This configuration is less static and are preferably done via ISM and the result is stored as inboz_access-files in the folder structure
Filtering
Certain services supply or handle, not just a single resource (folder) but, a quantity (typically a search) that may give potential results from the whole system and those results are filtered according to what current user are authorized to
Propagation
Every access configuration is effective in deeper folder levels until it is overridden by a new access configuration
Actions (current)
administrators (group)
- create_access.rq
- create_user.rq
- delete_access.rq
- delete_user.rq
- drop_item.rq
- get_server_log.rq
- list_access_groups.rq
- load_item.rq
- read_access.rq
- update_access.rq
- update_user_groups.rq
read (category)
- find_items.rq
- get_events.rq
- get_integration_sequence.rq
- get_mapping_info.rq
- get_possible_conversion_tags.rq
- get_scheduled_search_counts.rq
- get_sessions.rq
- get_transactions.rq
- get_transaction_flow.rq
- get_transaction_message.rq
- list_files.rq
- list_folders.rq
- list_items.rq
- list_item_relations.rq
- read_file.rq
- search_files.rq
- search_folders.rq
- search_items.rq
- get_adapter_metrics.rq
- get_current_adapter_metrics.rq
- get_process_metrics.rq
- get_current_process_metrics.rq
write (category)
- clear_errors.rq
- create_file.rq
- create_folder.rq
- delete_file.rq
- delete_folder.rq
- move_path.rq
- set_integration_sequence.rq
- update_file.rq
execute (category)
- abort_transaction.rq
- delete_transaction.rq
- reprocess_transaction.rq
- resend_transaction.rq
- run_now.rq
operate (category)
- create_item.rq
- delete_item.rq
- get_adapter_protocol_trace.rq
- get_adapter_script_trace.rq
- get_transaction_trace.rq
- read_item.rq
- update_item.rq
Samples
|
User |
Groups |
|
Alphonse |
administrators |
|
Bennet |
black_sabbath deep_purple |
|
Charlie |
black_sabbath led_zeppelin |
|
Service |
Category |
Groups |
|
create_user.rq |
administrators |
|
|
create_item.rq |
operate |
|
|
read_item.rq |
read |
|
Access |
Category |
Groups |
|
/ |
read |
black_sabbath led_zeppelin |
|
/aaa |
read |
black_sabbath |
|
/aaa |
operate |
black_sabbath |
|
/bbb |
read |
deep_purple led_zeppelin |
|
/bbb |
operate |
deep_purple led_zeppelin |
These tables are not in the same arrangement as shown in ISM but this is how it logically works
The mechanism is trying to explore what groups may grant access to a certain action/operation/service/resource
http://some.se:24780/create_user.rq?u=GeezerButler
Is immediately already declarative configured with group “administrators” and in this case only Alphonse will be granted to use that service
http://some.se:24780/create_user.rq?path=/aaa/FirstInput.inobiz_folder_in
Service belongs to category “operate” and the closest access configuration is found in “aaa” and that only group “black_sabbath” is granted and thus will Bennet and Charlie be authorized
http://some.se:24780/create_user.rq?path=/aaa/zzz/OtherInput.inobiz_folder_in
Service belongs to category “operate” and the closest access configuration is found in “aaa” and that only group “black_sabbath” is granted and thus will Bennet and Charlie be authorized
http://some.se:24780/create_user.rq?path=/bbb/CrazyInput.inobiz_folder_in
Service belongs to category “operate” and the closest access configuration is found in “bbb” and that groups “deep_purple” and “led_zeppelin” are granted and thus will just Charlie be authorized
0 Comments