I am creating an MVC application with Forms authentication. I have set the application up to authenticate against Active Directory. This works successfully.
I now need my application to consume a Web Api web service within my Domain. When I use Impersonation, the service is never called and object inspection shows the following: The remote name could not be resolved. This is the case for HttpClient, RestSharp and WebClient. If I remove the Impersonation, the code runs successfully (but not as the logged in user).
This throws up a couple of questions:
Can I perform WindowsIdentity Impersonation in a Forms Auth application if the Forms Auth application authenticates against Active Directory?
What is happening to prevent the code from finding my web service when Impersonation is used and how do I resolve this?
Thanks for any help.
Found the answer to my question so posting in case others are stuck with the same issue.
To perform Impersonation when Forms Auth is used you need Protocol Transition with Constrained Delegation. This article is excellent at talking you through the steps required to set this up. Once this is correctly implemented, Impersonation works as expected and the Service URL is correctly resolved.
Related
I've been beating my head for hours on this request.
I have an on-premise installation of an Azure MultiFactor Authentication Server. I'm building a new ASP.Net MVC 5 application that will do an LDAP lookup for users in Active Directory (also on-premise) with no ADFS configured.
I've gone through the sdk for MFA Server and can easily enable SMS requests to be sent. I get the otp code from calling pf_auth.pf_authenticate(authParams, out otp, out callStatus, out errorId);
This works for test. But I need to direct this request to my on-site MFA Server. I can't find anything that tells me where I can set this value.
I know that if I login to a machine on that domain it automatically sends the SMS text to my phone and I can enter it into the next screen to complete a login (the default user portals set up with MFA). I would assume that this would possibly work when I call ValidateCredentials on my application's newly created PrincipalContext. But how do I submit the sms code without some sort of RequestId to synch up the communication.
I'm sorry if this doesn't make much sense. It's just all the examples I can find are for using MFA with a local ADFS. I only have Active Directory which is causing me to do the custom LDAP lookup.
Any help or direction is greatly appreciated.
OK, sorry for the delay in responding to this post. After getting no responses I moved on but have recently noticed that there have been 45+ views since my post and thought I should update for others who might be experiencing a similar issue.
Turns out that when using MFA on premise you can point multiple applications to a single MFA server, like Remote Access, VPN, etc.
However if you are attempting to setup a Web Application hosted on IIS you need to install a copy of the MFA server on the IIS server hosting the application.
When installing you can point to the existing MFA setup so that both machines are in the same configuration. This local install also adds a custom IIS Plugin that does the request interception and directs it through the MFA pipeline. If everything looks good the request is then forwarded to your web application like normal.
This is really pretty straight forward but the documentation for MFA setup was sorely lacking. Hopefully in the future there will be a decent sample app provided by Microsoft that demos this process using local MFA and not just the Azure hosted solution.
I have a WCF service hosted in IIS. I have another website hosted in asp.net mvc. It is a public web site. I want to secure my WCF service so that it won't be accessible from any applications other than my MVC application, or which I give access.
Can I do this using forms authentication?
Update:
I had gone through several examples, but I couldn't get an effective one. I dont want to use ssl. Login feature is not there in my web spplication. If required, a programitic login can be implemented. All I need is, deny access if the service is not called from my website. I've done this in web service using forms authentication. But here, the httpcontext is null.
Yes, you can. WCF calls go through the same pipeline so that if you check for specific principals (usernames or roles), your checks will fail/succeed depending on the Forms cookie.
More details in my blog entry
http://netpl.blogspot.com/2010/04/aspnet-forms-authentication-sharing-for.html
where I show how to share the forms identity between a web app and hosted silverlight app which calls WCF services.
In case of yet another type of the client application, the way you get the cookie value at the client side can vary. Silverlight just inherits cookies from the web application it is run from.
Assuming your client is a console application, you could even expose an unguarded method from the WCF service which accepts loginname+password and returns the cookie to the client. This way, the console application would first call this unguarded method to login the user and then, using returned cookie, would call other WCF services guarded with forms authentication.
We have implemented several intranet web applications in my company. They all:
are built by ASP.NET MVC 3
use CAS(ticket in cookie policy) and a shared LADP server to single sign on
have role based access control logic according to current logon user
expose many RESTful(like) web apis for page's ajax usage
Now we find those web apis for ajax requests can be used as services for other web applications(like employee info, client info etc). Which means we need to access those apis at backend(with C# code). The problem is the authentication and authorization.
I don't know how to go with the existing authentication mode to access those web apis. I can only think of a way that use an shared service credential among back end servers but it means this credential must have a full access authority. Is it a security risk? And as I metioned, we use ticket in cookie policy with CAS. Which is OK for browser but seems difficult for C# code. How to use a credential with CAS from backend? Use a WebClient and handle 302 manually?
Has anyone met a similar case and have some good experiences with this? Please give me some advice. Thanks a lot.
What you need here is to use the CAS proxy mode to access backend web services : https://wiki.jasig.org/display/CAS/Proxy+CAS+Walkthrough.
I have an odd situation occurring that I am trying to diagnose and would appreciate any advice on where to look.
I have an ASP.NET application using WIF that contains another ASP.NET application as a child in IIS 7.5. This child application contains a REST based web service. Accessing this service directly by pasting a URL into a browser will redirect to an ADFS sign in page. This is how I expect it to work. The odd part is that I have a second environment with the same applications and service deployed, and in this environment I am never redirected to the sign in page.
I have checked that all web.config files are identical, and also checked all IIS settings that I thought might be related. Browsing to web pages on the second environment requires a login, but not when browsing directly to the REST .svc file. I checked all HttpModules and Handler Mappings in IIS. I also enabled tracing of Microsoft.IdentityModel events and on the first environment can see a basic entries for a redirect to the STS. On the second environment I don't see any WIF events. The SessionAuthenticationModule appears to be called when I examine the data flow using IIS failed event tracing, but am not sure why it isn't requiring authentication.
I am familiar with cookie related issues with WIF and made sure that all cookieHandler settings were correct. I also closed browser windows and cleared all cookies to make sure the SessionAuthenticationModule wasn't seeing previous WIF cookies.
If you can think of anything else I should check please let me know.
If you have the same application in two separate environments bound to the same instance of ADFS, the URL's must be different so I am puzzled by the statement "all web.config files are identical"?
Have you tried re-running FedUtil on the application that doesn't work?
Also check AppPool settings.
After a lot of trial and error and carefully examining the applicationHost.config files between the two servers I found out this was caused by a difference in the ordering of HTTP handlers. The ExtensionlessUrl-Integrated-4.0 handler was picking up the request on one server and redirecting to ADFS. On the other server the svc-Integrated-4.0 handler was responding to the request first. You can read more about this behavior here: http://support.microsoft.com/kb/2520479
Are there any decent examples of the following available:
Looking through the WIF SDK, there are examples of using WIF in conjunction with ASP.NET using the WSFederationAuthenticationModule (FAM) to redirect to an ASP.NET site thin skin on top of a Security Token Service (STS) that user uses to authenticate (via supplying a username and password).
If I understand WIF and claims-based access correctly, I would like my application to provide its own login screen where users provide their username and password and let this delegate to an STS for authentication, sending the login details to an endpoint via a security standard (WS-*), and expecting a SAML token to be returned. Ideally, the SessionAuthenticationModule would work as per the examples using FAM in conjunction with SessionAuthenticationModule i.e. be responsible for reconstructing the IClaimsPrincipal from the session security chunked cookie and redirecting to my application login page when the security session expires.
Is what I describe possible using FAM and SessionAuthenticationModule with appropriate web.config settings, or do I need to think about writing a HttpModule myself to handle this? Alternatively, is redirecting to a thin web site STS where users log in the de facto approach in a passive requestor scenario?
An example of WIF + MVC is available in this chapter of the "Claims Identity Guide":
http://msdn.microsoft.com/en-us/library/ff359105.aspx
I do suggest reading the first couple chapters to understand all underlying principles. This blog post covers the specifics of MVC + WIF:
Link
Controlling the login experience is perfectly fine. You should just deploy your own STS (in your domain, with your look & feel, etc). Your apps would simply rely on it for AuthN (that's why a app is usually called a "relying party").
The advantage of the architecture is that authN is delegated to 1 component (the STS) and not spread out throughout many apps. But the other (huge) advantage is that you can enable more sophisticated scenarios very easily. For example you can now federate with other organization's identity providers.
Hope it helps
Eugenio
#RisingStar:
The token (containing the claims) can be optionally encrypted (otherwise they will be in clear text). That's why SSL is always recommended for interactions between the browser and the STS.
Notice that even though they are in clear text, tampering is not possible because the token is digitally signed.
That's an interesting question you've asked. I know that for whatever reason, Microsoft put out this "Windows Identity Foundation" framework without much documentation. I know this because I've been tasked with figuring out how to use it with a new project and integrating it with existing infrastructure. I've been searching the web for months looking for good information.
I've taken a somewhat different angle to solving the problem you describe.
I took an existing log-on application and integrated Microsoft's WIF plumbing into it. By that, I mean that I have an application where a user logs in. The log-on application submits the credentials supplied by the user to another server which returns the users identity (or indicates log-on failure).
Looking at some of Microsoft's examples, I see that they do the following:
Construct a SignInRequestMessage from a querystring (generated by a relying party application), construct a security token service from a custom class, and finally call FederatedSecurityTokenServiceOperations.ProcessSignInresponse with the current httpcontext.response. Unfortunately, I can't really explain it well here; you really need to look at the code samples.
Some of my code is very similar to the code sample. Where you're going to be interested in implementing a lot of your own logic is in the GetOutputClaimsIdentity. This is the function that constructs the claims-identity that describes the logged-in user.
Now, here's what I think you're really interested in knowing. This is what Microsoft doesn't tell you in their documentation, AFAIK.
Once the user logs in, they are redirected back to the relying party application. Regardless of how the log-on application works, the WIF classes will send a response to the user's browser that contains a "hidden" HTML input that contains the token signing certificate and the user's claims. (The claims will be in clear text). At the end of this response is a redirect to your relying-party website. I only know about this action because I captured it with "Fiddler"
Once back at the relying party web site, the WIF classes will handle the response (before any of your code is run). The certificate will be validated. By default, if you've set up your relying party web site with FedUtil.exe (by clicking "Add STS Reference in your relying party application from Visual Studio), Microsoft's class will verify the certificate thumbprint.
Finally, the WIF framework sets cookies in the user's browser (In my experience, the cookie names start out with "FedAuth") that contain the users claims. The cookies are not human readable.
Once that happens, you may optionally perform operations on the user's claims within the relying party website using the ClaimsAuthenticationClass. This is where your code is running again.
I know this is different from what you describe, but I have this setup working. I hope this helps!
ps. Please check out the other questions I've asked about Windows Identity Foundation.
UPDATE: To answer question in comment below:
One thing that I left out is that redirection to the STS log-on application happens by way of a redirect with a query-string containing the URL of the application the user is logging in to. This redirect happens automatically the first time a user tries to access a page that requires authentication. Alternatively, I believe that you could do the redirect manually with the WSFederationAuthentication module.
I've never tried to do this, but if you want to use a log-on page within the application itself, I believe the framework should allow you to use the following:
1) Encapsulate your STS code within a library.
2) Reference the library from your application.
3) Create a log-on page within your application. Make sure that such page does not require authentication.
4) Set the issuer property of the wsFederation element within the Microsoft.IdentityModel section of your web.config to the login page.
What you want to do is an active signin. WIF includes WSTrustChannel(Factory) which allows you to communicate directly with the STS and obtain a security token. If you want your login form to work this way, you can follow the "WSTrustChannel" sample from the WIF 4.0 SDK. Once you have obtained the token, the following code will take that token and call the WIF handler to create a session token and set the appropriate cookie:
public void EstablishAuthSession(GenericXmlSecurityToken genericToken)
{
var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;
var token = handlers.ReadToken(new XmlTextReader(
new StringReader(genericToken.TokenXml.OuterXml)));
var identity = handlers.ValidateToken(token).First();
// create session token
var sessionToken = new SessionSecurityToken(
ClaimsPrincipal.CreateFromIdentity(identity));
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
}
Once you have done this, your site ought to behave the same as if passive signing had occurred.
You could use the FederatedPassiveSignIn Control.
Setting your cookie like this:
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
Doens't work for SSO to other domains.
To cookie should be set by the STS not at the RP.