Extended SSO for Discourse with IdentityServer3


In our business we operate a number of customer-facing web services which use an IdentityServer3 identity provider as the single source of identity. We have customised our setup to allow two sources of federated identity, and to pull certain claims from our CRM.

We have a new requirement to integrate a hosted instance of the excellent Discourse discussion forum, also using the same single source of identity.
Discourse does not support OpenId Connect, rather its own particular form of SSO.

Using IdentityServer3 as SSO source for Discourse

John Korsnes wrote the core of this approach, documented in his Medium article and on Github. In his article he gives a good overview of how the Discourse SSO works, and explains his approach:

  • a custom endpoint on the IdentityServer, running in the same Owin context as the main IdP
  • configure Discourse to redirect a login to the custom endpoint
  • in the custom endpoint check if the user has a current authenticated session with IdentityServer
  • if they have, generate a Discourse SSO payload from the user properties, and return to Discourse
  • if they haven’t, display a simple login form, and once they have authenticated, generate and return the Discourse SSO payload as before

Our modifications

From our perspective the only drawback of John’s approach was that it only allowed for user authentication against the local IdentityServer accounts (username / password). Although that covers most of our customer accounts, we have extended our IdP with federated identity against our own company Office365 (Azure AD), and against Google, as some of our customers use Google Apps corporately.

To extend John’s approach we modified it so that instead of displaying a local login form we:

  • register an application in our IdentityServer as a proxy for Discourse
  • carry out an (almost) standard Authorization Code authentication process from our custom controller against the Identity Server
  • the only difference is that because we are running inside the IdentityServer web piipeline we don’t need to redeem the authorization code agaisnt the token endpoint, but can ignore any generated tokens and query the Owin Context in the same way John does.

Our version is shown below

Week Note: w/e 10/02/2017

Account based Marketing and Dynamics CRM

Some useful notes and links here  from Steve Mordue , CEO of ForceWorks on Account-Based Marketing, and ways to adapt the native behaviour of Dynamics 365 to support it.

Beyond his suggestions I think the following are key in terms of building and information base about your target accounts:

  • acquire as much contextual information about accounts as possible, via both automated and human sources
  • whilst acquiring as much data as possible about individual customer interactions on touchpoints, put significant effort into linking those individuals to an account
  • when customising the touchpoint experiecne for an individual, take into consideration their account context, including other recognised individuals


Dynamics CRM entity status weirdness


Since upgrade of CRM Online to 8.2, we have noticed some strange issues around workflow triggers that are supposed to be fired by the change of a record status.

We have a workflow associated with the Invoice entity that is set to trigger on change of record status:

Workflow trigger settings

The workflow is responsible for setting up various bits of data when we issue an invoice, then flagging to an external integration that the invoice is ready to send to Finance.

We trigger the workflow in a couple of places – in C# code that runs during various automated operations, and in Javascript in response to a manual button click.

Updating the invoice status – the old way

Traditionally we would fire this using a SetStateRequest (C#, Javascript):

Updating the invoice status – the new way

However as that call has been deprecated, we took the opportunity of some other refactorings to migrate to using Update requests.

Using C# and IOrganizationService.Update

First attempt in C# was:

However we found that the workflow was being triggered twice!

The only way we found to stop this happening was to adjust the code so we only update the statuscode attribute:

Using Javascript and REST API PUT

Our first attempt in Javascript mirrored what we had found in C#:

However we found that although this appears to change the entity fields correctly:

Invoice status set correctly after REST PUT call just with status code

… the workflow is just not being triggered

So then we tried in javascript settiing the statecode as well, and the workflow triggers twice again! We restored the javascript to only update status (as per the gist above), and moved on to look at other settings for the process trigger.

Changing the process trigger

We changed the process trigger for the workflow to be “When record fields change” (i.e. update), and filtered only on statuscode

Worflow update trigger
Worflow update trigger filter attribute

I half expected that this might fire initially but that later steps where the workflow calls itself recursively by changing status of the invoice would fail.

First experiment was triggered by using the Javascript button(sending a PUT with only the statuscode). This ran correctly all the way through.

Second experiment was triggered from C# code based on other system actions. That too ran correctly all the way through, with the process only triggered once.

UPDATE – later in testing we started seeing random double triggers on this when the invoice status was changed using Update. Reverting to legacy SetStateRequest (but with the process still triggered on Update) corrected this behaviour. As none of this fits with documentation we assume it is an obscure bug in the platform


Microsoft have made changes to the way entity status interacts with processes.

The Microsoft recommendation is that all code which changes record status should do using updates, not the deprecated SetStateRequest

UPDATE: however from our later tests we consider SetStateREquest to be the safer option on the IOrganizationService

For workflows which are set to trigger on “Record status changes” there appears to be inconsistent behaviour depending on the source of the update (SOAP via the IOrganizationService, or directly to the newer REST API )

From our tests, any workflows which are triggered from “Record status changes” should be modified to fire on “Record fields change”, filtered down to just the status field.

Worflow steps created in the Workflow Designer which call “Set record status” still work, and will still fire triggers that have been modifed as above

A weirdness with xunit

Today was rebuilding a solution that had been updated to xunit2, and kept getting random test failures, usually with some kind of conflict with Rhino Mocks. The fix seemed to be to turn off the parallel testing. A little googling turned up this which suggests Rhino Mocks does indeed have a problem in a multi-threaded test environment