Security And User Roles
From UG
(→SOW 1) |
m (moved Security Framework to Security And User Roles) |
||
(9 intermediate revisions not shown) | |||
Line 101: | Line 101: | ||
See http://ct.jaguarfreight.com/wiki/International_Portal_Solution#Users_access_levels_and_security_framework | See http://ct.jaguarfreight.com/wiki/International_Portal_Solution#Users_access_levels_and_security_framework | ||
+ | |||
+ | == SOW 2 == | ||
+ | '''* 0003305: [* IPortal] (Security Framework/User Access) Next version under SOW 2''' | ||
+ | |||
+ | * Enable log in of internal user to Client with basic functionality | ||
+ | ** extra column in access table for client app access | ||
+ | |||
+ | * add Superuser role | ||
+ | |||
+ | * have one login panel for both client and internal (on jaguarfreight.com) | ||
+ | |||
+ | === SOW 2 Implementation Notes === | ||
+ | * Any Internal Jaguar User can now log-in into Client Application without having Client User or Planner/Shipper roles specified. | ||
+ | ** UserRole editor window have two panels for configuring allowed actions of Internal and Client applications. | ||
+ | ** Implemented Welcome Page Dashboard configuration and Edit User Profile options as basic functionality. | ||
+ | ** Both Client and Jaguar users can log-in into Client application via www.jaguarfreight.com login panel. | ||
+ | |||
+ | * Superuser Role added: | ||
+ | ** SuperUser is hidden hardcoded (built-in) system role. | ||
+ | ** List of SuperUsers is stored in file "/security.properties" and can be configured by system administrator. Changes are applying without restarting application. | ||
+ | ** SuperUser allowed to perform any operations by default. There is no need to manually edit this role in the role editor window. | ||
+ | ** Only SuperUsers can manage "Users Roles Admin". But SuperUser can create role for group of trusted users and assign "User Roles Administration" to delegate this option | ||
+ | |||
+ | == SOW 3 == | ||
+ | |||
+ | * Log In functionality | ||
== History == | == History == | ||
Line 124: | Line 150: | ||
=== 0002418: [EDI to TMS] (Client App Admin) (TMS Tab) Add TMS tab with config options === | === 0002418: [EDI to TMS] (Client App Admin) (TMS Tab) Add TMS tab with config options === | ||
+ | === 0002971: [Intl Portal] (ph2) User's access permissions (UAP) Core (Core functionality and Admin Console) === | ||
== User Guide == | == User Guide == | ||
Line 129: | Line 156: | ||
=== User Guide Status and SOW covered === | === User Guide Status and SOW covered === | ||
- | Up to date = Yes. Covered: [[# | + | Up to date = Yes. Covered: [[#SOW 0]], [[#SOW 1]]. |
=== Menu === | === Menu === |
Current revision as of 02:17, 16 October 2013
[edit] Info
[edit] Parent Mantis
0000607: (Security Framework/User Access) .......
[edit] Scope of this wiki
This covers our security framework/user access admin.
[edit] Glossary
Security Framework - framework that provides authentication, authorization and other security features for enterprise applications.
[edit] Core Business Need
System needs to have different levels of access. (As any system of this scale).
[edit] Business Requirements
[edit] BR Version 1.0
- Each jaguar user should be of one access type. This type controls what resources (components, etc) and features user can use. For example "Basic Ops" can not access accounting module.
- Types we need:
- Basic Ops
- Super Ops
- Basic Acc
- Super Acc
- Management
- Sales
- Blank 1
- Blank 2
- Some of the Access Options we need (not a full list):
- Ops Home (access to)
- Admin Home
- Acc Home
- CT Rights Administration
- Delete saved documents
- Typical access options would be to allow to click on a button and proceed to a homepage of a component (example: Acc button on CT2 homepage). If user does not have enough rights then system could show pop-up stating that user has no access. Or we could simply hide that button.
- One design option would be to present a table - see #Figure 1: UI
Please note that above Biz Reqs has been implemented.
[edit] BR Version 2.0
[edit] Managing access types should be through admin
Instead of hard coded "blank1", "blank2" user types we need ability to create/delete/edit as many as we wish through admin.
[edit] Superuser
We probably need to add hard coded "superuser level" that can do anything. This uname/password can not be editable through the systems UI. And it can not be deleted through the system.
[edit] New access options: per tab
System should be able to block access not only to buttons but tabs as well
[edit] Per form control
In the future we will need to create CT2 sub systems - limited versions of CT2 (with just limited functionality available). Example: trucker user would need to be able to create CT and edit/view of 40% of fields, only on Gen Tab. Ideally we would like to make it configurable through admin (vs making them hard coded).
[edit] Super configurable option
- List as many options as possible in access table (all CT2 sections, sub sections, all tabs, all fields on CT profile)
- implement this only if feasible / possible
[edit] Comments from Systems Analyst
- Superuser requirements: please research alternatives and make a decision what to use, for example "Linux root approach".
- UI design: use usual "modal window approach" if possible
- first create #Preliminary Design / Prototype and review with me;
- create UI prototype in Paint or use any other tool/approach
--Alex 20:55, 29 January 2010 (UTC)
[edit] Figures
[edit] Figure 1: UI
[edit] SOW 0
[edit] SOW 1
0002971: [Intl Portal] (ph2) User's access permissions (UAP) Core (Core functionality and Admin Console)
[edit] SOW 2
* 0003305: [* IPortal] (Security Framework/User Access) Next version under SOW 2
- Enable log in of internal user to Client with basic functionality
- extra column in access table for client app access
- add Superuser role
- have one login panel for both client and internal (on jaguarfreight.com)
[edit] SOW 2 Implementation Notes
- Any Internal Jaguar User can now log-in into Client Application without having Client User or Planner/Shipper roles specified.
- UserRole editor window have two panels for configuring allowed actions of Internal and Client applications.
- Implemented Welcome Page Dashboard configuration and Edit User Profile options as basic functionality.
- Both Client and Jaguar users can log-in into Client application via www.jaguarfreight.com login panel.
- Superuser Role added:
- SuperUser is hidden hardcoded (built-in) system role.
- List of SuperUsers is stored in file "/security.properties" and can be configured by system administrator. Changes are applying without restarting application.
- SuperUser allowed to perform any operations by default. There is no need to manually edit this role in the role editor window.
- Only SuperUsers can manage "Users Roles Admin". But SuperUser can create role for group of trusted users and assign "User Roles Administration" to delegate this option
[edit] SOW 3
- Log In functionality
[edit] History
[edit] This doc has been created
--Alex 18:42, 19 January 2010 (UTC)
[edit] Re-design: Managing access types should be through admin; new access options: per tab, per form control
--Alex 18:39, 19 January 2010 (UTC)
- mantis: http://mantis.jaguarfreight.com/mantis/view.php?id=1690
- Biz Req updated? Y see #BR Version 2.0
- Tech Spec updated? N
[edit] m902
- Add the following options:
- Address book (every tab - separate access option)
- Reports (every report category [see m1873] - separate access option)
- Admin > Users (every tab - separate access option)
- Admin > Client Companies (every tab - separate access option)
[edit] 0002418: [EDI to TMS] (Client App Admin) (TMS Tab) Add TMS tab with config options
[edit] 0002971: [Intl Portal] (ph2) User's access permissions (UAP) Core (Core functionality and Admin Console)
[edit] User Guide
[edit] User Guide Status and SOW covered
Up to date = Yes. Covered: #SOW 0, #SOW 1.
[edit] Menu
New Security item added to Admin menu:
Admin > Security > User roles
[edit] User role manager
User roles (types) can be added.
Each menu item / feature can be added or removed from access list for specific role.
Each user can have multiple roles.
See example of "Report user":
Technical Note: --------------- Authorization system is implemented using Spring Framework. Secured action set is configurable from XML configuration file