Blog posts by Rejaie Johnson

Blog posts by Rejaie Johnson2017-12-18T05:40:45.0000000Zhttps://world.optimizely.com/blogs/rejaie-johnson/ Optimizely World Web API + Service API + Cookie Auth Gotcha<!DOCTYPE html> <html> <head> </head> <body> I ran into an interesting problem while on a past project this year - when we turned on Service API via OWIN, my authorized Web API endpoints were returning a 401. We were using cookie authentication for the Web API endpoints. This baffled me a bit until I peeled back the code for Service API. When one of the Service API's initialization modules executes, it bypasses the default host authentication by calling SupportDefaultHostAuthentication on the Global HTTP Configuration. This explains why my API endpoints weren't recognizing the logged in user's cookie. I came up with a workaround that ignored this call and used cookie authentication instead. See below - during this project, we were using Episerver 10.9.1, and Service API 3.0.1: <ul> <li> Add the following code to your OWIN startup. This code ultimately re-adds cookie auth to the Web API filter pipeline <pre class="language-html"><code>GlobalConfiguration.Configuration.Filters.Add(new HostAuthenticationFilter(DefaultAuthenticationTypes.ApplicationCookie));</code></pre> </li> <li> In your API controller, decorate your controller or action with the System.Web.Http's Authorize Attribute </li> </ul> After I made these changes, I was able to access my authorized Web API endpoints. As a quick note, if you do use cookie authentication for your Web API endpoints, you may want to send an antiforgery token to protect against XSRF attacks. In this project, I sent the antiforgery token as a header and created a filter attribute that validated the token against the logged in user's cookie. In case anyone is interested, here was my setup: <ul> <li> In my master layout, I included a global antiforgery token. I placed this right after the <body> tag, but you can place this anywhere. </li> <li> In my client side code, I sent the antiforgery token as a header. I called the __RequestVerificationToken. </li> <li>On the server side, I created an attribute called UserValidateAntiForgeryTokenAttribute that inherited from FilterAttribute and IAuthorizationFilter. In the ExecuteAuthorizationFilterAsync method, I grabbed the cookie and token values and validated them against each other. <pre class="language-csharp"><code>public Task<HttpResponseMessage> ExecuteAuthorizationFilterAsync(HttpActionContext actionContext, CancellationToken cancellationToken, Func<Task<HttpResponseMessage>> continuation) { try { // get headers var headers = actionContext.Request.Headers; // get cookie value var cookieRvtValue = headers .GetCookies() .Select(c => c[AntiForgeryConfig.CookieName]) .FirstOrDefault() ?.Value; // get header value var headerRvtValue = headers.GetValues("__RequestVerificationToken").FirstOrDefault(); // validate AntiForgery.Validate(cookieRvtValue, headerRvtValue); } catch { actionContext.Response = new HttpResponseMessage { StatusCode = HttpStatusCode.Forbidden, RequestMessage = actionContext.ControllerContext.Request }; var source = new TaskCompletionSource<HttpResponseMessage>(); source.SetResult(result); return source.Task; } return continuation(); } }</code></pre> </li> <li> Decorate your Web API controller action with the attribute <pre class="language-html"><code>[UserValidateAntiForgeryToken] [Authorize] [HttpGet] public string DoGetAction() { // do something return string.empty; } </code></pre> </li> </ul> Thanks for reading. Hope you find this helpful! </body> </html>2017-12-18T05:40:45.0000000Z

Blog post

Securing Web API Endpoints with Owin + Oauth 2.0, Part II<!DOCTYPE html> <html> <head> </head> <body> To recap Part I of this series, I showed you how you can configure ASP.NET Identity and Owin/Oauth to authenticate/authorize your Web API endpoints. Now, let's say you don't want to maintain different sets of user name/password combinations in a separate data store. Instead, ideally, you would like to maintain this information in Azure Active Directory Domain Services. If this is you, you're in luck. Here's another step-by-step guide on how I configured Azure AD with OWIN inside of Episerver. This set up assumes you are making server-server authentication calls. Disclaimer: I ran this POC on Episerver 10.8.0, so later versions should work with this configuration. Unfortunately, I'm not sure if earlier versions will be compatible: <ol> <li>First, you will need to ensure Azure Active Directory is enabled in your subscription. Here's a <a href="https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-getting-started-enableaadds">link</a> on how to do this.</li> <li>Next, you will need to create 2 apps, one for the Web API and one for the client. Here's a <a href="https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-devquickstarts-webapi-dotnet">link</a> on how to do this. You can follow steps 1 & 3 in the link (I will explain step 2 from the link next).</li> <li>Next, you will need to modify the Startup.cs file to use Azure Active Directory as the Authentication provider. Below you will find the code. Essentially, the Windows Active Directory options (WindowsAzureActiveDirectoryBearerAuthenticationOptions) will look at the credentials passed in from the request and will respond back with an Oauth 2.0 token, if the credentials are correct. The options class will need to be initialized with the Web API App's App URI ID (Audience) and Active Directory Name (Tenant). <pre class="language-csharp"><code>public class Startup { public void Configuration(IAppBuilder app) { var config = new HttpConfiguration(); this.ConfigureAzureADAuth(app); WebApiConfig.Register(config); app.UseWebApi(config); app.UseServiceApiMembershipTokenAuthorization(); } private void ConfigureAzureADAuth(IAppBuilder app) { app.UseWindowsAzureActiveDirectoryBearerAuthentication( new WindowsAzureActiveDirectoryBearerAuthenticationOptions { Audience = ConfigurationManager.AppSettings["ida:Audience"], Tenant = ConfigurationManager.AppSettings["ida:Tenant"], AuthenticationType = "OAuth2Bearer", } ); } }</code></pre> </li> <li>Next, create a console application project and give it a name. This console application will be used as our client to test the configuration.</li> <li>Next, ensure that the Microsoft.IdentityModel.Clients.ActiveDirectory NuGet package is installed.</li> <li>In the Main method, add the following code from below:</li> <ul> <li>The code first creates an authentication context to your Active Directory Domain. The pattern for the URL used is https://login.windows.net/[Azure AD Domain Name].</li> <li>Next, you will need to enter the client app's Application ID and Key of the client application created in Step 2 as ClientCredentials. The key will be created under Keys in the client application.</li> <li>Next, you will need to acquire a token by sending the ClientCredentials to the Web API's App URI ID.</li> <li>After you send the ClientCredentials to the Web API's App URI ID, Azure AD will send you back an Oauth 2.0 Bearer token to use. Now, you can call the GetListOfNumbers endpoint with that token. <ul> <li>Code <pre class="language-csharp"><code>class Program { static void Main(string[] args) { ADAzureAuthStuff(); } static void ADAzureAuthStuff() { AuthenticationContext ac = new AuthenticationContext("https://login.windows.net/[Azure AD Domain Name goes here]"); //Leaf node is Azure AD Domain name var clientCredentials = new ClientCredential("[Client Application ID goes here", "[Client Application Key goes here]"); //first parameter: Application ID, //Second Parameter is a key configured in the client application AuthenticationResult ar = ac.AcquireTokenAsync("[Web API App's App URI ID goes here]", //This parameter is the Web API App's Application ID URI clientCredentials).Result; string result = string.Empty; HttpClient httpClient = new HttpClient(); httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", ar.AccessToken); HttpResponseMessage response = httpClient.GetAsync("http://alloy.dev.com/sample-api/getlistofnumbers").Result; if (response.IsSuccessStatusCode) { result = response.Content.ReadAsStringAsync().Result; } Console.WriteLine(result); Console.ReadLine(); } }</code></pre> </li> <li>Screenshots of running code Token after targeting my Active Directory Domain and sending ClientCredentials to the Web API App's Applicaton ID URI <img src="/link/cc49b7757ef84af185438668d227261b.aspx" /> Success Status <img src="/link/869ed2e8fff14c379e5ac40fadc24a0c.aspx" /> Result <img src="/link/a7518a3419b643c99ef3708490e1cbd9.aspx" /></li> </ul> </li> </ul> </ol> There you have it - you now have two different ways on how to secure your Web API endpoints using OWIN, at least in a server-server authentication capacity. I'm sure you are wondering - well, can I use OWIN to handle my authentication for content editors/admins and customers? Of course you can! Here are some Episerver documentation on how to do this: <ul> <li><a href="/link/9e3ab295f8234005855614aa6a84561f.aspx">Owin Authentication</a></li> <li><a href="/link/9fe1050fea0e468cbfa6009819921870.aspx">Configure mixed-mode OWIN authentication</a></li> </ul> From there, you can definitely mix and match how you want users to authenticate to your Episerver's back-end, customer portal, and Web API endpoints. Happy coding! </body> </html>2017-05-31T17:52:13.0000000Z

Blog post

Securing Web API Endpoints with Owin + Oauth 2.0, Part I<!DOCTYPE html> <html> <head> </head> <body> In my <a href="/link/04204d9d5d924fb1beb242938ce73d93.aspx">last blog</a>, I explained how simple it is to expose a Web API endpoint inside of Episerver. Now, the next question is: How can you secure these endpoints? Here's a scenario - you've created a scheduled job in Episerver to fetch data from an XML file, and you've stored this data using <a href="/link/7b5666f0001045ea937bc5d293e0d13f.aspx">Dynamic Data Store</a>. Now, you want your mobile and other supporting applications to consume this information by hitting Web API endpoints inside of Episerver. Of course you don't want anyone/everyone hitting your endpoints, right? That could lead to a slew of issues. In pure Episerver fashion, it is pretty straight-forward and not as hard as you would think to secure Web API endpoints using Oauth 2.0 through OWIN. In a nutshell, OWIN is a standard that essentially decouples IIS and the web application. In a 2-part series, I'm going to walk you through how you can configure OWIN/Oauth inside of Episerver using ASP.NET Identity and Azure Active Directory as the authentication layer. First, below you will find the steps I took to configure Owin/Oauth and ASP.NET Identity. Disclaimer: I ran this POC on Episerver 10.8.0, so later versions should work with this configuration. Unfortunately, I'm not sure if earlier versions will be compatible: <ol> <li>Install Owin-specific packages <ol> <li>Install the Episerver ServiceAPI Nuget Package. This package will give you all of the goodies needed to use OWIN inside of Episerver (because it actually uses OWIN!).</li> </ol> </li> <li>Configure Startup File <ol> <li>Create a .cs code file under the root project folder called Startup.cs. This Startup class will be our entry point in configuring our authentication parameters for the Web API endpoints.</li> <li>Inside of the Startup.cs file, we need to make sure we lock down the Service API endpoints first. Let's add the following: <pre class="language-csharp"><code>public class Startup { public void Configuration(IAppBuilder app) { app.UseServiceApiMembershipTokenAuthorization(); } }</code></pre> </li> <li>Above the namespace in the Startup.cs code file, add the following code. This line of code tells OWIN to use the Startup class as the entry point for configuration. Insert your namespace in the placeholder [NamespaceGoesHere]: <pre class="language-html"><code>[assembly: OwinStartup(typeof([NamespaceGoesHere].Startup))]</code></pre> </li> </ol> </li> <li>Create ASP.NET Identity Backend <ol> <li>Create another .cs code file under the root project folder named EpiApiAuthDbContext.cs. Inside of this code file, add the code from below. This is a simple Identity DB context that points to our custom authentication database. The string inside of the base constructor is the connection string to the database used to store this information. If the IdentityDbContext class does not resolve for you, please ensure that you have the Microsoft.AspNet.Identity.EntityFramework NuGet package installed. You can use Entity Framework Migrations to create the database, but in my case, I just cracked open SQL Server Management Studio and created the database. Also, don't forget to add your connection string in the web.config. <pre class="language-html"><code>public class EpiApiAuthDbContext : IdentityDbContext { public EpiApiAuthDbContext() : base("EpiApiAuthContext") { } }</code></pre> </li> <li>Create another .cs code file under the root project folder named EpiApiAuthRepository.cs. Add the code from below. This repository class will be used to create and find users. In a later step, we will build an action that will create our dummy user to authenticate to the Web API (very similar pattern that's used to set up the admin account for DXC environments). For a full-fledge solution, you can build a UI for users (or admins) to create their username/password combination(s). <pre class="language-html"><code>public class EpiApiAuthRepository : IDisposable { private EpiApiAuthDbContext _context; private UserManager<IdentityUser> _usrMgr; public EpiApiAuthRepository() { _context = new EpiApiAuthDbContext(); _usrMgr = new UserManager<IdentityUser>(new UserStore<IdentityUser>(_context)); } public async Task<IdentityResult> CreateUserAsync(UserModel userModel) { IdentityUser user = new IdentityUser(); user.UserName = userModel.UserName; var createResult = await _usrMgr.CreateAsync(user, userModel.Password); return createResult; } public async Task<IdentityUser> GetUserAsync(string username, string password) { IdentityUser usr = await _usrMgr.FindAsync(username, password); return usr; } public void Dispose() { _context.Dispose(); _usrMgr.Dispose(); } }</code></pre> </li> </ol> </li> <li>Create Oauth Authorization Provider Class <ol> <li>Create another .cs code file under the root folder named SimpleAuthorizationServerProvider.cs. This class inherits from OAuthAuthorizationServerProvider and overrides two methods: ValidateClientAuthentication and GrantResourceOwnerCredentials. <ol> <li>ValidateClientAuthentication  - this method is used to validate the "client_id" parameter. Here, we will just call the <a href="https://msdn.microsoft.com/en-us/library/dn385502(v=vs.113).aspx">Validate</a> method from the context since we're authenticating with the username/password combo.</li> <li>GrantResourceOwnerCredentials - This method will contain logic to authenticate the incoming request's username/password combo via the GetUser method in our Repository class. If the user is found, we will validate the request with the user's ASP.NET Identity. If not found, we will set an error. <pre class="language-html"><code>public class SimpleAuthorizationProvider : OAuthAuthorizationServerProvider { public override async Task ValidateClientAuthentication(OAuthValidateClientAuthenticationContext context) { context.Validated(); } public override async Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context) { context.OwinContext.Response.Headers.Add("Access-Control-Allow-Origin", new[] { "*" }); using (EpiApiAuthRepository authRepository = new EpiApiAuthRepository()) { IdentityUser user = await authRepository.GetUser(context.UserName, context.Password); if (user == null) { context.SetError("invalid_grant", "The user name or password is incorrect."); return; } } var identity = new ClaimsIdentity(context.Options.AuthenticationType); identity.AddClaim(new Claim("sub", context.UserName)); identity.AddClaim(new Claim("role", "user")); context.Validated(identity); } }</code></pre> </li> </ol> </li> </ol> </li> <li>Complete Startup code <ol> <li>Add the following code from below to complete the startup file: <ol> <li>First, we will set up our Oauth Authorization by specifying a Token endpoint, how long the token will stay active, allow insecure requests (TRUE should only be used for development purposes only), and a provider that will handle the authorization of the incoming requests. </li> <li>Next, we will register our Web API endpoints. If you've registered your Web API endpoints, in the Global.asax.cs file, please remove that registration</li> <li>Also, we will tell the Startup to use this config for Web API. <pre class="language-csharp"><code>public class Startup { public void Configuration(IAppBuilder app) { var config = new HttpConfiguration(); this.ConfigureOAuth(app); WebApiConfig.Register(config); app.UseWebApi(config); app.UseServiceApiMembershipTokenAuthorization(); } private void ConfigureOAuth(IAppBuilder app) { OAuthAuthorizationServerOptions OAuthServerOptions = new OAuthAuthorizationServerOptions() { AllowInsecureHttp = true, TokenEndpointPath = new PathString("/token"), AccessTokenExpireTimeSpan = TimeSpan.FromDays(1), Provider = new SimpleAuthorizationProvider() }; app.UseOAuthAuthorizationServer(OAuthServerOptions); app.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions()); } }</code></pre> </li> </ol> </li> </ol> </li> <li>Create Custom Authorize Attribute <ol> <li>Add a .cs file under the root project folder called CustomAuthorizeAttribute. Add in the code from below. You will need to create a custom authorize attribute to secure the Web API endpoints. When I tried using the out-of-the-box Authorize attribute, Episerver constantly redirected me to the Login page. This was due to the fact that Episerver is still set to use Forms Authentication, which is what we want ultimately. The implementation below will bypass this and let the Oauth server authenticate the user. NOTE: I've set the response to 403 instead of 401 if the user is not authorized. This is because if I set the response code to 401, the response will be redirected to log in Episerver log in page, which is not our desired outcome. <pre class="language-html"><code>public class CustomAuthorizeAttribute : System.Web.Http.AuthorizeAttribute { protected override void HandleUnauthorizedRequest(System.Web.Http.Controllers.HttpActionContext actionContext) { if (HttpContext.Current.User == null || HttpContext.Current.User.Identity == null) { actionContext.Response = new System.Net.Http.HttpResponseMessage(System.Net.HttpStatusCode.InternalServerError) { ReasonPhrase = "User not is authenticated." }; } else { actionContext.Response = new System.Net.Http.HttpResponseMessage(System.Net.HttpStatusCode.Forbidden); } } }</code></pre> </li> </ol> </li> <li>Create Web API Endpoints <ol> <li>Create your Web API endpoints inside of the Episerver project. You can refer to my <a href="/link/04204d9d5d924fb1beb242938ce73d93.aspx">previous blog</a> on how to create your endpoints. For this example, I will have a Web API Controller called SampleApiController with 2 endpoints: <ol> <li>GetListOfNumbers - this endpoint will return a list of numbers</li> <li>AddApiCredentials - this endpoint will create our dummy account to use to authenticate to our Oauth Provider. Of course, the credentials used need to pass any/all security measures created by your team/client/company. <pre class="language-csharp"><code>public class SampleApiController : ApiController { [CustomAuthorize] [HttpGet] [ActionName("GetListOfNumbers")] public IHttpActionResult GetListOfNumbers() { return Ok(new int[] {1, 2, 3, 4, 5, 6, 7, 8, 9 }); } [HttpPost] [ActionName("AddApiCredentials")] public async Task<IHttpActionResult> AddApiCredentialsAsync() { var adminUser = new UserModel() { UserName = "epiadmin", Password = "123456abcdef" }; using(var repo = new EpiApiAuthRepository()) { await repo.CreateUserAsync(adminUser); } return Ok(); } }</code></pre> </li> </ol> </li> </ol> </li> <li>Let's start testing!! <ol> <li>For testing, I used Fiddler to make my GET/POST calls. However, you can use whatever you tool to test the configuration. First, you will need to create the dummy account to test. Make a POST call to the AddApiCredentials endpoint. This endpoint is very similar to the aspx page used to create an admin account for your Episerver site if deploying to a DXC environment for the first time. AddApiCredentials Post Call <img src="/link/e5ed8e2cedf14506a3fd9d16140c912f.aspx" /> AddApiCredentials Response <img src="/link/075616ebb4f94f20b7a1ad401b3cca37.aspx" /></li> <li>Next, make a POST call to the token endpoint, sending the user name/password combination. The response should give you a response back with an access token and when it expires. In your client application, you can store this token somewhere. Token POST Call <img src="/link/fc36dc385c484ed4b7e6c577120b5f03.aspx" /> Token Response <img src="/link/23f09b23e43245b389bdb5c66161f0bb.aspx" /></li> <li>Next, make a GET call to the GetListOfNumbers endpoint. Make sure that you send the access token as a Bearer token on the Authorization header. The response should give you back an array of numbers! GetListOfNumbers GET Call <img src="/link/e7fde171619041b18fcfe6b9d8f2903e.aspx" /> GetListOfNumbers Response <img src="/link/cb842b7d929f49e5a35457d02541cc2d.aspx" /></li> <li>Next, delete the first four characters in the access token, and make the GET call to the GetListOfNumbers endpoint again. The response should give you a 500 or 403 since the access token is incorrect. GetListOfNumbers Incorrect Token GET Call <img src="/link/777005f72ee4439c92d9b0e010f21a05.aspx" /> GetListOfNumbers Incorrect Token Response <img src="/link/0536b19b14d94e94b0a8df64b59eaced.aspx" /> <img src="/link/698a7b0fc5ff409a86cdfb6244c34645.aspx" /></li> </ol> </li> </ol> In Part II, I will discuss how to configure Azure Active Directory instead of ASP.NET Identity to grab an Oauth token to secure your Web API endpoints. Happy Coding! </body> </html>2017-05-31T17:52:06.0000000Z

Blog post

Episerver CMS + Web API<!DOCTYPE html> <html> <head> </head> <body> During my last Episerver project, I needed to stand up a Web API endpoint to grab data from an external source. Sounds easy enough, right? Actually, it is in Episerver. One of Episerver’s greatest strengths is the code base works really well with existing ASP.NET features like Web API. In the scenario above, you can easily wire up a Web API Controller just like you would in any MVC web application. Here are the steps I followed to set up a very simple Web API controller in Episerver:   <ol> <li>Open your Episerver solution in Visual Studio</li> <li>Create an API controller named DummyApiController under the Controllers folder. From here, add an action to do something simple, such as returning the number 5. <img src="/link/d4e1a64e3f18437c838afcf741ec7d95.aspx" width="226" alt="Image Step2-1.png" height="110" /> <img src="/link/ff527e02f3204989b8143c6edf3e65a6.aspx" width="436" alt="Image Step2-2.png" height="157" /> </li> <li>Create a code file named WebApiConfig.cs. This fill will contain a method called Register. This method will register the route to our custom API. <img src="/link/1c136a8a381f45e0b151f2024e171954.aspx" width="345" alt="Image Step3-1.png" height="126" /> </li> <li>Add code to register your route with the application in the WebApiConfig.cs file.<img src="/link/da41895a52c444018ba3483049c1d462.aspx" width="681" alt="Image Step4-1.png" height="97" /></li> <li>Next, call the register method in the Application_Start method. You can find this method in the global.asax.cs file<img src="/link/02430b56729a434ea7a4a592c0d757c0.aspx" width="681" alt="Image Step5-1.png" height="102" /></li> <li>Fire up your app, and navigate to your API endpoint (http://host/app-api/getdummynumber). The request will return the number 5!<img src="/link/e1da05fa6d5b49538ab74d2916112d45.aspx" width="681" alt="Image Step6-1.png" height="148" /> </li> </ol>   That’s it. Very, very simple. However, in this case, you will need to do a lot more in terms of security and data input validation. Hope this is helpful to you. </body> </html>2017-05-10T22:29:09.1630000Z

Blog post