Security followup

This is a consolidated post covering the main things that came up about security.  Again sorry for the delay on getting this out.  Also note the post has links to the pictures rather than in-place thumbnails.  I'll get them moved to a better home where I can reference them directly tomorrow.

I took away 4 main issues from the comments on the security model:

• What is “disabled mode” and how does it work?
• What are “safe macros” and why would anyone ever use them?
• How can I tailor my app’s UI to specific users without using User Level Security?
• How do ADP’s fit into the new security story?

Disabled Mode:

The Automation security property will still be honored and will continue to function the way it always did. This property as you already know is valid and useful in developer scenarios where Access is launched using startup scripts and applications.

Disabled mode and the Office Trust Center are designed to make it easier for a user to make trust decisions in scenarios where scripts that launch Access do not come into play.

There are scenarios, where developers of a solution want to ensure that code in Access (startup form/ macro or otherwise) always executes. In such cases the recommended approach is to ensure that one or more of the following conditions are met:

• The database is signed with a trusted certificate.
• The database is installed in a trusted location.

By meeting these conditions, the code within the solution will always be enabled. In scenarios where neither of these conditions can be guaranteed, Access can be made to revert to its legacy behavior of a modal startup trust prompt, that will launch and execute code in the database or not open the file at all. To revert to this legacy behavior set the following registry key:

          HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Access\Security\

Value: ModalTrustDecisionOnly = 1 (DWORD)

Safe Macros:

Safe Macros aren’t meant to replace code, and as noted there is no way all VBA in Access apps today could be replaced by macros.  However, they can still serve a very useful purpose, and there is an interesting set of applications that can be created with no VBA at all.  The Access team is building over 25 out of the box applications that use only macros.  By not using code, we can ensure that these apps are fully functional without signing and without being trusted – they can be mailed around and will work great.  In order to make that work, we’ve extended the macro language in some key areas and rethought about the way we build apps. 

Even applications that use VBA may still want to use macros for some functionality, like creating simple navigation that will still work when the application is running in disabled mode.  Examples include:

• Enable navigation and other safe actions that will be available to the user even in disabled mode.
• A combination of safe macros and code, provide an alternatives like an alert requesting the user to enable the database to unleash its full potential in disabled mode, where as using code to fulfill complex business logic requirements in enabled mode. For example: Let's say a button is supposed to execute an update query, which would be disabled if the database is not trusted, in this case using a macro that looks like the following can provide a usable experience:

{missing picture 1 is available at http://groups.msn.com/AccessBlogPics/shoebox.msnw?action=ShowPhoto&PhotoID=1}

Custom navigation using the navigation tools:

Access 12 developers will be able to customize the “navigation pane” (new nav metaphor, more on that very soon) to show users only those objects they need to see.  This is the key thing that Access developers did with the ULS, but done in the context of personalization rather than security. 

Let's consider a simple scenario where the database has the following objects:

Tables:

Issues

Contacts

Forms:

Contacts

Issues List

Issue Details

Reports:

Active Issues

Issues by Assigned To

Macros:

Autoexec

As the creator of the solution let's say I wanted to create the following navigation model:

• A set of my users see all the objects and are able to design them.
• A set of my users can see and use some forms and reports but not design them.
• A set of my users can only see and use the forms and reports based on Issues, not Contacts.

To go about doing this I can use the concepts of the navigation pane along with certain macros and even code.

The first step is for me to create the navigation pane categories and groups that would allow me to divide up these objects in a way that makes sense. Based on my requirements, I'd need three categories, with the following groups and object shortcuts: 

·         All Objects

·         Tables:

·         Issues

·         Contacts

·         Forms

·         Contacts

·         Issues List

·         Issue Details

·         Reports

·         Active Issues

·         Issues by Assigned To

·         Macros

·         Autoexec

·         Issues and Contacts

·         Forms

·         Contacts

·         Issues List

·         Reports

·         Active Issues

·         Issues by Assigned To

·         Issues

·         Forms

·         Issues List

·         Reports

·         Active Issues

·         Issues by Assigned To

For object shortcuts in the "Issues and Contacts" category and the "Issues" category, I'd disable design UI (using the shortcut properties option in the context menu for each shortcut). The property on the shortcut will disable all UI entry points into design for that object.

{{missing picture 2 is available at http://groups.msn.com/AccessBlogPics/shoebox.msnw?action=ShowPhoto&PhotoID=2}}

Now with my categories ready I can create the logic that sets the navigation pane category based on the user.  To identify the user I can use code to get the current windows user ID and map that ID to a given category or any other logic (like a custom login prompt) I prefer.

Let's say I'm using code to identify the user and assign him a category (in a function called GetUseCategory()), then the startup macro would look like:

{missing picture 3 is available at http://groups.msn.com/AccessBlogPics/shoebox.msnw?action=ShowPhoto&PhotoID=3}

A brief introduction to Navigation pane macros:

SetDisplayedCategories:

This macro allows the user to specify the categories displayed in the navigation pane. It takes two arguments:

Show (Yes/No): Specifies whether to hide or show specified category.

Category (Enum): Allows the user to specify an existing category. If blank macros operates on all categories.

LockNavigationPane:

This macro allows the user to lock the navigation pane, disabling any further customization via the UI. It takes one argument: Lock (Yes/No).

NavigateTo:

This macro allows the user to navigate to a specific category and sub group. It takes two arguments:

Category (Enum): Specifies the name of an existing category. If blank default to first available category.

Group (Enum): Specifies the name of the group within the category.

ADP’s and Access 12 Security:

The ADP architecture is conceptually unchanged between Access 2003 and Access12, which means that the features continue to work in essentially the same way they did.  We continue to believe that SQL Server makes a great store for Access data and that building the UI either through linked tables or ADPs will continue to work well.