I am using OWIN-MixedAuth to authenticate website users. Running it locally with VS2015 on a Win10 mahine everything is fine. Deploying it to the productive Windows 2008 R2 server within an AD domain the User.Identity isn't a ClaimsIdentity, it is a WindowsIdentity missing the NameIdentifier claim and GetuserId returns null.
In Startup.Auth.cs I set the following cookie options. The login path points to "account/windowslogin" as recommended here.
var cookieOptions = new CookieAuthenticationOptions {
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString(ConfigurationManager.AppSettings["LoginPath"]),
Provider = new CookieAuthenticationProvider {
OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, IdentityUser, Guid>(
TimeSpan.FromMinutes(30),
async (manager, user) => await user.GenerateUserIdentityAsync(manager),
(id) => new Guid(id.GetUserId())),
}
};
Any ideas why IIS 7.5 is acting differently here?
Cheers
Bernd
Related
We are implementing Azure AD Authentication in ASP.NET MVC 5 using Open ID Connect. When the application was running on premise we had windows Authentication, so there is no login page or Login button.
We have put [Authorize] attribute to all the controllers so that the user is authenticated before accessing the page. Below is the code in start up Auth.
app.UseKentorOwinCookieSaver();
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = "Cookies",
CookieManager = new Microsoft.Owin.Host.SystemWeb.SystemWebChunkingCookieManager()
});
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions
{
ClientId = clientId,
Authority = authority,
PostLogoutRedirectUri = postLogoutRedirectUri,
RedirectUri = RedirectUri,
ResponseType = OpenIdConnectResponseType.Code,
Notifications = new OpenIdConnectAuthenticationNotifications()
{
AuthenticationFailed = (context) => {
context.HandleResponse();
return Task.FromResult(0);
}
}
});
But we are facing the Infinite loop once the user is authenticated. And I tried all the solutions on internet, but my issue is not solved.
https://stackoverflow.com/a/37666371/55775
https://github.com/Sustainsys/owin-cookie-saver
https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues
ASP.NET_SessionId + OWIN Cookies do not send to browser
asp.net mvc azure AAD authentication infinite loop
I have a web forms app which I am trying to authenticate against Azure AD using SAML 2/Kentor/Owin. I think I have things configured OK, but when my login page issues the following command I am not being redirected to a login page.
HttpContext.Current.GetOwinContext().Authentication.Challenge(new AuthenticationProperties { RedirectUri = "/Login.aspx" });
Here is my startup.cs
private void ConfigureSAML2Authentication(IAppBuilder app) {
var authServicesOptions = new KentorAuthServicesAuthenticationOptions(false)
{
SPOptions = new SPOptions
{
EntityId = new EntityId("https://login.microsoftonline.com/<tenant guid>/saml2")
}
},
AuthenticationType = "KentorAuthServices",
Caption = "ADFS - SAML2p",
};
authServicesOptions.IdentityProviders.Add(new IdentityProvider(
new EntityId("https://sts.windows.net/<tenant guid>/"),
authServicesOptions.SPOptions)
{
MetadataLocation = "https://login.microsoftonline.com/<tenant guid>/federationmetadata/2007-06/federationmetadata.xml",
LoadMetadata = true,
});
app.UseKentorAuthServicesAuthentication(authServicesOptions);
}
As far as I can tell looking at the Network Tools in chrome, no auth request is being sent at all. Is anyone able to tell me why?
The AuthServices middleware is configured as Passive by default, so it will not automatically respond to an authentication challenge unless you specify the provider.
When you issue the challenge you should specify the same AuthenticationType that you used when the middleware was set up. By default this is "KentorAuthServices" but can be changed.
If you change your challenge to include the type, it should trigger the redirect:
HttpContext.Current.GetOwinContext().Authentication.Challenge(new AuthenticationProperties { RedirectUri = "/Login.aspx" }, "KentorAuthServices");
Here the identity class for authentication. it works fine on my localhost but it's behaving strange after deployment on server.I used OWIN for authentication, it works fine for first login, but after few seconds if I refresh the page, it redirects me back to the login page.
public class IdentityConfig
{
public void Configuration(IAppBuilder app)
{
app.CreatePerOwinContext<AppDBContext>(AppDBContext.Create);
app.CreatePerOwinContext<AppUserManager>(AppUserManager.Create);
app.CreatePerOwinContext<AppRoleManager>(AppRoleManager.Create);
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/Account/Login"),
Provider = new CookieAuthenticationProvider
{
// Enables the application to validate the security stamp when the user logs in.
// This is a security feature which is used when you change a password or add an external login to your account.
OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<AppUserManager, AppUser>(
validateInterval: TimeSpan.FromMinutes(15),
regenerateIdentity: (manager, user) => manager.CreateIdentityAsync(user, DefaultAuthenticationTypes.ApplicationCookie))
},
CookieName = "MyCookie",
//CookieDomain = "www.example.com",
//CookieHttpOnly = true,
//CookieSecure = CookieSecureOption.Always,
ExpireTimeSpan = TimeSpan.FromMinutes(double.Parse(ConfigurationManager.AppSettings["app:SessionTimeout"])),
SlidingExpiration = true
});
}
}
Here the web.config code of search4best used for session timeout
<add key="owin:AppStartup" value="Search4Best.App_Start.IdentityConfig" />
<add key="app:SessionTimeout" value="15"/>
on web.config try this
<machineKeyvalidationKey="F18753F2CF84EFFFB10600B1E29D9849A74F080A1E1170BF728D8381979271EF6894673001C877FD8A349F8D953024019AF6C4C5090309B4569C1933ECC90D94"
decryptionKey="504430FBB7D426A3C401600906CD5C121DC0808B0D40328E02EAF7A59652157B"
validation="SHA1" decryption="AES"/>
I have a web application that uses ACS to federate multiple identity providers which I'm trying to migrate to use OWIN. I have a custom login page in a separate application (that shares a SSO experience with mine) which I was able to specify using the issuer attribute in the wsfederation configuration element in my existing pre-OWIN setup.
I've tried to replicate this behaviour using OWIN, but no matter what I try, an unauthenticated request is redirected to the standard (ugly) ACS login page. Here's how I've configured the middleware components:
app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
AuthenticationMode = AuthenticationMode.Active,
Provider = new CookieAuthenticationProvider
{
OnResponseSignIn = ctx => TransformClaims(ctx.OwinContext.Authentication.User, loggingService)
},
ExpireTimeSpan = TimeSpan.FromMinutes(int.Parse(ConfigurationManager.AppSettings["security:slidingExpirationMins"])),
SlidingExpiration = true,
});
app.UseWsFederationAuthentication(
new WsFederationAuthenticationOptions
{
AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
MetadataAddress = "https://mylogin.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml",
Wtrealm = siteUrl,
Wreply = siteUrl,
AuthenticationMode = AuthenticationMode.Active,
});
The LoginPath property of the CookieAuthenticationOptions object won't work as it's not in the same application.
Any help with how I would specify the external login URL would be appreciated!
I would recommend setting to Passive the WSFederation middleware AuthenticationMode, otherwise it will keep intercepting outgoing 401s.
So I have a solution that is using Microsoft.Owin.Security.WsFederation 3.0.0-rc2 and I'm trying to get Passive sign-out calling back to the identity provider to log out of there as well as my application (so I don't get a redirect loop just logging it back in).
I'm currently using WAAD as the WS-Fed endpoint.
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/login")
});
app.SetDefaultSignInAsAuthenticationType(DefaultAuthenticationTypes.ApplicationCookie);
app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);
app.UseWsFederationAuthentication(new WsFederationAuthenticationOptions
{
AuthenticationMode = Microsoft.Owin.Security.AuthenticationMode.Passive,
AuthenticationType = WsFederationAuthenticationDefaults.AuthenticationType,
Wtrealm = ConfigurationManager.AppSettings["WSFEDRealm"],
MetadataAddress = ConfigurationManager.AppSettings["WSFEDMetadataAddress"]
});
I can get it working fine if I use active but it would be nice to have the option of using passive as well.
I am signing out using:
_authenticationManager.SignOut();
I think it has something to do with these lines in the signout helper
if (revoke.AuthenticationTypes == null || revoke.AuthenticationTypes.Length == 0)
{
return authenticationMode == AuthenticationMode.Active ? revoke : null;
}
But I'm unsure of how I add to the revoke.AuthenticationTypes dictionary?
A potential solution is to manually force the signout1.0 request
var wsConfiguration = await _wsConfigurationManager.GetConfigurationAsync(HttpContext.GetOwinContext().Request.CallCancelled);
var message = new WsFederationMessage
{
IssuerAddress = wsConfiguration.TokenEndpoint,
Wtrealm = ConfigurationManager.AppSettings["WSFEDRealm"],
Wreply = Url.Action("Index", "Home", null, Request.Url.Scheme),
Wa = "wsignout1.0"
};
I then have a binding in my ninject module for the wsfederation configuration
Bind<IConfigurationManager<WsFederationConfiguration>>().ToMethod((c) =>
{
var owinContext = HttpContext.Current.GetOwinContext().Authentication;
return new ConfigurationManager<WsFederationConfiguration>(ConfigurationManager.AppSettings["WSFEDMetadataAddress"]);
}).InSingletonScope();
I'm not 100% happy with this solution as it means there are two running configuration managers for the metadata, but it is a working solution.