We have a lot of domains running on one IIS WebSite/AppPool.
Right now we are in the process of implementing SSO with Windows Identity Foundation.
in web.config the realm has to be set with
<wsFederation passiveRedirectEnabled="true" issuer="http://issuer.com" realm="http://realm.com" requireHttps="false" />
My problem is that the realm is dependent on which domain the user accessed the website on
so what I did is that I set it in an global action filter like this
var module = context.HttpContext.ApplicationInstance.Modules["WSFederationAuthenticationModule"] as WSFederationAuthenticationModule;
module.Realm = "http://" + siteInfo.DomainName;
My question is. When I set the realm like this, is it set per user instance
or application instance.
Scenario.
User A loads the page and the realm get set to domain.a.com.
User B is already logged in on domain.b.com and presses login.
Since user A loaded the page before User B pressed login, user A will hit the STS
with the wrong realm set.
What will happen here?
If this is not the way to set the realm per user instance, is there another way to do it?
I have already solved the problem.
I set PassiveRedirectEnabled to false in web.config
I set up the mvc project to use forms authentication, eventhough I dont.
I do that so that I will get redirected to my login controller with a return url everytime a controller with [Authorize] is run.
In my login controller I do
var module = HttpContext.ApplicationInstance.Modules["WSFederationAuthenticationModule"] as WSFederationAuthenticationModule;
module.PassiveRedirectEnabled = true;
SignInRequestMessage mess = module.CreateSignInRequest("passive", returnUrl, false);
mess.Realm = "http://" + Request.Url.Host.ToLower();
HttpContext.Response.Redirect(mess.WriteQueryString());
This is definitely not really how it should be, for me it feels like Windows Identity Foundation is lagging behind, both in documentation and microsoft technology wise, no examples for MVC.
For other MVC people i recommend them to not use the fedutil wizard, and instead write the code and configuration themself
Related
I have a test ASP.NET Core 2.0 web application that authenticates the user using SAML. All is well if the URL typed in the browser matches the case of the web app name in IIS 10 (ex. .../MyTestSite). However, if the user types a different case (ex. .../mytestsite) they will fail to authenticate.
In code, the point of failure is in the OnGetCallbackAsync method of the ExternalLogin class at this line:
var info = await _signInManager.GetExternalLoginInfoAsync();
Since info == null in these cases the user is redirected back to the login page.
I have noticed that the .AspNetCore.Antiforgery token has the path value from the url (/mytestsite) but Identity.External path value is the site name (/MyTestSite).
I'm not sure why this happens or why case would even matter.
(Assuming you are using Authentication Schemes)
By default all authentication schemes are case sensitives that is why it matches case while authenticating. If you want to make URL case insensitive you can add routing options like this:
services.Configure<RouteOptions>(options => options.LowercaseUrls = true);
Note: This will provide support of URLs but you can try this.
Hope this helps!
I have an ASP.NET 3.5 application that I recently extended with multiple membership and role providers to "attach" a second application within this application. I do not have direct access to the IIS configuration, so I can't break this off into a separate application directory.
That said, I have successfully separated the logins; however, after I login, I am able to verify the groups the user belongs to through custom role routines, and I am capable of having identical usernames with different passwords for both "applications."
The problem that I am running into is when I create a user with an identical username to the other membership (which uses web.config roles on directories), I am able to switch URLs manually to the other application, and it picks up the username, and loads the roles for that application. Obviously, this is bad, as it allows a user to create a username of someone who has access to the other application, and cross into the other application with the roles of the other user.
How can I mitigate this? If I am limited to one application to work with, with multiple role and membership providers, and the auth cookie stores the username that is apparently transferable, is there anything I can do?
I realize the situation is not ideal, but these are the imposed limitations at the moment.
Example Authentication (upon validation):
FormsAuthentication.SetAuthCookie(usr.UserName, false);
This cookie needs to be based on the user token I suspect, rather than UserName in order to separate the two providers? Is that possible?
Have you tried specifying the applicationName attribute in your membership connection string?
https://msdn.microsoft.com/en-us/library/6e9y4s5t.aspx?f=255&MSPPError=-2147217396
Perhaps not the answer I'd prefer to go with, but I was able to separate the two by having one application use the username for the auth cookie, and the other use the ProviderUserKey (guid). This way the auth cookie would not be recognized from one "application" to the other.
FormsAuthentication.SetAuthCookie(user.ProviderUserKey.ToString(), false);
This required me to handle things a little oddly, but it simply came down to adding some extension methods, and handling a lot of membership utilities through my own class (which I was doing anyhow).
ex. Extension Method:
public static string GetUserName(this IPrincipal ip)
{
return MNMember.MNMembership.GetUser(new Guid(ip.Identity.Name), false).UserName;
}
Where MNMember is a static class, MNMembership is returning the secondary membership provider, and GetUser is the standard function of membership providers.
var validRoles = new List<string>() { "MNExpired", "MNAdmins", "MNUsers" };
var isValidRole = validRoles.Intersect(uroles).Any();
if (isValidRole)
{
var userIsAdmin = uroles.Contains("MNAdmins");
if (isAdmin && !userIsAdmin)
{
Response.Redirect("/MNLogin.aspx");
}
else if (!userIsAdmin && !uroles.Contains("MNUsers"))
{
Response.Redirect("/MNLogin.aspx");
}...
Where isAdmin is checking to see if a subdirectory shows up in the path.
Seems hacky, but also seems to work.
Edit:Now that I'm not using the username as the token, I should be able to go back to using the web.config for directory security, which means the master page hack should be able to be removed. (theoretically?)
Edit 2:Nope - asp.net uses the username auth cookie to resolve the roles specified in the web.config.
We use Sharepoint 2007 as our internal portal. I'm currently developing a custom app (asp.net MVC2) and I've been asked to have the login process mimic Sharepoint, where a user is initially logged in using SSO but then can opt to logout and provide different credentials.
Any blogs/guides on how to do this?
UPDATE:
Thanks to reflector I was able to find a way to do this, but it doesn't totally work.
First off, I'm testing this on IIS running on my local Windows 7 machine.
I have setup the "LogOff" action to do the following:
var current = System.Web.HttpContext.Current;
var response = current.Response;
object obj2 = current.Items["ResponseEnded"];
if ((obj2 == null) || !((bool)obj2))
{
current.Items["ResponseEnded"] = true;
response.StatusCode = 401;
response.Clear();
response.Write("401 UNAUTHORIZED");
response.End();
}
This partially works. When I click "logOFf" I get prompted for credentials. Oddly enough, when debugging, I can see the method gets called twice (this is an MVC action).
But, even when providing valid credentials I still can't log back in. After the third try I get a 401 page.
My only thought here is somehow it's trying to use Kerberos to authenticate and since I don't have Kerberos setup on this machine it fails. But, when I first access the site from IE it just passes me IE credentials on (the SSO) and everything works fine, so I'm not sure why a second authentication fails.
asp.net membership provider is a great choice. There are a lot of options for authentication methods, based on your question though I think the .net membership provider would be your best bet. If you are using simply windows authentication, even sharepoint has its faults as IE will attempt to change the login back to the windows account user.
http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
i have some code that tries impersonate the callers windows security settings and then connect to another WCF service on a different machine
WindowsIdentity callerWindowsIdentity = ServiceSecurityContext.Current.WindowsIdentity;
using (callerWindowsIdentity.Impersonate())
{
NetTcpBinding binding = new NetTcpBinding();
binding.Security.Mode = SecurityMode.Message;
binding.Security.Message.ClientCredentialType = MessageCredentialType.Windows;
EndpointAddress endpoint = new EndpointAddress(new Uri("net.tcp://serverName:9990/TestService1"));
ChannelFactory<WCFTest.ConsoleHost.IService1> channel = new ChannelFactory<WCFTest.ConsoleHost.IService1>(binding, endpoint);
WCFTest.ConsoleHost.IService1 service = channel.CreateChannel();
return service.PrintMessage(msg);
}
But I get the error:
"the caller was not authenticated by the service"
System.ServiceModel .... The request for security token could not be satisfied because authentication failed ...
The credentials I am trying to impersonate are valide windows credential for the box the service is on.
Any ideas why?
In order to support your scenario, you need to have an understanding of how Protocol Transition and Constrained Delegation work. You will need to configure both Active Directory and your WCF service endpoint(s) to support this. Note the use of the Service Principal Name (SPN). Take a look at the following link and see if they help you. The article has a sample to demonstrate the complete end-to-end configuration required to make this work.
How To: Impersonate the Original Caller in WCF Calling from a Web Application
Agree with marc_s this is the double-hop problem.
You need to get the windows authentication all the way through, therefore:
The request must be made in the context of a windows users
IIS must be configured to use windows authentication
Web.config must be set up for windows authentication with impersonate = true
The user that your application pool is running as, must be allowed to impersonate a user. This is the usual place where the double-hop problem occurs.
There is a right called "Impersonate a client after authentication"
http://blogs.technet.com/askperf/archive/2007/10/16/wmi-troubleshooting-impersonation-rights.aspx
Impersonation from you service to the next is a tricky issue, known as "double-hop" issue.
I don't have a final answer for that (I typically avoid it by using an explicit service account for the service that needs to call another service).
BUT: you should definitely check out the WCF Security Guidance on CodePlex and search for "Impersonation" - there are quite a few articles there that explain all the ins and outs of impersonating an original caller and why it's tricky.
Marc
If you are sure you have the credentials right on both hops, the next thing that could be causing the issue is the lack of the EndpointDnsIdentity being set on the endpoint.
DnsEndpointIdentity identity = new DnsEndpointIdentity("localhost"); // localhost is default. Change if your service uses a different value in the service's config.
Uri uri = new Uri("net.tcp://serverName:9990/TestService1");
endpoint = new EndpointAddress(uri, identity, new AddressHeaderCollection());
My ASP.NET site is using Integrated Authentication with impersonation turned off. I have added a "%username" to my "conversionPattern" in the web.config to add the user name to each logging entry. However this will use the application pool identity's user name, and not the current visiting user's name.
Any ideas on how best to do this? Do I have to write a custom appender? I don't mind any minor performance penalties as this is a small intranet site. Thanks!
There's built in ASP.NET pattern converters in recent versions of log4net:
%aspnet-request{REMOTE_ADDR} and %aspnet-request{AUTH_USER}
https://stackoverflow.com/a/7788792/74585
You can also access the contents of
aspnet-cache
aspnet-context
aspnet-session
https://logging.apache.org/log4net/log4net-1.2.13/release/sdk/log4net.Layout.PatternLayout.html
An alternative (and easier) solution you may want to take a look at is to use the ThreadContext class (formerly implemented as the MDC and NDC classes). You could have something like this inside an HttpModule (before the request arrives at your page) or anywhere else before you log your first message:
ThreadContext.Properties["user"] = username;
And then include the following in your conversionPattern:
%property{user}