Listing Subscriptions and Logic Apps from .NET

string TokenAudience = “https://management.core.windows.net/” ;

string ClientRedirectUri = “urn:ietf:wg:oauth:2.0:oob” ;

string ClientId = “1950a258-227b-4e31-a9cf-717495945fc2” ;

string EnableMagicCookie = “site_id=501358&display=popup” ;

string BaseLoginUrl = “https://login.windows.net/{0}” ;

string TenantId = “common” ;

AuthenticationResult result = null ;

AuthenticationContext authenticationContext
= new AuthenticationContext ( string .Format(BaseLoginUrl,
TenantId), true , TokenCache .DefaultShared);

try

{

result = authenticationContext.AcquireToken(

TokenAudience,

ClientId,

new Uri (ClientRedirectUri),

PromptBehavior .RefreshSession,

UserIdentifier .AnyUser,

EnableMagicCookie);

}

catch ( AdalException )

{

result = null ;

}

return result;

CancellationToken canToken = new CancellationToken ();

TokenCloudCredentials cred = new TokenCloudCredentials (commonTenantCredentials.AccessToken);

SubscriptionClient client = CloudContext .Clients.CreateSubscriptionClient(cred);

SubscriptionListOperationResponse response
= await client.Subscriptions.ListAsync(canToken);

// Project subscriptions into a list of SubscriptionWrapper
instances

List SubscriptionWrapper >
subscriptions = response.Subscriptions.Select

(

sub =>

new SubscriptionWrapper (sub)

).ToList();

using ( LogicManagementClient client
= new LogicManagementClient (

new TokenCredentials (credentials.AccessToken)))

{

client.SubscriptionId = subscription.SubscriptionId;

Page Workflow >
workflowPage = client.Workflows.ListBySubscription();

List Workflow >
workflows = workflowPage.ToList();

}

string LogoutUrlBase = “https://login.windows.net/{0}/oauth2/logout” ;

authenticationContext.TokenCache.Clear();

new WebClient ().OpenRead( string .Format(LogoutUrlBase, “common” ));

NativeMethods .InternetSetOption( IntPtr .Zero, NativeMethods .INTERNET_OPTION_END_BROWSER_SESSION, IntPtr .Zero,
0);

private static class NativeMethods

{

internal const int INTERNET_OPTION_END_BROWSER_SESSION
= 42;

[ DllImport ( “wininet.dll” ,
SetLastError = true )]

internal static extern bool InternetSetOption( IntPtr hInternet, int dwOption, IntPtr lpBuffer,

int lpdwBufferLength);

}

Sidebar

Here’s some useful information that should help you understand how
all of this works under the covers.

What “logging into Azure” means

When you log into Azure, you’re logging into Azure Active Directory
(AAD) – either one you host (in your subscription) or a common one (e.g. O365).

Technically, you’re using an AAD Tenant: A tenant is an instance
of Azure Active Directory just for your organisation (basically the same meaning when
we talk about tenants in multi-threaded
programming): when you create an O365 Enterprise subscription you get assigned a tenant,
as you do when you create an Azure subscription [I’m simplifying this a great deal,
as it’s really a rather complex subject – see this post here https://msdn.microsoft.com/en-us/library/azure/jj573650.aspx ,
or see Vittorio’s post here ,
or Brady’s post here for
more detail).

When you create a personal Azure Subscription, an AAD tenant is created
for you, and within that AAD is a default directory – that’s right, it’s an Azure
Active Directory Directory!

The default directory will use a name related to your Microsoft Account
Name e.g. if your Microsoft Account is dan@acme.com, your default directory will be danacmecom.onmicrosoft.com .

You can create multiple AAD Directories from within the management
portal – an AAD Directory doesn’t belong to any subscription.

A subscription can only use one directory at a time – you can see
what directory is being used by going to the Settings view in the old portal.

Note : if you have an Enterprise O365
account, you can link the AAD tenant for your O365 account to your Azure subscription,
and then tell that subscription to use the O365 directory for authentication – which
means your corporate users can log in to the Azure subscription.

Because we’re using the management libraries, we’re using the OAuth
2.0 protocol for logging in – which means that when we successfully,
authenticate, we’re given a Bearer token
in JWT form (pronounced “jot”), which is stored in a cookie locally against the id
of the client we authenticated against.

A JWT (JSON Web Token – see here for
more info, and for a decoder: http://jwt.io/ )
is a string comprised of three Base64 encoded sections, separated by full stops/period
(.). You can decode these section to see what they contain – the important bits are
who has been authenticated, and when the JWT expires.

When we authenticate (using the Azure login window) we’re passed
one of these Bearer tokens, and we have to then transform it into a Credentials object
for use by the Management libraries.

Note that if you were using the REST interface (which is what the
Management libraries use underneath) you’d be passing the Bearer token in the HTTP
header for each request.

Two types of Azure Account

There are currently two types of Azure account:

• Microsoft Accounts – these are the old
  Hotmail/Passport/Windows Live ID accounts. They’re a personal account, and they’re
  to be used to login to consumer-based Microsoft services e.g. Outlook.com, personal
  O365 subscriptions, Xbox Live etc. They’re also the default way of creating Azure
  subscriptions (until recently, you had to use a Microsoft
  Account to create an Azure Subscription, or as the Account
  Administrator). They’re denoted by the Microsoft four-colour flag icon.
• Organisational Accounts (aka work or
  school accounts) – these are corporate/enterprise accounts, used to log into Enterprise
  services e.g. 0365 under an Enterprise License. They use the domain of your organisation,
  and you can sync these accounts with an on-premise AD server. They’re denoted by an
  icon that looks like a corporate photo id on a lanyard (see more here: https://azure.microsoft.com/en-gb/documentation/articles/sign-up-organization/ ).

Why is this important? Azure needs to know what type of account you
have, so it can work out which AAD Tenant to authenticate you against.

When you attempt to login to an Azure resource e.g. the management
portal, you’ll sometimes see this screen:

(it used to have a password box under it, and when you tabbed out
of the email address box, it would start doing something, but recently they’ve started
phasing out that version and started using the version above).

The reason this screen exists is to allow Azure to work out if you
have an Org Account or a Microsoft
Account – you’re then directed to the appropriate login screen: Org
Accounts can customise their login screen.

If you happen to have an Org Account and
a Microsoft Account with the
same name, then you’ll see this screen next:

This is Azure’s way of saying that it can’t work out which of the
two accounts you wish to use.

Some services only allow you to use a Microsoft
Account to login – this will be obvious on the login screen:

The bane of those with multiple accounts: Auto Logon

One thing that those people with multiple Azure accounts (both Microsoft
Accounts and Org Accounts )
hate with a passion (well, I do!!) is auto logon: you go a secured resource (e.g.
Azure Portal), click the Sign In button
(or just type in the page URL), and instead of being asked which account you want
to use, you’re just logged in with what seems like a random account.

Why does this happen? It’s to do with how Azure AD has grown over
time, and how something that is designed to make life easier for people with single
accounts tends to make it more complex for those with multiple accounts.

Firstly, there’s the “Keep me signed in” feature: if you see this
checkbox on a login screen, and tick it, a cookie is created locally which stores
your authentication token.

Next time you go access a secured resource or click the SignIn button,
as long as the authentication token is still valid, then you’re automatically logged
in using that account.

But… if you then login using another account, and *don’t* tick the
same option, and then close your browser, and then try and login again, instead of
logging you in with the previously used account, you’re logged in with the original
account (i.e. the one you ticked the option for).

It gets more complex when you realise that whilst only a single Microsoft
Account can be marked for auto-login at a single time, multiple
Corporate Accounts can be marked for auto-login at the same time.

I mention this because when it comes to logging in from code, you
can actually control this functionality and (hopefully) give your end user a more
pleasant login experience.

How to login to Azure if you don’t know the tenant

With all the discussion above, it may not be obvious on how to login
to Azure if you don’t know which AAD Tenant to authenticate against.

The solution is that Azure provides for the concept of a common tenant:
the common tenant indicates that you don’t know which tenant should be used (and you
don’t actually care): Azure will log you in against the relevant tenant for the user
signing in. After the user has logged in, you can get the tenant details (should you
need them).

Prompt Behavior

In Step 1, where we login, note the use of a variable called promptBehavior :
this lets us control whether or not we wish to see the login window if we’re already
logged in.

This value is an enum called PromptBehavior ,
and has the following values and meanings:

In our case, we want to use RefreshSession when
we first login (in case we have a token that can be reused) but want to set it to
Always when we Log off (so that we’re prompted to login next time we login). There
are some flaws in this plan: since we’re using the PowerShell client ID, if you logged
into PowerShell recently, and chosen the “keep me logged in” option, then when you
run this tool, you’ll be auto logged in as the user you logged in to PowerShell with.
The only way around this (that I know of at the moment) is to use a different client
id.