This project has moved and is read-only. For the latest updates, please go here.

Enriching claims after authorization

Jul 8, 2014 at 12:53 AM
Edited Jul 8, 2014 at 1:29 AM
In my MVC.NET project I've been using System.IdentityModel and System.IdentityModel.Services for authentication against a WAAD instance (and life was good) then I migrated to owin WSFederation (RC1) and now have two issues:
  1. For some reason the controller action protected by the [Authorize] attribute never detects that the authorization is successful. I am being redirected to the sign in page and after I log in with my domain credentials, the authentication goes into a loop where it authenticates against AD and redirects me to the resource I was trying to reach which forces a redirect back to verify if i'm authenticated, which redirects me back to the resource, etc. This happens 8 times after which i'm redirected back to the sign in page. Is there an event I can put a breakpoint into to see what the issue is?
  2. I was extending the ClaimsAuthenticationManager with a custom implementation in order to pull user-data from my local database and enrich the ClaimsPrincipal. At the same time I extended the RoleProvider to check for custom roles. These objects were instantiated as part of the standard pipeline with the identity model (and the [Authorize(role,role,role)] attribute). This was done via web.config and a custom entry for the <claims.identityModel><identityConfiguration><claimsAuthenticationManager> element. How do I tie in my custom authentication/authorization code into the WSFederation pipeline?
__EDIT: Issue #1 is now resolved by following this suggestion: but Issue #2 is still relevant. __
Jul 8, 2014 at 2:04 AM
Looks like my problem would be solved by using the OnAuthenticated and OnReturnEndpoint events that exist in all providers except the WsFederationAuthentication. Should I be using MicrosoftAccountAuthenticationProvider with windows azure active directory instead of WsFederationAuthentication?

Jul 8, 2014 at 2:16 AM
Did more digging, looks like Notifications.SecurityTokenValidated is the entry way into the pipeline to do what I need with the claims and roles. Why the difference with the other providers?
Jul 8, 2014 at 5:01 AM
Yes, that's a good point to modify claims.

As to why this is different from the prior middleware: The WsFederationMiddleware and OpenIdConnectMiddleware are a new generation where we are trying to improve on the design. We'll have an opportunity before the next release to see how people like the new model and reconcile them.
Jul 8, 2014 at 4:54 PM
Thanks for confirming! I'll chime in if I run into any issues :)
Jul 8, 2014 at 10:14 PM
Final implementation using 3.0.0-RC1 (to help get started for someone else) with WS-Federation.

Authentication configuration below. If someone is getting errors when signing out verify that SignOutWreply matches what you defined in the Reply Url section in the windows azure portal.
private static void ConfigureAuth(IAppBuilder app)
            app.UseCookieAuthentication(new CookieAuthenticationOptions());
                new WsFederationAuthenticationOptions
                    MetadataAddress = ConfigurationManager.AppSettings["owin:MetadataAddress"],
                    Wtrealm = ConfigurationManager.AppSettings["owin:Wtrealm"],
                    SignOutWreply = ConfigurationManager.AppSettings["owin:SignOutWreply"],
                    Notifications = new WsFederationAuthenticationNotifications()
                        SecurityTokenValidated = notification =>
                            AddUserClaims(notification.AuthenticationTicket.Identity); //custom method to add claims to ClaimsIdentity object.

                            return Task.FromResult(0);

Signout controller action.
        public void SignOut()
Really need a good set of samples and/or documentation for these libraries.