Applications running in Enterprise Server for .NET can be affected in various ways by the identity of the user executing the application. APIs such as EXEC CICS SIGNON, the CESN system transaction, and the USER card in a JCL deck can establish the user's identity. EXEC CICS ASSIGN USERID and similar APIs can retrieve the user's identity.
User impersonation lets Enterprise Server for .NET run application code under the operating system account for the default or current user.
In a conventional Windows deployment, Enterprise Server for .NET uses the Windows operating system to authenticate users and supply the user tokens for impersonation. A Windows Azure deployment, however, may not have access to the same collection of Windows user accounts, since it runs in the Azure cloud rather than as part of your corporate network. There are various options for handling users in Windows Azure.
An Azure VM role is a self-contained Windows Server installation that you set up before deploying it to Azure. That means you can add required user accounts to the role during the setup process. You can automate this task using VBScript, PowerShell, or another scripting language.
Setting up users for Azure worker roles is more complex, because the Windows environment for these roles is created automatically by Azure. The worker role deployment solution can create users as part of its setup process.
The startup.cmd script supplied with the Enterprise Server for .NET Azure deployment solution creates a temporary user account using the Windows net user command as part of its processing. If you are only creating a few users, you could do something similar in your deployment process.
Other options include writing a program to create the necessary user accounts and having that run as part of role setup or even Enterprise Server for .NET region startup, and creating accounts manually in a Remote Desktop session connected to your worker role instance.
The Service Bus Logon Provider is an optional Enterprise Server for .NET component that changes how regions validate user credentials and perform other user-related tasks. By default, another logon provider component called the Windows Logon Provider handles those functions. The Service Bus Logon Provider lets an Enterprise Server for .NET Azure role instance check usernames and passwords by sending them to the seesvcbuslogon service running on another system, typically a system in your Windows domain. The Service Bus Logon Provider lets you avoid predefining Enterprise Server for .NET user accounts. Users simply sign on to regions using their normal Windows credentials.
The Service Bus Logon Provider does not support impersonation, so while it can validate usernames and passwords, it doesn't provide the run-time security of executing application code with the user's authority.
User impersonation is currently only available in Azure VM roles because it requires that the Event Monitor and SEP be running under the same OS instance. It also requires the Windows Logon Provider, as the Service Bus Logon Provider cannot create impersonation tokens.