09 necto architecture_ready
Download as PPTX, PDF0 likes734 views
The document discusses the architecture and security of the Necto software. It describes the client-server architecture with the Necto server connecting an analysis server to customer data warehouses. It also covers role-based security for restricting access to data and content, with roles determining which data dimensions and members users can access. Users are imported from Active Directory domains and assigned roles to control their permissions.
09 necto architecture_ready
- 1. Necto Training Module 9: Necto Architecture and Security
- 2. Agenda Necto Architecture Necto Security
- 4. Prerequisites Necto Software IIS Analysis Client Server Data Necto Server Customer Data Warehouse Windows 2008 Necto Server
- 5. BI Services BI Display BI Calculations Necto Software NovaView.aspx BI Server IIS Analysis Client Server Data Necto Server Customer Data Warehouse Windows 2008 Necto Server
- 6. Administrative Services Administration of: • Workboard trees • Social • Users and roles Necto Software • Etc. NovaView.aspx BI Server IIS Admin Web Admin Analysis Services Server Server Client Social Data Necto Server Customer Data Warehouse Windows 2008 Necto Server
- 7. Necto Server Data Calculation and Storage Can use SQL express installed or with Necto SQL Express Necto DB SQL Server Necto Software NovaView.aspx BI Necto Calculations Server Server/s IIS Recommended: Admin web Admin separate SQL services Server Client servers Social Necto Server Both BI and Admin servers use this work area Windows 2008 Necto Server
- 8. Universal Data Connector (UDC) Provides connection to additional data sources Necto Software NovaView.aspx BI Server IIS Admin Web Admin Analysis Services Server Server Client Social Data Necto Server UDC Customer data Warehouse LB Performs load balancing Analysis of UDC requests Windows 2008 Services instance Data Necto Server SQL Sources Creates and updates cubes UDC
- 9. Necto Architecture Summary SQL Express Necto DB SQL Server Necto Software NovaView.aspx BI Necto Calculations Server Server/s IIS Admin Web Admin Analysis Services Server Server Client Social Data Necto Server UDC Customer Data Warehouse LB Analysis Windows 2008 Services instance Data Necto Server SQL Sources UDC
- 10. Security
- 11. Security Overview Content Data (OLAP ) Security Security • Can be Roles implemented by user name or by the role the user belongs to Users • Which • Which portions of the workboards will data will be available be available • Defined in terms of Dimensions and Members
- 12. Content Data (OLAP ) Security Security Roles Users OLAP Security
- 13. Data (OLAP) Security Users are added to roles in a SSAS cube OLAP Domain Users Roles specify which objects and members will be available Roles to users Users must be part of an Active Groups Directory domain and imported into Necto Dashboard User User User
- 14. Users and Roles OLAP Domain Necto Roles can be added manually Users Roles Import Roles Groups Groups User User User Domain Server Necto When an active directory Users Users Users user logs into Necto – a user is created in Necto From Necto Manually Server defined
- 15. Data (OLAP) Security Necto Users are added to roles in a SSAS cube Roles Roles specify which objects and members will be available to users Groups Users must be part of an Active Directory domain and imported into NovaView Dashboard Necto and Server users can be mapped to domain users Domain Server Necto Users Users Users For example: a guest user
- 16. Role vs. User Based Security Content Data (OLAP ) Security Security Both security Roles methods can be implemented per role or per user. What should I use? Users
- 17. Role vs. User Based Security Connection to data source is defined by: Server, database, cube, security (Role or User) Role-based security enables reuse of connection Better efficiency of Necto and AS Necto Analysis Server Server
- 18. Content Data (OLAP ) Security Security Roles Users Content Security
- 19. Content Security Public Workboards Access rights (permissions) are assigned by administrator per role Private folders Per user User can share with users or roles Shared folders of other users Best Practice: • Public folders – view-only for most users • Users should create new workboards in their private folder
- 20. Content Permissions Levels Name Weight Description All administrative rights, including giving rights to Admin 5 others The user will see that the workboard exists Deny 4 but will not be able to view it User will be allowed to change and edit the Write 3 workboard Read 2 View only The user will not see that the Workboard exists Hidden 1 Therefore will not be able to access it No permission has been assigned. Permissions None 0 will be inherited from parent folder
- 21. User James Part of Role A Role A = Permission Admin Permission = Inherit Admin Admin 5 Deny 4 Write 3 Read 2 Hidden 1 None 0
- 22. Breaking Inheritance If Same Role Take Last, Unless Admin Role A = Permission Admin Role A = Permission Same Role, Take Last, Hidden Unless Admin Permission – Inherit Admin Role A = Permission Read Role A = Permission Same Role, Take Last Hidden Permission – Inherit Hidden Admin 5 Role A = Permission Read Deny 4 Role A = Permission Same Role, Write 3 Deny Take Last Read 2 Permission – Inherit Deny Hidden 1 None 0
- 23. Combining Hierarchies – User James is Member of Role A & B Role A = Permission Admin Role B = Permission MAX(Admin, Hidden Permission – Inherit Hidden) Admin Role A = Permission Read Role B = Permission MAX(Read, Hidden) Hidden Permission – Inherit Read Admin 5 Role A = Permission Read Deny 4 Role B = Permission MAX(Read, Write 3 Deny Permission – Inherit Deny) Read 2 Deny Hidden 1 None 0
- 24. Breaking & Combining Hierarchies First Break Then Combine Role A = Permission Hidden Role A = Permission Role B = Permission Role C = Permission Read Admin Read Role A = Permission Role B = Permission Role C = Permission Hidden Admin Hidden Role A = Permission Role B = Permission Deny Read Role A = Permission Role B = Permission Admin Hidden Role A = Permission Role B = Permission Read Deny Admin 5 Role A = Permission Hidden Deny 4 Role A = Permission Role B = Permission Write 3 Deny Read Read 2 Hidden 1 None 0
- 25. Remove Remove any role that James is not a part of
- 26. Removing Role C “James is a Member of Role A & B” Role A = Permission Hidden Role A = Permission Role B = Permission Role C = Permission Read Admin Read Role A = Permission Role B = Permission Role C = Permission Hidden Admin Hidden Role A = Permission Role B = Permission Deny Read Role A = Permission Role B = Permission Admin Hidden Role A = Permission Role B = Permission Read Deny Admin 5 Role A = Permission Hidden Deny 4 Role A = Permission Role B = Permission Write 3 Deny Read Read 2 Hidden 1 None 0
- 27. Break Hierarchy In each role use Thumb Rule 1: Break Hierarchy “Use last folder permission unless Root = Admin”
- 28. Breaking Hierarchies “Use last folder permission unless Root = Admin” Role A = Permission Hidden Role A = Permission Role B = Permission Read Admin Role A = Permission Role B = Permission Hidden Admin Role A = Permission Role B = Permission Deny Read Role A = Permission Role B = Permission Admin Hidden Role A = Permission Role B = Permission Read Deny Admin 5 Role A = Permission Hidden Deny 4 Role A = Permission Role B = Permission Write 3 Deny Read Read 2 Role A = Permission Role B = Permission Hidden 1 Deny Admin None 0
- 29. Combine The highest permission is selected
- 30. Combining Hierarchies ”The highest permission is selected” Role A = Permission Hidden Role A = Permission Role B = Permission Read Admin Role A = Permission Role B = Permission Hidden Admin Role A = Permission Role B = Permission Deny Read Role A = Permission Role B = Permission Admin Hidden Role A = Permission Role B = Permission Read Deny Admin 5 Role A = Permission Hidden Deny 4 Role A = Permission Role B = Permission Write 3 Deny Read Read 2 Role A = Permission Role B = Permission Hidden 1 Deny Admin None 0
- 31. Breaking & Combining Hierarchies First Break, Then Combine Role A = Permission Hidden Role A = Permission Role B = Permission Read Admin Role A = Permission Role B = Permission Hidden Admin Role A = Permission Role B = Permission Deny Read Role A = Permission Role B = Permission Admin Hidden Role A = Permission Role B = Permission Read Deny Admin 5 Role A = Permission Hidden Deny 4 Role A = Permission Role B = Permission Write 3 Deny Read Read 2 Permission – Inherit Admin Hidden 1 None 0
- 32. Summary In this lesson you have learned about: Necto Architecture Necto Security