Synchronize Episerver according to your ClaimsIdentity during Authentication
Well-known built-in Identity classes, such as GenericPrincipal and WindowsPrincipal, has been supported for ages in Episerver CMS. .NET’s support around claims were introduced in .NET4.5, to support claims based authentication into the framework, in the form of ClaimsIdentity and ClaimsPrincipal. Episerver of course quickly adopted this way of dealing with external identities and has over time supported both Windows Identity Foundation and OWIN.
Following blog post assumes the use of OWIN, through Microsoft’s Katana project, and focuses on one specific aspect of the login pipeline: syncronization of data to Episerver as soon as any ClaimsIdentity authenticates.
What’s the purpose?
Synchronization of customer data during any login scenario, regardless of it being username/password or through an external single-sign-on solution, can be very beneficial. We’ve multiple times been required to ensure Episerver’s data around customer contacts and/or organizations were up to date whenever a customer accessed our platform. Relying on a centralized mechanism for such requirement ensures we aren’t short on supporting edge-case scenarios or longer term scale.
Trigger the synchronization during login
Cookie Authentication, for OWIN, relies on a series of cycles and events, where we as developers are allowed to intercept and apply our own logic. For the purpose of synchronization of Episerver records, we frequently listen to OnResponseSignIn as part of the built in CookieAuthenticationProvider. Triggering Episerver’s built in ISynchronizingUserService is very easy and can be boiled down to a code snippet as simple as below.
Some of you may think – what is ISynchronizingUserService? Episerver does ship with an implementation of ISynchronizingUserService, which manages user synchronization during WSFed login flows. For the purpose of this blog post, we wont cover this implementation in more detail, but we will though rely on ISynchronizingUserService to facilitate additional levels of data synchronization.
Extend ISynchronizingUserService to synchronize additional data
Tailoring built-in Episerver implementations are always an easy task thanks to the strict use of a loosely coupled architecture glued together by great patterns such as inversion of control. Since ISynchronizingUserService not is considered an internal interface, we can safely alter the implementation since it’s governed by Episerver’s semantic versioning.
We are in above snippet keeping the built-in synchronization for WSFed (for compatability). On top of that piece, we are also enabling an additional layer of data synchronization. SynchronizeContact can be implemented as per the requirements of your project, but we have before done implementations obtaining additional customer information based on a claim value (e.g. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/customerid).
If you’re looking for how to enable your new implementation, then please have a look at Episerver’s documentation here.