Security And User Roles

From UG

Revision as of 18:16, 19 January 2010 (edit) Alex (Talk | contribs) ← Older edit		Current revision as of 02:17, 16 October 2013 (edit) (undo) Alex (Talk | contribs) m (moved Security Framework to Security And User Roles)
(51 intermediate revisions not shown)
Line 1:		Line 1:
-	[[Category:OpsAdmin]]	+	[[Category: OpsAdmin]]
-	== Classified As and Parent Mantis ==	+	== Info ==
		+	=== Parent Mantis ===
-	* Classified As: (small) (large) component / common feature / ...	+	[http://mantis.jaguarfreight.com/mantis/view.php?id=607 0000607: (Security Framework/User Access) .......]
-	* Parent Mantis: [http://mantis.jaguarfreight.com/mantis/view.php?id=tbd tbd]	+
		+	=== Scope of this wiki ===
		+
		+	This covers our security framework/user access admin.
		+
		+	== Glossary ==
		+
		+	'''Security Framework''' - framework that provides authentication, authorization and other security features for enterprise applications.
		+
		+	== Core Business Need ==
		+
		+	System needs to have different levels of access. (As any system of this scale).
-	== Business Needs ==
	== Business Requirements ==		== Business Requirements ==
-	== Technical Specification ==
-	=== Summary ===
-	=== User Interface and Functionality ===
-	=== Entities and Attributes ===
-	=== Special Cases and Misc ===	+	=== 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.
		+
		+	=== BR Version 2.0 ===
		+
		+	==== 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.
		+
		+	==== 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.
		+
		+	==== New access options: per tab ====
		+
		+	System should be able to block access not only to buttons but tabs as well
		+
		+	==== 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).
		+
		+
		+	===== 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
		+
		+	=== 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
		+
		+	--[[User:Alex|Alex]] 20:55, 29 January 2010 (UTC)
		+
-	=== Look And Feel ===
	=== Figures ===		=== Figures ===
-	==== Figure: XXX ====	+	==== Figure 1: UI ====
-	== Questions and RFC ==	+	[[File:User Access Admin.JPG]]
-	== Known Non Critical Bugs ==	+	== SOW 0 ==
		+	See [[#Business_Requirements]]
		+
		+	== SOW 1 ==
		+	'''0002971''': [Intl Portal] (ph2) User's access permissions (UAP) Core (Core functionality and Admin Console)
		+
		+	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 ==
-	== DB ==	+	=== This doc has been created ===
		+	--[[User:Alex|Alex]] 18:42, 19 January 2010 (UTC)
		+
		+	=== Re-design: Managing access types should be through admin; new access options: per tab, per form control ===
		+	--[[User:Alex|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
		+
		+	=== m902 ===
		+
		+	* [http://mantis.jaguarfreight.com/mantis/view.php?id=902 0000902: (*ph1)(User Access Admin) Add new lines to access table ]
		+
		+	* 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)
		+
		+	=== 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 Status and SOW covered ===
		+
		+	Up to date = Yes. Covered: [[#SOW 0]], [[#SOW 1]].
		+
		+	=== Menu ===
		+
		+	New Security item added to Admin menu:
		+
		+	Admin > Security > User roles
		+
		+	=== User role manager ===
		+
		+	User roles (types) can be added.
		+
		+	Each menu item / feature can be added or removed from access list for specific role.
		+
		+	[[File:Edit role.JPG]]
		+
		+
		+	Each user can have multiple roles.
		+
		+	[[File:User profile with user roles.GIF]]
		+
		+	See example of "Report user":
		+
		+	[[File:Report user.JPG]]
		+
		+	Technical Note:
		+	---------------
		+	Authorization system is implemented using Spring Framework. Secured action set is configurable from XML configuration file

---

Current revision as of 02:17, 16 October 2013

Contents 1 Info 1.1 Parent Mantis 1.2 Scope of this wiki 2 Glossary 3 Core Business Need 4 Business Requirements 4.1 BR Version 1.0 4.2 BR Version 2.0 4.2.1 Managing access types should be through admin 4.2.2 Superuser 4.2.3 New access options: per tab 4.2.4 Per form control 4.2.4.1 Super configurable option 4.3 Comments from Systems Analyst 4.4 Figures 4.4.1 Figure 1: UI 5 SOW 0 6 SOW 1 7 SOW 2 7.1 SOW 2 Implementation Notes 8 SOW 3 9 History 9.1 This doc has been created 9.2 Re-design: Managing access types should be through admin; new access options: per tab, per form control 9.3 m902 9.4 0002418: [EDI to TMS] (Client App Admin) (TMS Tab) Add TMS tab with config options 9.5 0002971: [Intl Portal] (ph2) User's access permissions (UAP) Core (Core functionality and Admin Console) 10 User Guide 10.1 User Guide Status and SOW covered 10.2 Menu 10.3 User role manager

[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

See #Business_Requirements

[edit] SOW 1

0002971: [Intl Portal] (ph2) User's access permissions (UAP) Core (Core functionality and Admin Console)

See http://ct.jaguarfreight.com/wiki/International_Portal_Solution#Users_access_levels_and_security_framework

[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

• 0000902: (*ph1)(User Access Admin) Add new lines to access table

• 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