Wednesday, January 16, 2008

Security Upgrade to GP 10 - Upgrade Security or Set Up Security from Scratch?

A recent discussion in the forums about upgrading security went like this -


Brad (Customer): Does anyone know if there is a tool or utility to convert Advanced Security in GP 8 to the new security model in GP 10. Lots of time and effort went into setting up security in 8 and would hate to redo it.

David (from Microsoft) : There is a security conversion tool which can be used during the upgrade of the DYNAMICS database.

Before you use the tool, you should be aware of how it works and what the consequences of using the tool are.

In the new model, each user can be assigned multiple security roles. Each role is made up of tasks and each task is made up of operations. Operations are the actual access permissions as shown in v8 Security (Standard or Advanced).

When you use the conversion tool, it will create a new security task and matching security role for each user/company combination.

While this will provide the same access you had in v8, it will not leverage the role based model at all. Also, maintenance would need to be handled on a individual user/company combination as there are no classes or multi-selection in v10.0.

My personal opinion is to promote this as a perfect opportunity to redo security using the new more powerful and flexible role based pessimistic model.

Brad (Customer) : Thank you very much for your answer, I understand the added granularity that the new security model allows, unfortunately our Sarbanes auditors aren't as flexible.

Now I totally understand what Brad is saying - It takes a lot of time and effort to set up Security. Making sure each user has access to what they are required to do, not more, not less - is work. And if you have something working - you generally don't want to break it.

At the same time I can understand David's pain - The security architecture in GP 10 is miles ahead of the security in GP8/9. Its in a different generation altogether! And as he points out correctly - in the longer run - it would be difficult to maintain the upgraded security. Maintaining GP 10 Tasks and Roles are much more easy.

I guess there is no simple answer to this. What I decided to do was - to do some tests and show how security upgrades. Perhaps, that would probably make it a little easier for people to make a decision.

If you have any inputs or suggestions, do let me know.

Security in GP 9

I created a test company in GP 9 and added 6 users in it.

1. I created 3 classes.

2. I assigned 3 users - to a class "AP Clerk".

3. One user was given a class - "Accounting Manager".

4. The two remaining users - were not given a class - I set up security for them independently

Users Created in GP 9

How the Security upgraded to GP 10

In GP 10

1. Each Class was translated to a task.

2. Each "User/Company" Security permissions was translated to a Role. This role - had one task - which in turn had the permissions.

3. All Users were assigned their own individual "User/Company" Role. None of the users was assigned to the common class.

A Task was made for each Class

A Task was made for each User/Company Combination The User was given access to the new Role specific to that User A Task Broken down into Operations

A Alternate Modified Reports ID was made for each User and Class.

Maintenance Problems - When you use Upgraded Security

Having a Role for each User, is a maintenance nightmare. You would have to make a change in 50 places for 50 users.

If you have to make a change to the class "AP Clerk" - that is not possible immediately. You would have to

a) Make a role which maps to each task created from a GP 9 class

b) Assign all the three users access to the new role.

Now when you make a change to that role, all users would pick it up.

This looks kind of ugly, because each Role just has one task, which as the permissions. In a way the Role is just a pseudo role. It sits there as a proxy, looking at what's going on feeling useless about its existence.

However, it's the best that can probably be done in migrating to a completely new architecture.

Now if you were to set up the same security in GP 10. Here's how you would probably do it. You would create a role AP Clerk, and all relevant users would be assigned that role. You would have relevant tasks in that role. Then, when you make a change in the role - all users would pick up the change.

Additionally you could use Tasks to further break down your security architecture. Roles, Tasks and Operations in GP 10 offer a far greater potential to plan security in comparison to Classes and Operations in GP 9.

Knowing what's possible with GP 10 security - I would feel uneasy, in just migrating security and using it the way it migrated. Everything would probably work - but it is just not the way it is supposed to work.

1 comment:

Anonymous said...
This comment has been removed by a blog administrator.