390 likes | 521 Views
Progress Dynamics™ 2.1A. Group Security. Cheryl LaBarge, Product Readiness tPC Neil Bell, Progress Dynamics Development. Agenda. Security Review Key Enhancements Guidelines Demonstration Questions and Answers. Security Review. Security Model User Types Structures Allocations
E N D
Progress Dynamics™ 2.1A Group Security Cheryl LaBarge, Product Readiness tPC Neil Bell, Progress Dynamics Development
Agenda • Security Review • Key Enhancements • Guidelines • Demonstration • Questions and Answers
Security Review • Security Model • User Types • Structures • Allocations • Resolution of Model
Security Model Revoke Scenario- Application for Subsidiary Offices with access available to the majority of application
Security Model *Grant Revoke Scenario- Application for vendors to update products available to internal system for ordering
Security User Types – WHO? • Users • Individuals • Option available to make profile User • User Categories • Descriptive grouping of users • *Security Groups • Automatically propagate changes • Not hierarchical • Conflicts resolved with least restrictive approach
Security Structures – WHAT? • *Actions • Data Ranges • Fields • Login Companies • Default Structures • Containers • Data • Menu Items • Menu Structures Containers Data Menu Items Menu Structures
Security Allocations – HOW? • Associate who may use what? • Associate users to structures • Define key parameters • Document the purpose of the association
Resolving Conflict Most specific to least checking • Specific user, specific login company • Specific user, any login company • All groups, to which the user belongs • If more than one, it applies cumulative least restrictive • Allocations against all users • Within the category, • Allocation against all users within specific login company • Allocation against all users within alllogin companies
Apply the Rules Model = Revoke Groups A B C 3 User Maintenance Record – Action - Folder 1 User – No restriction on the user 2
Agenda • Security Review • Key Enhancements • Guidelines • Demonstration • Questions and Answers
Enhancements - General • Support for group based security • Default security groups – new users linked automatically • Addition of grant model • Improved UI for security leveraging treeview interface • Security Maintenance • Security Allocations • Security Query • Security Processing
Secondary Features • Conversion function – user to groups • Fully documented API
Enhancements Issues • 11422 - Order of security allocations at runtime • 11237 - Consolidated groups • 11349 - Group w/out security allocations treated as consolidated group • 11311 - Assigning default groups (check the resolution) • 11346 - Overriding group restrictions at the user level • 11621 - Data ranges API uses chr(3) delimiter • 11975 - Can't set security structures below container level
Agenda • Security Review • Key Enhancements • Guidelines • Demonstration • Questions and Answers
Guidelines • Choose model • Identify functionality access • Consolidate groups • Plan default • Plan company • Plan user • Review model for complex overrides • Implement security model
Security Demonstration • Outline scenario • Follow guidelines • Implement using product
Case Study Scenario • Sporting Goods application • Typical Users • Admin – all access • Jr. Salesrep • Robert Newman • Seth Macabee • Nicole Milton • Sr. Sales Representative • Charles Oliver • All Sales • Tom Gun
Choose a Model *Grant Revoke Scenario- Most user have access to application. Easiest to revoke.
Replacing a Model • Backup your current security work • Backup the appropriate tables GSMFF - Fields GSMGA - Group Allocations GSMLG - Login Companies GSMSS - Security Structures GSMTO - Actions (Tokens) GSMUS - Users (and Groups) • Please note that Group Allocation and Users are not exported separately they are combined in the GSMUS export.
Identify Functionality Access • Jr Salesrep • Default group • Limited access • Balance hidden • Credit Limit and Discount read-only • Sr Salesrep • Override the default on balance read-only • All Salesrep • Combines both groups with least restrictive result
Consolidate Groups JR SR Customer Info Order Entry All Sales
Plan Default • Default group • Jr Salesrep • Senior level group with more access • Sr Salesrep
Plan Company Default Company • Starting small • Only our default company • Major concern for hosted applications that might have multiple vendors sharing the application resources • Third Party Group for new companies SR JR All
Plan User • Typical Users • Admin – all access • Jr. Salesrep • Robert Newman • Seth Macabee • Nicole Milton • Sr. Sales Representative • Charles Oliver • All Sales • Tom Gun
Review For Overrides • You can remove a menu structure for an individual • Nicole Milton • Jr. salesrep • Access to Order Entry • User override • Restrict Order Entry MenuBand Menu Band Restricted
User Overrides Jr Sales • Example • Seth Macabee • Jr. Salesrep group member • Balance field – Hidden • User Override • Balance field – Full Access User– Seth Macabee
Establish (Maintenance) Actions Data ranges Fields Login Companies Security groups Users Apply Security (Allocation) Actions Containers Data Data Ranges Fields Login Companies Menu Items Menu Structures Use Enquiry to determine security allocation combinations If necessary use Security processing to convert User and Profile Users to Groups Implement security model
Containers - oeOrderFoldWin RNewman
Fields– ARMCU • Jr Salesrep • Balance • Hidden • Credit Limit • Read-only • Discount • Read-only
No Security Allocations • Data Ranges • Access is all or nothing • Login Companies • Only one company in original model
Groups – Name field contains Group • Model based • Revoke • Grant No Overrides
UI Users – Name Field contains user • Regardless of Model • Revoke Access • Not Secured Overrides
Converting Users to a Group • Converting a user • All security allocations against the user being converted from is transferred to the new security group. • User is linked to the newly created security group, he becomes the first “member”. • Converting a profile user • Only security allocations common to the profile user being converted, • All users linked to the profile user will be transferred to the newly created group. • Any “non common” security allocations are not moved, and stay assigned directly to the applicable user.
Demonstration • Maintenance • Allocations • Enquiry • Processing
Questions and Answers • Cheryl LaBarge clabarge@progress.com • Documentation • Progress Dynamics Developer’s Guide Chapter 13 • Progress Dynamics Administration Guide Chapter 3 • Specifications • Ntdata\apps\specs\ Dynamics\2.1a\specs\group_based_security_spec.doc • IssueZilla • Search dynamics Security