Diary of a .NET programmer

Machine to machine authorization in Azure AD

Fri, 14 Apr 2017 15:23:00 +0000

This is the last post in the series about Azure Active Directory authentication and authorization. To see previous posts, navigate to the following links:

Business case

In this post I will cover how to protect access to Web API with bearer tokens, using Azure Active Directory. The business case is as follows:

My core business app gathers users data in a very structured way. It is being used by Organizations, that create Forms for their users to fill, and each filled and completed Form becomes a Submission.
My API is a reporting service, serving data in a way that follows the structure outlined above.

[HttpGet]
[Route("api/v1/{organization}/{form}")]
public AppResponse Get(string organization, string form, [FromUri]string dateFrom)

I need to be able to grant access to my API to various third party services for their integration purposes. Security must be quite granular, I need to be able to grant access to all submissions of the form, all form submissions in a given organization or to all data.

So for example, there can be an app which should be able to query:

GET http://foo.com/api/v1/awesomecorp/registration?dateFrom=2017-01-01

but should fail with 403 when accessing

GET http://foo.com/api/v1/awesomecorp/supersurvey?dateFrom=2017-02-02

Azure setup

As usual, I need Azure AD app configuration for my API. Next, edit application manifest and add some roles. This time they will be Application roles as opposed to User roles which we added in previous post in the series.

{
  "appId": "067f5d6c-a79f-4430-bb82-00aa060432b1",
  "appRoles": [
    {
      "allowedMemberTypes": [
        "Application"
      ],
      "description": "Allow the application to access ALL APIs",
      "displayName": "Access ALL APIs",
      "id": "0c65e07c-9d03-4617-83d5-09adae44c5e3",
      "isEnabled": true,
      "value": "/api/v1"
    },
    {
      "allowedMemberTypes": [
        "Application"
      ],
      "description": "Allow the application to access Supercorp's Registration",
      "displayName": "Access Supercorp's Registration",
      "id": "0c65e07c-9d03-4617-83d3-09adae44c4e2",
      "isEnabled": true,
      "value": "/api/v1/awesomecorp/registration"
    }
}

Notice allowedMemberTypes being set to Application and the value of the role. Next, we design an onboarding process. Each partner that wants access to our API needs to have Azure AD application created. In newly create app in azure portal, go to CONFIGURE and click big green Add application button in the bottom. Search for Azure app that represents your API and click plus sign in the grid next to it.

Back in main settings panel, in permissions to other applications section at the bottom, you will have a new row representing our API, with all Application Permissions it provides. Select proper items from the list and save.

API code adjustments

First, API needs to be instructed where to expect incoming Auth data and how to ensure they aren’t spoofed. The following code in Startup.js is required:

public void Configuration(IAppBuilder app)
{
    app.UseWindowsAzureActiveDirectoryBearerAuthentication(
     new WindowsAzureActiveDirectoryBearerAuthenticationOptions
     {
         TokenValidationParameters = new System.IdentityModel.Tokens.TokenValidationParameters
         {
             ValidAudience = ConfigurationManager.AppSettings["ida:Audience"]
         },
         Tenant = ConfigurationManager.AppSettings["ida:Tenant"]
     });
}     

ida:Audience is APP ID URI setting configured in Azure portal and it ensures that the token is meant for our API. ida:Tenant is what we’ve had in all previous code examples.

Then it all comes down to analyzing roles embedded within the incoming request token. If requested API route starts with some role value then request is authorized to proceed.

public class AuthorizeApiAzureAttribute : AuthorizeAttribute
{
    protected override void HandleUnauthorizedRequest(HttpActionContext actionContext)
    { /* omitted for clarity */ }

    protected override bool IsAuthorized(HttpActionContext actionContext)
    {
        var claims = ClaimsPrincipal.Current.FindAll(c => c.Type == ClaimTypes.Role || c.Type == "roles");
        if (claims == null || !claims.Any())
        {
            return false;
        }

        List<string> roleValues = claims.Select(c => c.Value).ToList();
        var url = actionContext.Request.RequestUri;
        return IsAuthorizedInternal(url, roleValues);
    }

    protected static bool IsAuthorizedInternal(Uri url, List<string> roleValues)
    {
        string path = String.Format(@"{0}{1}{2}{3}", url.Scheme, Uri.SchemeDelimiter, url.Authority, url.AbsolutePath);
        string apiPath = path.Substring(path.IndexOf(@"/api"));
        return roleValues.Any(rv => apiPath.StartsWith(rv, StringComparison.InvariantCultureIgnoreCase));
    }
}

What about client code?

Please note that partner’s clients are not bound to CSharp or .NET in general. It is cross-platform standard, so all they need to do is to obtain a token from azure using their ClientId and Secret and use this token with an API request. The following code should be very easy to port to other programming languages:

var httpClient = new HttpClient();
var tokenRequestMessage = new HttpRequestMessage(HttpMethod.Post, TokenEndpointUrl);
HttpContent tokenRequestMsg = new FormUrlEncodedContent(new[]
{
    new KeyValuePair<string, string>("grant_type", "client_credentials"),
    new KeyValuePair<string, string>("client_id", clientId),
    new KeyValuePair<string, string>("client_secret", secret),
    new KeyValuePair<string, string>("resource", resource)
});
tokenRequestMessage.Content = tokenRequestMsg;

var tokenResponse = httpClient.SendAsync(tokenRequestMessage).Result;
string rawTokenResponse = tokenResponse.Content.ReadAsStringAsync().Result;
TokenRequestResponse deserializedTokenResponse = JsonConvert.DeserializeObject<TokenRequestResponse>(rawTokenResponse);

var apiClient = new HttpClient();
apiClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", deserializedTokenResponse.access_token);
var apiResponse = apiClient.GetAsync("http://foo.com/api/v1/xml/awesomecorp/registration?dateFrom=2017-01-01").Result;
string content = apiResponse.Content.ReadAsStringAsync().Result;

In the code above, clientId and secret are as set in client’s app in Azure Portal and resource matches ida:Audience in API.

Azure AD Authorization

Sun, 05 Mar 2017 18:30:00 +0000

In the third part of this Azure AD series I will cover various features that can be utilized to implement authorization in your application. You can find previous posts here and here.

Azure supports groups and roles which are easilly transformable to ASP.NET Identity claims. If there are very refined rules driving your authorization, you can utilize Azure Graph API to get access to almost any data in directory’s possession in order to make your security desisions.

Groups in B2E

Groups are top level active directory objects, that can contain any number of users. Groups in B2E can also be nested, which unfortunately is not the case for B2C. Nesting groups can lead to some issues when using Graph API to check membership. Some Graph API calls are transitive and some or not, so asking about assignment to a group high in the tree hierarchy can give different results based on the api call of choice.

You can manage groups and user assignments in both legacy and new portals or using Graph API. In order to have groups automatically set as claims for ASP.NET identity, you need to flip the switch in application manifest file, because group claims are not being returned by default. Go to application settings in legacy Azure portal, select Manage Manifest, download file, find groupMembershipClaims and change null value to SecurityGroup. The other permitted value is All but this will return all user’s distribution lists, which for some users, in some corporations, can easilly excess the limit, which for JWT token is set to 200. As a side note: in new portal, you can just edit manifest in the browser, which is kind of nice.

If all goes well, ASP.NET Identity will contain claims with IDs of all groups user is assigned to:

Groups in B2C

This is all good and fine in B2E scenarios. B2C will not return groups in payload, no matter what configuration voodoo we will do. Graph API is a way to go and fortunatelly is not that hard to play with.

To query B2C Active Directory using Graph API you need a special service application, other than the one you are currently working with. Set of powershell commands required to create this azure app is described in detail in MSDN documentation. Once you have that, the following code will get the list of IDs of all groups user is assigned to:

var credential = new ClientCredential(clientId, clientSecret);
AuthenticationResult result = await authContext.AcquireTokenAsync("https://graph.windows.net/", credential);

string userObjectId = ctx.Identity.FindFirst("http://schemas.microsoft.com/identity/claims/objectidentifier").Value;
string api = "/users/" + objectId + "/getMemberGroups";
string url = "https://graph.windows.net/" + tenant + api + "?api-version=1.6";
var request = new HttpRequestMessage(HttpMethod.Post, url);
request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", result.AccessToken);
request.Content = new StringContent("{securityEnabledOnly: false}", Encoding.UTF8, "application/json");

var http = new HttpClient();
var response = await http.SendAsync(request);
return await response.Content.ReadAsStringAsync();

The above code requires some explanation. The goal is to make a POST request to Graph getMemberGroups operation, parametrized with user’s objectId - user’s unique identifier in AD. Call is protected with Bearer token, which needs to be provided in authentication header of the request. Token is obtained from Azure with use of this special credential set I mentioned in a previous paragraph. Notice also a securityEnabledOnly parameter provided in request body which is rough equivalent of groupMembershipClaims setting from json app manifest.

Please also note that you may not find objectidentifier claim on your user’s identity. It depends on B2C policy settings, so head out to new portal, navigate to Policies -> policy name -> Edit -> Application claims, and select User’s Object ID, see below:

Roles

There are some predefined global user roles in azure, like Global Admin or User, which you can see by going to role section in user profile tab in legacy portal. You can also define your custom roles per application scope. Roles setup is, again, tedious json edit in application manifest file. Go to your application download and edit manifest and add the following snippet in the empty roles section (adjust to your needs):

{
    "appRoles": [
    {
      "allowedMemberTypes": [
        "User"
      ],
      "displayName": "Reader",
      "id": "d2c2ade8-98f8-45fd-aa4a-6d06b947c64f",
      "isEnabled": true,
      "description": "Readers Have the ability to create tasks.",
      "value": "Reader"
    },
    {
      "allowedMemberTypes": [
        "User"
      ],
      "displayName": "Writer",
      "id": "d2c2ade8-98f8-45fd-aa4a-6d06b947c65f",
      "isEnabled": true,
      "description": "Writers Have the ability to create tasks.",
      "value": "Writer"
    }
  ]
}

You can set user in role while assigning him to an app. In legacy portal go to application, click users tab, select user and click ASSIGN button in the bottom. The roles dropdown should appear automatically. Remember that if you have only one role for your app, you will not be presented with any choice and assigned users will automaticaly have this role assigned. Roles will automatically be translated to claims in ASP.NET Identity.

I haven’t found a way to assign user to a role in new portal.

M2M

That’s it for user’s authorization in azure B2E and B2C. In the next part of the series I’ll cover machine to machine authorization scenarios and topics like:

necessary manifest changes
setting permissions in Azure portal
working with Bearer tokens in C#

Authentication in Azure AD B2C

Sun, 05 Feb 2017 23:24:00 +0000

The tale of two portals

In the previous part of this series we learned how to incorporate simple authentication with Azure AD (B2E) into vanilla ASP.NET MVC App. As a prerequisite, we had to create a bunch of entities in Azure Portal (https://manage.windowsazure.com). In this blog post I will show how to achieve a similar thing but with Business to Consumer (B2C) flavour of Azure Active Directory and we will learn what are some additional benefits of using B2C.

This is also a moment where new Azure portal needs to be introduced: https://portal.windowsazure.com. There are several entry points to this new management tool, one of them is a banner that will bug you to “Check out the new portal” in classic Azure portal: https://manage.windowsazure.com. Please note that if you want to play with B2C you must use the new portal because classic one is simply unaware of most B2C features and configuration options.

B2C is a different type of Azure Active Directory and you decide if a given AD will be B2C while creating it. In legacy portal click NEW, App Services, Active Directory, Directory, Custom Create. In Add Directory dialog remember to select This is a B2C directory checkbox. Interestingly enough, you cannot add a B2C AD from withing new portal because at the time writing this (22/1/2017) Microsoft did not finish adding support for that in new portal. Things essential to B2C AD configuration are supported though and not available in legacy portal. You just can’t create a directory here. Madness!

So, once you create a B2C directory from withing legacy portal, you can use new portal’s UI to create app and user in your newly created directory. This process is pretty much the same as for B2E, so I will not cover the details here. Once setup is done, you need Client Id and Tenant to replace values in a configuration in our B2E example and sign in process should work the same. Remember to use an account from B2E directory!

B2E Policies

We’ve got to the point where we’re stuck again with a pre-defined set of users, no sign-up, no federation with other identity providers, nothing fancy. But this is where it gets interesting. We need to create and incorporate a policy. Head to the old portal, navigate to a landing page for your B2C directory and click Manage B2C settings link. It will redirect you to the new portal (told’ya - madness!) and open AZURE AD B2C SETTINGS section automatically. Let’s see how we can set up our application with an onboarding process for users from internet.

Go to Sign up or sign-up policies, click Add, give it a name (I named it blog_policy so the full name will be B2C_1_blog_policy) and in Identity providers section select Email signup. It is the only build-in azure sign up policy which also has an advantage of not having any additional configuration. For users it will be as simple as it can be - their new accounts will be associated with their emails, they will have to create a password and it will essentially create a new account in our B2C directory.

You might also want to add Display Name Sign-up attribute and Application claim to your policy. It will another field on the registration form generated by Azure, which will correspond to proper Claim in OpenIdConnect payload returned after Sign-in.

You can test the process orchestrated by this policy by selecting it on the list of Sign-up or sign in policies and choosing Run now.

Notice that Run now button navigates to the following URL:

https://login.microsoftonline.com/aisappengine.onmicrosoft.com/oauth2/authorize?p=B2C_1_blog_policy&client_Id=09866094-b889-46f4-8903-1e66799518df&nonce=defaultNonce&redirect_uri=http%3A%2F%2Flocalhost%3A44404%2F&scope=openid&response_type=id_token&prompt=login

It is pretty much the same as a redirect URL in B2E scenario but there’s a p (as in policy) query string parameter which is triggering proper behavior on Azure side. Our whole programming task right now is to convince MVC to include proper policy name when automatically redirecting to Azure when it encounters Authorize attribute.

Give me the code

First we need to update a package listed below, because it doesn’t play nicely with B2E for some reason.

Update-package Microsoft.IdentityModel.Protocol.Extensions

Next, our OpenIdConnectAuthenticationOptions object needs to be adjusted a bit in comparison to the one we’ve had previously for B2E.

string policy = "B2C_1_Blog_SignIn_SignUp";
app.UseOpenIdConnectAuthentication(
    new OpenIdConnectAuthenticationOptions
    {
        ClientId = WebConfigurationManager.AppSettings["ida:ClientId"],
        MetadataAddress = string.Format(
            "https://login.microsoftonline.com/{0}/v2.0/.well-known/openid-configuration?p={1}",
            WebConfigurationManager.AppSettings["ida:Tenant"],
            policy),
        RedirectUri = "http://localhost:44404/"
    });

MetadataAddress = is the line responsible of understanding p parameter. If you remember from the previous post, by default middleware automatically looks for a openid contract at the location as configured in azure:

With MetadataAddress = we give a hint to the middleware where new, policy-aware configurations are being hosted. Some articles and blog posts on the topic also advise to set Scope+ and _Response properties which drive the OpenidConnect/OAuth2 flows to openid and id_token, which by default are openid+profile and code+id_token respectively.

With the changes listed above applied, you should be able to run the app, be redirected to azure login page that allows user registration via email. After quick registration process (that requires email validation via email sent by azure) your brand new account will be created and after successful authentication you’ll be greeted as previously… or not.

As you can see in the snippet below, we get all the data we need, MVC just can’t understand which payload part is user identifier:

We can help it with the following addition to OpenIdConnectAuthenticationOptions:

TokenValidationParameters = new TokenValidationParameters
{
    NameClaimType = "name"
}

Expanding

With this code in place, app will greet each user correctly, but now users can register in the app by themselves and this process is totally outsourced to Azure AD. How cool is that? Other cool thing is enabling other identity providers. Instead of using email signup, users will be able to use their existing facebook, google or linkedin accounts, and again - entire process is outsourced to Azure.

Having authentication in place, is many scenarios it’ll be time to start authorizing user access to various resources in your application, which will be covered in the next part of the series.

Deep dive into Azure AD Authentication

Fri, 30 Dec 2016 22:03:00 +0000

Azure AD introduction

This is the first post in a series about Azure Active Directory. I want to cover the following topics:

Authentication in Azure Active Directory (Business to Enterprise)
Authentication in Azure AD B2C (Business to Consumer)
Authorization with Azure AD
Working with Azure AD using Graph API

Azure Active Directory (in this post I am referring to old Business to Enterprise type) is a cloud service that puts a synchronized mirror of On-Premise Active Directory in Azure Cloud and provides some neat APIs to work with it. On of the main reasons why Azure AD came to existence was to provide an easy licensing model for Office and other Enterprise tools in the cloud. The logic goes like that: enterprises use Office, enterprises also use Active Directory (On-Premise). Office 365 lives in a cloud, so let’s move AD to the cloud, so enterprise can use their AD accounts for Office.

What’s in that for us - developers? With AD we have a reliable and up-to-date user store which, with Azure boost, can be used for internet apps without any additional infrastructure. There are pretty good chances that if a company uses Office 365, you’re almost set to get all the goodies from Azure AD. Moreover MSDN subscription licenses also have Azure for developers to play with and Azure AD is just one of services that can be used with that subscription. This is exactly what I’ll be using in my demo.

Azure AD basic concepts and portal overview

Let’s see how we can implement a simple authentication in ASP.NET MVC internet application. First, let’s have a look at some basic concepts in Azure AD:

azure application - it is a handler for your actual app in azure. It is an entity which holds information on how your web application interacts with azure, how azure should interact with your app and many other configuration parameters. Internally represented by Client Id
Client Id is a GUID which uniquely identifies Azure app
Tenant is a… tenant. Think of it a specific instance of AD (in case I described above - the synced On-Premise one) in Azure Active Directory service. It is represented by a name, but more importantly, it has a default domain, which was configured while creating a tenant, and will be used in our web app configuration.
Open ID Connect - Authentication protocol, built on top of OAuth2, used in Azure AD authentication scenarios.

Now we’ll actually build stuff. Starting in Azure portal, we need to create an application and obtain some basic configuration parameters for our ASP.NET MVC app.

In Azure portal go to Active Directory, Default Directory, Application tab.
Click Add at the bottom.
Click Add an application my organization is developing. It means that you have a new web application that you want to integrate with Azure. There are already tons of other federated services that can be protected with Azure AD and the list is under Gallery link in that dialog window.
In the next step, provide the descriptive name. Choose Web application and/or web API option. Native client application option is useful in different scenarios. The main difference is underlying OAuth2 flow.
Provide Sign-On URL and App ID URI. Sign-On URL setting will be used in default application configuration as a reply to URL. App ID URI is like a namespace of your app. In most cases any unique URI will be just fine. The URI must be in a verified custom domain for an external user to grant your app access to their data in Microsoft Azure AD, but we will not use this app in app-to-app resource authorization scenario.
When you’re done with the wizard, you will see azure app summary screen, where most of settings can be changed or adjusted and where you can see Client ID for your app.

Programming Azure AD APIs

Right, we’re done on Azure Portal side, now switch to the code.

Create an empty MVC app in Visual Studio and install the following Nuget packages:

Install-Package Microsoft.Owin.Security.OpenIdConnect
Install-Package Microsoft.Owin.Security.Cookies
Install-Package Microsoft.Owin.Host.Systemweb

First two packages are directly related to Azure, third package will allow you to wire it all up in Startup.cs.

You need to have Azure app Reply Url in sync with URL where you actually host your app. After successful user authentication in Azure Portal, Azure will redirect back to the given Reply Url. So if you create your sample app in Visual Studio and host it in IIS Express, make sure your localhost:port URL will be present in Azure app config.

Now head to Startup.cs class and add the following lines:

public void Configuration(IAppBuilder app)
{
    // ...
    ConfigureAuth(app);
}

private void ConfigureAuth(IAppBuilder app)
{
    app.UseCookieAuthentication(new CookieAuthenticationOptions());
    string authorityUrl = string.Format("https://login.microsoftonline.com/{0}", WebConfigurationManager.AppSettings["ida:Tenant"]);
    app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
        {
            Authority = authorityUrl,
            ClientId = WebConfigurationManager.AppSettings["ida:ClientId"]
        });
    app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
}

There are couple of things that need explanation. First, app.UseCookieAuthentication() line says that we will have cookie based auth session. Important thing is that this middleware needs to be higher in a pipeline than OpenIdConnect middleware. OpenIdConnect doesn’t have any session persistence on its own, so even if Azure authentication would work, without proper cookie management on application side, user still would look like anonymous and we would get infinite redirect loop. Second, we configure some core settings for OpenIdConnect. Authority URL is where all metadata manifests, sign-on/sign-out endpoints are, all that protocol good stuff. OpenIdConnect library needs only the root URL, it will figure out the rest automatically. If you’re interested what are all these URLs related to your app, you can see them in azure portal. Go to your app definition in Azure portal and click View Endpoints button in the bottom.

There are multiple ways of building authority URLs. As you can see Azure portals builds them with guid/object id convention. The same result can be achieved by using tenant domain identifier as in the code. It’s just easier to obtain, clearly visible in azure portal. So because my tenant piotrais.onmicrosoft.com object id is 96a4c14c-38d2-481b-931e-59502b6a22a1, the following authority URLs are in fact pointing to the same thing:

https://login.microsoftonline.com/96a4c14c-38d2-481b-931e-59502b6a22a1/
https://login.microsoftonline.com/piotrais.onmicrosoft.com/

There is a third convention for building authority URLs, for multi-tenant apps it is always https://login.microsoftonline.com/common/.

Enough explanation! We’re done! Now putting [Authorize] attribute on a HomeController class will make it a protected asset, where anonymous users don’t have access. Moreover, it will automatically trigger a redirect to Azure login page where user will be able to sign in. Azure will also take care of redirecting back to our app and OpenIdConnect middleware we just configured in Startup.cs will consume incoming payload, set proper cookies and identity.

So running the following code and signing in as demo@piotrais.onmicrosoft.com

[Authorize]
public class HomeController : Controller
{
    public ActionResult Index()
    {
        return Content(string.Format("Hello {0}", User.Identity.Name));
    }
}

will give the following result: Hello demo@piotrais.onmicrosoft.com

A word about users and summary

Speaking about users… Where do we get users for sign in? In enterprise scenarios there will be plenty of users from synced On-Premise AD. In development scenario, we need to create a user in Azure portal. In your Default Directory go to Users tab, click Add User button at the bottom, provide a user name and you’re done. This is useful for testing scenarios but I can also imagine an app with small, constant number of users or an app with admistrative module, where this authentication/authorization scheme would be just enough.

Azure AD also supports user onboarding process with some self-service and even federation to popular identity providers like google, facebook or twitter. It is Azure AD B2E younger sibling called Azure AD Business to Consumer (B2C). I will cover this topic in the next part of this series.

Aggregate string concatenation in TSQL explained

Wed, 12 Oct 2016 22:09:00 +0000

I’m not sure about latest version of Microsoft SQL Server, but still popular 2008R2 and 2012 versions do not have an aggregate function that would join strings for you. You need to choose one of the work-arounds:

a lengthy query that is using PIVOT
a CLR aggregator function
FOR XML
Common Table Expression (CTE)

Recently I use a lot of XML-type columns and queries, so I choose XML-based solution. Let’s take baby steps.

Having this:

SELECT id, val FROM #tbl

	id	val
1	1	aaa
2	2	bbb
3	1	ccc

We want to get the following result:

	id	foo
1	1	aaa, ccc
2	2	bbb

Do you know that you can get a query result in XML by using FOR XML PATH directive.

SELECT * FROM #tbl FOR XML PATH

Result is:

<row>
  <id>1</id>
  <val>aaa</val>
</row>
<row>
  <id>1</id>
  <val>ccc</val>
</row>
<row>
  <id>2</id>
  <val>bbb</val>
</row>

PATH directive can be tweaked, to adjust the shape of resulting XML. You can tell how <row> node should be named.

SELECT * FROM #tbl FOR XML PATH('awesome')

<awesome>
  <id>1</id>
  <val>aaa</val>
</awesome>
<awesome>
  <id>1</id>
  <val>ccc</val>
</awesome>
<awesome>
  <id>2</id>
  <val>bbb</val>
</awesome>

So what? Let’s get to the point. The point is you can also make the node name empty, which is where things become interesting:

SELECT id, val FROM #tbl FOR XML PATH('')

<id>1</id>
<val>aaa</val>
<id>1</id>
<val>ccc</val>
<id>2</id>
<val>bbb</val>

You know what happens when you mess around with your columns, like adding an empty string to the result? SQL Server will not generate column name for you. You’ll get (No column name) in result header. I wonder how this will be represented in XML result…

SELECT id+'', val+'' FROM #tbl FOR XML PATH('')

1aaa1ccc2bbb

That’s the core of this hack. Now it is a matter of proper grouping, joining and cleanup.

SELECT id, (SELECT val+', ' FROM #tbl tblinner WHERE (tblinner.id=tblouter.id) FOR XML PATH('')) AS foo
FROM #tbl tblouter GROUP BY id

	id	foo
1	1	aaa, ccc,
2	2	bbb,

Now use replace() and len() or stuff() and voilla!

Code navigation in loosely coupled project architecture

Thu, 06 Oct 2016 20:35:00 +0000

When your web application project has App and Web layer, it is often not only divided conceptually but also on a physical and infrastructure layer. No matter if communication between layers is via WCF, asmx or .NET remoting (anyone here remembers .NET remoting?), you have a nice and clean separation with ability to scale but also a bit of a pain in code navigation. Drilling down using Go To Implementation finally get you to WCF proxy class, HTTP call or something similarly useless. Then you need to understand how the technology works and find “the other end”. Fortunately there are (simple) ways to tackle this problem. I really like this guy’s approach on WCF. I use it in some of my projects and it works really well.

Similar trick works for REST. If you are in control of both sides - REST service and a client - you can save yourself from code navigation pain with a simple interface. It is no rocket science but so many projects don’t follow this pattern and precious minutes of your life are wasted for unnecessary ctrl+F.

Imagine having the following code on a REST service side:

[RoutePrefix("api/v1/user")]
public class UserController : ApiController, IUserService
{
    [Route("{userId}")]
    public UserDto GetUser(int userId)
    {
        UserDto user = this.userRepo.GetById(userId);
        return user;
    }
}

and the following in the client:

public UserDto GetUser(int userId)
{
    var client = new HttpClient();
    client.BaseAddress = new Uri("http://localhost:2460/");
    var response = client.GetAsync("api/v1/user/" + userId).Result;
    if (!response.IsSuccessStatusCode)
    {
        return null;
    }

    string responseJson = response.Content.ReadAsStringAsync().Result;
    UserDto result = JsonConvert.DeserializeObject<UserDto>(responseJson);
    return result;
}

See the pattern?

public interface IUserService
{
    UserDto GetUser(int userId);
}

So now, every time you use your interface like below, you can Go To Implementation and easily see what’s going on on both sides of the wire.

IUserService user = new UserServiceClient();
UserDto userDto = user.GetUser(userId);

Note about RESTfulness

Returning null from GetUser method on server side is not very RESTful, yet we cannot return IHttpActionResult because we need to implement interface. Fortunately there’s a way:

[RoutePrefix("api/v1/user")]
public class UserController : ApiController, IUserService
{
    [Route("{userId}")]
    public UserDto GetUser(int userId)
    {
        UserDto user = this.userRepo.GetById(userId);
        if (userDto == null)
        {
            throw new HttpResponseException(System.Net.HttpStatusCode.NotFound);
        }

        return user;
    }
}

This doesn’t address the potential problem with RESTful PUT action (CreateUser) but creative programmer with figure something out using ActionFilterAttribute.

See the whole sample on my github.

Use VS Code to prettify XML and JSon code

Thu, 15 Sep 2016 23:00:00 +0000

While debugging, you often need to analyze a random piece of XML or JSon. Most of the time it is not pretty-printed, it is a single line, ugly blob which makes it hard to analyze. On my second blog I presented a tool which I use for XML formatting but since VS Code makes its way to most .NET developers machines, I thought it would be nice to have these features in Code as well. Additionally, JSon support is present in Code by default, so it makes it one to rule them all.

So how to quickly format a random piece of XML or JSon in Code?

Create a new tab (ctrl + n), paste your code snippet (ctrl + v). Notice that until you save it, it will not be recognized as XML or JSon, so Format Code option, which we’ll cover in a minute, will not be available. You probably don’t want to save this file (file extension would hint code what is the type of data), so you need to use Change Language Mode (ctrl + k, m) option from the command palette (ctrl + shift + p) and choose JSon or XML. By the way, XML is not supported by default, so make sure you have XML Tools extension installed. Now, since VS Code is aware of context, hit (ctrl + shift + p) again and choose Format Code.

Transitive Group queries in Azure AD Graph API

Sat, 23 Apr 2016 18:37:00 +0000

In Windows Azure Graph API, some operations on groups are transitive and others are scoped only to direct members of the group. So if you have a user that is a member of developers group, and groups reporting and admin contain developers, non-transitive operation will not tell you that your user is member of reporting.

I needed to get all group names that user is assigned to. I had the following code:

IUserFetcher userFetcher = graphClient.Users.GetByObjectId(userObjectId);
IPagedCollection<IDirectoryObject> pagedCollection = await userFetcher.MemberOf.ExecuteAsync();
// further processing

I was all nice until nested groups appeared. MemberOf is not transitive, so I needed something else. According to documentation, I can do something like:

var groupIds = await userFetcher.GetMemberGroupsAsync(false);

but that gave me a collection of objectIds and not the rich object. I needed to query Graph API for list of Group objects that I am interested in, not falling into n+1 trap using graphClient.Groups.GetByObjectId(). Note that graphClient.Groups.Where() clause is limited solely to displayName startsWith filter and every other interesting predicate will throw an exception.

I know about batches but still, some filtering would be an obvious choice.

Finally, after hours of experimenting and googling, I found GetObjectsByObjectIdsAsync method of ActiveDirectoryClient itself. Now the following code works:

IUserFetcher userFetcher = graphClient.Users.GetByObjectId(userObjectId);
IEnumerable<string> userGroupIds = await userFetcher.GetMemberGroupsAsync(false);
List<string> userGroupIdList = userGroupIds.ToList();
IEnumerable<IDirectoryObject> userGroups = await graphClient.GetObjectsByObjectIdsAsync(userGroupIdList, new List<string> {"group"});
foreach (IDirectoryObject directoryObject in userGroups)
{
    var group = directoryObject as Group;
    if (group != null)
    {
        groupNames.Add(group.DisplayName);
    }
}

Hope it will help someone in a similar situation. This is a horrible developer experience and I am seriously considering contributing to Graph project since all pieces seem to exist, someone just need to put them in a correct place.

Advanced late hotfix scenario in Git

Thu, 07 Apr 2016 22:56:00 +0000

There was a project with the following history.

4aa5222 - some other bugfix
220a4bd - small feature 2
ebad147 - important fix 2
b04860f - small feature 1
f4a7a5d - some bugfix
a39ba71 - important fix 1
e117d73 - something 2
5fe39ad - something 1

This project hit production after 5fe39ad - something 1. Soon we realized that there were two bugs but business decided that they are not so important and we’ll wait for fixes until next planned release. Then developers fixed these bugs directly in development branch. Then business changed their minds. How to release hotfix with important fixes 1 and 2 and have a nice development branch history? Here’s what I did.

Create patches for a39ba71 and ebad147:

[development ≡]> git format-patch -1 a39ba71
[development ≡]> git format-patch -1 ebad147

Revert a39ba71 and ebad147:

[development ≡]> git revert a39ba71
[development ≡]> git revert ebad147

Create hotfix branch from release:

[development ≡]> git checkout release-1
[release-1 ≡]> git checkout -b hotfix-1

Apply patches. Powershell is acting out when using less then operator, so some voodoo is required:

[hotfix-1 ≡]> cmd.exe /c "git am < C:\temp\0001-important-fix-1.patch"
[hotfix-1 ≡]> cmd.exe /c "git am < C:\temp\0001-important-fix-2.patch"

Merge to release and development.

I realize that this is more note to self rather then full-blown blog entry but I hope it may help someone in similar situation.

SQL Backup Helpers for PowerShell

Sat, 26 Dec 2015 11:47:00 +0000

My workflow with SQL often looks like that:

backup
hack, hack, hack
break something important
restore
repeat

To make life easier, I created three batch scripts: backup.bat, drop.bat and restore.bat, that wrap osql.exe to do the obvious. But there’s a problem. While number of apps I have to support in my day job increases, I need to remember more and more database names because these scripts are dummy and need explicit, correct parameters. I decided that enough is enough and created smarter PowerShell module that includes tab completion for available databases and automatically restores last backup if called without parameters.

New-SqlBackup -dbName AdventureWorks
Restore-SqlBackup AdventureWorks

Please make note that this module depends on SQL Server Management Objects API, so you need to have Client Tools SDK for SQL Server (part of SQL Server installation) or Shared Management Objects from the SQL Server feature pack.

Download

SqlHelpers PowerShell module is available on github