0

So we have integrated Okta in our application for an SSO solution utilizing the OWIN stack and Microsoft.Owin.Security.WsFederation nuget package. It seems to work well overall, however we have a problem when the authorize attribute for WebApi is added to the mix. The custom authorize attribute works as designed for permissions provided via string parameter, however the problem seems to occur with the default behavior of returning a 401 response. It seems this 401 is watched for globally as I never hit my custom OWIN middleware component to sign in (ie: re-direct to Okta) yet still the API request fails when a 302 is returned which triggers the re-direct to Okta. Every post I have read indicates to follow this blog post by Brock Allen, however as I mentioned the re-direct never triggers this code. I thought about building an Angular Interceptor but I don't like that approach at all, so I went with returning a 403 (Forbidden) for now from the Authorize attribute, which isn't ideal but is workable. This SO post seems to be the main discussion on this issue but I have had no luck following the advice there. Here is the middleware code being utilized thus far, does anyone have any thoughts or ideas on how to exclude /api routes from being re-directed to Okta?

        var fileSystem = new PhysicalFileSystem(@".\wwwroot");

        var options = new FileServerOptions()
        {
            FileSystem = fileSystem,
            EnableDefaultFiles = true,
            EnableDirectoryBrowsing = true,
        };

        app.SetDefaultSignInAsAuthenticationType(WsFederationAuthenticationDefaults.AuthenticationType);

        app.UseCookieAuthentication(
            new CookieAuthenticationOptions
            {
                AuthenticationType = WsFederationAuthenticationDefaults.AuthenticationType,
            });

        app.UseWsFederationAuthentication(
                new WsFederationAuthenticationOptions
                {
                    MetadataAddress = ConfigurationManager.AppSettings["MetadataAddress"],
                    Wtrealm = ConfigurationManager.AppSettings["Wtrealm"],
                    TokenValidationParameters =
                    {
                        ValidAudience = ConfigurationManager.AppSettings["ValidAudience"]
                    }
                });


        app.Map("/api", x =>
        {
            dependencyResolver = x.UseApi();
        });

        app.UseFileServer(options);
Community
  • 1
  • 1
Shawn
  • 869
  • 1
  • 9
  • 27
  • 1
    I'd recommend taking a look at http://www.cloudidentity.com/blog/2014/04/28/use-owin-azure-ad-to-secure-both-mvc-ux-and-web-api-in-the-same-project/. Although the post uses OIDC, that approach should work with WSFed just as well. – vibronet Dec 18 '15 at 00:05
  • @vibronet I would love for you to post this as an answer so you get the credit that is due. That article resolved my problems as I did not know about the HostAuthentication attribute. I will give you the answer if you post it. Thanks again that blog never came up in my research! – Shawn Dec 18 '15 at 13:21

1 Answers1

1

I'd recommend taking a look at http://www.cloudidentity.com/blog/2014/04/28/use-owin-azure-ad-to-secure-both-mvc-ux-and-web-api-in-the-same-project/ - the post is about OIDC but should apply to wsfed just as well.

vibronet
  • 7,364
  • 2
  • 19
  • 21