How to Prevent the VBA Macro Security Warning (or) How to Install a digital signature for your Projects

Summary: Outlook frequently displays macro security warning messages when Outlook encounters VBA macros or VBScript. This tip describes the easiest way to prevent these messages from appearing.
IntroductionWith the release of Microsoft® Outlook® 2000, you can now write event procedures and macros in Outlook to customize its behavior and to automate tasks that you find tiresome. For example, by using Visual Basic® for Applications (VBA) in Outlook you can write a simple BeforeNavigate event procedure that opens a new explorer window when you click an Outlook Bar shortcut, instead of opening the target folder in the current explorer window. Then, to deal with the resulting desktop clutter, you can write a macro to minimize all those open Outlook windows!
Although native support for VBA in Outlook 2000 gives you an easy-to-use, yet powerful tool for tailoring Outlook 2000 to fit your personal needs, it does have one drawback: the macro security warning. If you write an event procedure or macro with VBA in Outlook, every time you start Outlook a warning message is displayed that reminds you of the hazards of running unknown code and gives you the option of enabling or disabling the macro code.
This security warning is the same as the one provided by other Microsoft Office applications when you try to open a document containing macros. This helps protect users from inadvertently running hidden code that could wreak havoc on their computers. Because documents are so portable (and seemingly benign), it makes sense to warn users if they contain potentially harmful program code.
Outlook also displays a similar warning message when a user opens a message that contains Visual Basic Scripting Edition (VBScript) code if the form associated with the message is not published in an appropriate forms library. Again, this is to protect users from unknowingly running program code that could damage their system.
Outlook macros are not as easily transported as Office documents or Outlook messages, however. There is no way to embed them in a file that can be sent to another user and executed automatically. However, it is possible to replace all existing Outlook macro code by replacing the Outlook VBA project file (VbaProject.otm). The macro warning message ensures that users do not unknowingly run macros contained in a project file that was replaced without their knowledge.
Preventing the Warning from Appearing
The easiest way to prevent the macros security warning from appearing is to change the Outlook macro security setting to Low. Although this is the easiest method, it is also an undesirable one because it leaves you vulnerable if your project file is replaced by one containing malevolent code.
Fortunately, there is a solution that is nearly as easy and that still alerts you that your project file was replaced by one from a source you don’t trust. You can add a digital signature to your VBA project in Outlook that marks the code as being “macro safe.”
The basic purpose of a digital signature is to authenticate the origin of a particular message or program. In the case of program code, a digital signature reassures a user that the creator of the program is who the creator claims to be and that the code has not been altered since it was signed. Before distributing ActiveX® controls on the Internet, for example, Microsoft attaches a digital signature to the control. This digital signature is authenticated by an independent authority so users who download the control can be sure that it was actually created by Microsoft and not by a malicious programmer pretending to be Microsoft.
You don’t have to obtain a digital signature from a security authority to digitally sign your VBA code in Outlook, however. Office 2000 includes a utility that creates a personal digital signature that you can use to mark your VBA macros as being safe for you to run. This will allow you to prevent the macro warning message from appearing unless your project file is replaced with one that is not signed or is signed by a source you don’t trust.
How to Use the Personal Digital Signature
There are three major steps to using a personal digital signature to sign your Outlook VBA projects:
1. Install Digital Signature for VBA Projects.
2. Create the digital certificate.
3. Sign the project by using the digital certificate.
The following sections describe these steps in detail.
Install Digital Signature for VBA Projects
By default, Digital Signature for VBA Projects is not installed with Office 2000, so you must install it yourself.
1. Close all programs.
2. Click the Windows Start button, point to Settings, and then click Control Panel.
3. Double-click the Add/Remove Programs icon.
4. Do one of the following:
· If you installed Outlook by using the Office Setup program, click Microsoft Office on the Install/Uninstall tab, and then click Add/Remove.
· If you installed Outlook individually, click Microsoft Outlook on the Install/Uninstall tab, and then click Add/Remove.
5. Click Add or Remove Features.
6. Click the plus symbol (+) next to Office Tools.
7. Click the icon next to Digital Signature for VBA Projects, and then click Run from My Computer.
8. Click Update Now.
Create the Digital CertificateInstalling Digital Signature for VBA Projects does not create the digital signature itself; rather, it installs an application program that you run to create the digital signature.
1. In Windows Explorer, locate and double-click Selfcert.exe. It is located in the Office program folder; by default, the path of this folder is C:\Program Files\Microsoft Office\Office.
2. In the Your name text box, type your name or some other identifying information, and then click OK.
Sign the Project
Once you have created the digital certificate, you can use it to sign your Outlook VBA project.
1. In the Visual Basic Editor, select the project you want to sign.
2. On the Tools menu, click Digital Signature.
3. Click Choose, and then select the digital certificate you created.
Note The first time you start Outlook after signing your project, Outlook will display a message informing you that the Outlook project (called ThisOutlookSession) contains macros written by you. To prevent this message from appearing again, select the Always trust macros from this source check box.
More About Digital SignaturesBecause a personal digital signature that you create yourself isn’t issued by a formal certification authority, VBA projects that are signed by using such a certificate are referred to as self-signed projects. Depending on how your organization uses the digital-signature features in Microsoft Office, you might be prevented from using such a certificate, and other users might not be able to run self-signed macros for security reasons.
Some organizations use tools such as Microsoft Certificate Server to produce or distribute digital certificates within the organization. If this applies to your organization, you might be able to sign your VBA projects by using a digital certificate from your organization’s internal certification authority. Even if your organization does not issue digital certificates for internal use, a network administrator or software development manager in your organization might control a digital signature that can be used to sign your project for you.You can also obtain a digital certificate from a commercial certification authority, such as VeriSign or Thawte Consulting. The digital certificates provided by these authorities provide the level of assurance required by commercial software publishers such as Microsoft.

For more information about digital signatures, you can visit these sites:
Microsoft Security Advisor (http://www.microsoft.com/security/)
VeriSign, Inc. (http://www.verisign.com/)
RSA Data Security (http://www.rsasecurity.com/)
You can also read about digital security and Microsoft Office in the Microsoft Office 2000/Visual Basic Programmer’s Guide published by Microsoft Press (1999).

How to preserve the user information in service context

This is follow up to my previous blog on things to watch out when developing application using SL3 + RIA. One issue I ran into during the testing is that the user information did not get persisted as I would have thought. One of the implementation suggested that, Use create the Authentication Service and then implement a singleton pattern to preserve the user once the validation user is successful. From there all the services can consume the singleton user. In my development everything worked great. I didn’t even think twice because each service request will run in its own application domain and so singleton will be a good solution. Well it turned out that my ‘assumption’ was wrong. It seems when two people access the same silver light page, the first user information gets the store and all following users end up using the first user identity and of course it is wrong.

To resolve that problem, I ended up removing the singleton user and started access the User information directly off of ServiceContext.User, but here is the catch. If you override the User information with your custom user and added some property to it, it is not available. But for starters, I have resolved the current problem and I will revisit to see why I can not user custom user I have created.

SL3 + RIA custom authentication

I have been playing with Custom Authentication lately and while trying out, I ran into bunch of problem. So I thought I will point out few of things you need to watch out. When you create a SL3 + RIA services, it automatically gives you Windows Authentication. When you need to change to custom authentication, couple of things you need to change and for that I would recommend Brad Abrams (ex-Microsoft) blog

If you are new to this area I would strongly recommend you to look at the authentication quick starts in the following URL, they are very simple and easy to follow.

http://code.msdn.microsoft.com/RiaServices

while you are at it, I would recommend visiting this Silverlight forum question to have an understanding of authentication as well.

Few things to watch out are

1. Make sure you have <authentication mode="Forms" /> in your web.config at the WCF service side.

2. The USER return from GetAuthenticatedUser has a catch, if you do not assign the name to the returning user, then by default IsAuthenticated flag will be false.

3. Make sure you have authentication setup to form authentication in silver light app.xaml.

<local:WebContext.Authentication>
                <appsvc:FormsAuthentication></appsvc:FormsAuthentication>
</local:WebContext.Authentication>

4. If you have a page where you are authenticating and then data binding, do not do data binding till you complete the validation. In other words, make sure you add the root visual element on login completed method delegate.

If you run into any other problems let me know or if you have any comments or suggestion also send me a mail.