Methodology for implementing Security in NAV

ben5000
ben5000 Member Posts: 110
edited 2012-04-18 in NAV/Navision Classic Client
Hi experts,

I need to implement security for a specific company but I've several questions I need to be answered before I begin.
This was first supposed to be a cleanup of the security roles. But it's such a mess that creating new roles from scratch was the best solution.

As for every project that turns arround security I need to find a good balance between Security, Flexibility and Maintainability.
So what are the different ways to approach security in NAV?

For example do you assign every user Read access on Table Data 0 and then use Form-security (access to Customer Card onlly for example) to limit user's possibilities?
Or do you prefer to grant access to all users to Forms and limit their access on table level?
Or do you prefer to do some trial/error to create highly secured roles but difficult to maintain?
Does it makes sense to grant Read/Write/Modify permissions on a CodeUnit or a Form? (should it be regarded as "Allow Read access through this form"? )

I've already searched accross the web and Mibuso abysses but the question never seems to be discussed.
Instead I find lots of topics that describe how to do this in practice (click Role -> permission -> add your permission etc...)
Or other topics to promote some tools that help to record new roles...

Could you share your experience about implementing security in NAV?

Thanks in advance,

Comments

  • Chinmoy
    Chinmoy Member Posts: 359
    Hi Ben,

    I have done this (in some of my implementations) in the way, like; providing the users (Roles) with access to the forms, sub-forms, etc. required (I mean interfaces) first and then configuring access for the underlying tables. In this way I was able to do the configurations in very little time. However, I am not very confident whether this is the right way to do this. But I must say that it was very effective for my projects.

    Let's wait for others to comment.

    Best regards,

    Chn
  • David_Singleton
    David_Singleton Member Posts: 5,479
    Every client is different and has different needs. For many customers, table level security is generally enough. Larger companies and especially SOX compliant must have form level. In addition sometimes the security is not flexible enough and you need to add code to implement some form of record level security.

    You also need to look at how Responsibility centers work.

    Also they returned the feature of globalfilters, so you can often implement some simple record level security using that.

    The SQL record level filters are totally unusable though, completely ignore them.

    The point is that you need to investigate the full needs of the client and design a system that suits their needs. Always the killer is when you have 99% of security designed and you find one or two users that have some exception to the norm that throws your whole design out the window.
    David Singleton
  • davmac1
    davmac1 Member Posts: 1,283
    Have you looked at the third party products?
    Mergetool has several security products for NAV and one of the editions is free.

    Since NAV does not have a deny capability in security, complex scenarios take a lot of work.
    David Machanick
    http://mibuso.com/blogs/davidmachanick/
  • ben5000
    ben5000 Member Posts: 110
    Hi all,

    Thanks for your quick replies :)

    Yes I need to implement security for a SOX compliant company so I'll have to consider table/form-level security.

    I'll investigate how Responsability Centers can help me to sharpen my implementation.
    If often use the "User Setup" table with custom code to limit access when permissions and menusuite are not sufficient.

    Implementing form/table security is relatively simple if you record roles with the code coverage tool. But the problems come when you need to allow posting or other "complex" operations. I tought that Code coverage tool would record those permission requirements but it's not always the case.
    Maybe is it caused by custom code for that specific implementation. Normally I expect such related permissions to be handled by Indirect accesses and Object-permissions.

    Regards,
  • ben5000
    ben5000 Member Posts: 110
    davmac1 wrote:
    Have you looked at the third party products?
    Mergetool has several security products for NAV and one of the editions is free.

    Since NAV does not have a deny capability in security, complex scenarios take a lot of work.


    Yeah I'm going to give a try to this addon which might be a good tool for creating and maintaining roles :)

Categories