A mi me cuesta mucho entender el modelo de seguridad de AX, pero menos mal que tenia por hay un documento de M$ que vamos a pegar integro por si a alguien le sirve pa algo…

Configuration and security in Navision Axapta

This technical information paper will go through the concept of the configuration and security system introduced in version 3.0 of Navision Axapta.

Introduction

With version 3.0 of Navision Axapta the Configuration and Security system is introduced. This system is an extension of the feature key system that has existed since the first version of Axapta.

This paper is an introduction to the concept and ideas behind the new system. The paper will not deal with the technical aspects of how to create configuration and security keys and connect these to application objects. These issues are covered in the Navision Axapta Developer’s Guide, which is available from the Help menu in the toolbar.

For help on specific forms in Navision Axapta, please consult the online help.

Configuration and security key concept

The new security system was created to make the system more intuitive and flexible, and easier for the administrator to set up. The feature keys are replaced by two types of keys: configuration and security keys. This means, that the double-function the feature keys previously had, is now replaced by two types of keys each having one function.

The standard version 2.5 of Navision Axapta had more than 1,000 feature keys. The new system will only have few, but well-defined keys. To maintain the flexibility, security can now be set up on each menu item.

License codes

The license code concept has not changed on the interface with version 3.0. The setup form still looks the same, and license information can be entered manually or loaded from the license file. But license codes are now defined in the AOT. The specific codes, however, are still requested at, and generated by Navision.

Configuration keys

Configuration keys are used to disable or enable functionality and, according to the name, used for configuration of your system. Configuration keys are present everywhere in the AOT like the feature keys were present.

When buying license codes and entering these in the system, you perform the first steps of the configuration. A more detailed configuration is done from the Administration menu; click Setup, then System and double-click Configuration. In most cases license codes control the configuration keys, therefore it is not possible, and would not make sense, to disable a configuration key. A configuration key, however, can control a number of child configuration keys, and they can be either disabled or enabled as required. An example could be a company buying the Trade module license code; the company wants most of the functionality in this module, but does not do business with other countries, and chooses therefore to disable the Foreign trade configuration key. This can all be controlled from the Configuration form.

A minimized system

Having loaded the license code file, the system will start up minimized. This means that all child configuration keys are disabled. Any required extra features can safely be enabled later. A specific setup can still be exported and imported, or, if necessary reset to standard, which is the minimized system. The minimized system will not be used during an upgrade.

Security keys

Having set up the configuration keys, security must be considered. Security keys are used to control access to functionality for users. The security keys are used almost everywhere the feature keys were, except for indexes, fields and types:

• Indexes – the performance of indexes must be available for all users, just as in version 2.5.

• Fields – security on fields must be set up from the User group permissions form, under the table they belong to.

• Types – security can only be applied to fields, making the concept of indirect access obsolete.

Security keys control access to menu items and tables, and setup is done from the Administration menu, click Setup, then Security, and User group permissions. Access for menu items and tables can be set to:

• No access,

• View,

• Edit,

• Create, and

• Full control.

   

The figures (2 and 3) below illustrate the hierarchy of the configuration and security keys.

Key hierarchy

Fig 3.: (C) = Configuration key, (S) = Security key, (MI) = Menu item, and (T) = Table.

 

Figure 3 illustrates how security keys control menu item and table access, and how the Ledger configuration key controls the Cust security key.

For each module, a set of 9 security keys exists, they all have the same naming, and the prefixes denote the module. For the Accounts Receivable module the security keys are:

• Cust

• CustDaily,

• CustJournals,

• CustInquiries,

• CustReports,

• CustPeriodic,

• CustSetup,

• CustMisc, and

• CustTables.

  The security key structure resembles the Main menu structure. To make setup easier, drill-down of menu items is possible. A drill-down will display the tables, form controls and other menu items that are accessible from the menu item.

Record level security

Another new feature for version 3.0 is the Record level security system. It can be used in addition to the other permissions setup in Navision Axapta. For each combination of company, user group, and table a query can be set up, limiting data access for the specific combination. Specify, for example, that a certain user group within a company only has access to see customer numbers from 1000 to 4999. Row level security is set up from the Administration menu, under Setup, then Security, and Record level security.

Read more about Record level security in the online help.

Forms’ setup

In previous versions, an extension of the security access was to set up access to fields etc. on specific forms. The setup was done from each specific form for the user group. With version 3.0, the same functionality is available, but it is handled differently. Granting access to form controls is done from the User group permissions form. In the tree, each control for a specific form, this being a field, a button or a display field can be set to the appropriate access level.

Comparison

For the user coming from an Axapta version 2.5, the changes may not seem very overwhelming on the interface. The main difference between the old and the revised system is the split-up into two different types of keys. This means that it is more obvious to the user what keys are used for what purpose.

Another difference is, that indirect access no longer exists. Indirect access was introduced to allow related fields to be shown in the related table in order to, for example, show the Item number on a Sales Order. Since it is no longer possible to set security on types, the Item number field will not be removed, and the indirect access is not necessary. To remove the Item number field from the Sales Order, use table access on the sales order table and item number field.

The following table illustrates the Feature key system versus the Configuration system:

 

Functionality	2.5	3.0
License codes	Used for registering license information. Codes are requested at Navision.  License codes are defined in the kernel.	Used for registering license information. Codes are requested at Navision.  License codes are defined in the AOT.
Configuration keys	 Did not exist as a separate type of key. The function lied in Feature keys.	 Are used for enabling/disabling functionality.
Security keys	 Did not exist as a separate type of key. The function lied in Feature keys.	 Are used for assigning access to user groups.
Users	Users are created, and permissions are assigned to User groups. A user must be member of at least one User group.	Users are created, and permissions are assigned to User groups. A user must be member of at least one User group.
User groups	Permissions are assigned to User groups. A User group can belong to one or more Domain(s), and can have different permissions assigned through the Domain.	Permissions are assigned to User groups. A User group can belong to one or more Domain(s), and can have different permissions assigned through the Domain.
Companies	A company can be connected to one or more Domain(s).	A company can be connected to one or more Domain(s).
Domains	A domain is a collection of one or more company accounts. The purpose of domains is to enable user groups to have some permissions within a number of company accounts, and other permissions within other company accounts.	A domain is a collection of one or more company accounts. The purpose of domains is to enable user groups to have some permissions within a number of company accounts, and other permissions within other company accounts.
User group permissions	User group permissions are assigned for a user group within a certain domain. The same user group can have different permissions assigned within each domain.  Feature keys controlled the access rights for user groups to features, menus and tables.	User group permissions are assigned for a user group within a certain domain. The same user group can have different permissions assigned within each domain.  Security keys control the access for user groups. Each module is divided into 8 categories, resembling the Main menu structure: Daily, Journals, Inquiries, Reports, Periodic, Setup, Miscellaneous, and Tables.  The indirect access concept has disappeared. Access is set up on security keys, menu items, tables, fields, and form controls.
Record Level Security	 Did not exist.	 Record level security allows setup of data limitations for a certain combination of Company/User group/Table. It extends the User group permissions setup.
Forms’ setup	 Setup for the specific controls on a form, saved per User group and Domain.	 No longer exists as a separate form. Setting form control access is done from the User group permissions form per User group and Domain.
Table access	 A separate system to limit access to confidential tables and fields by overruling the feature keys.	 No longer exists as a separate system. Security is set up from the security tree, see Example on page 7.