I have three asp.net applications. Only one of them has a forms authentication login. I redirect anonymous users to that one login page for all three applications to login. Once they log in, they automatically redirected back to the application and page they were attempting to access.
I enabled this functionality by setting the same MachineKey in all three applications.
Is there a way to do this for ADFS 3.0 WIF authentication as well? It doesn't seem to work the same in my testing. When I log into the application that is wired up to ADFS, I still can't access the other two.
WIF and ADFS don't work the same way as traditional forms authentication. These technologies rely on issuing access tokens, and require that dependent applications (also known as Relying Parties, or RPs) configure a trust relationship with the token provider (AKA Identity Provider, or IP). You can't share the cookie with MachineKey between apps that have not directly authenticated with an IP, and to be quite honest you don't want to.
The typical web scenario (also known as Passive Federation) is to have a separate application that functions as a Security Token Service (STS). This application houses the Login.aspx page and is protected with Forms or Windows Authentication like you would find in a classic ASP.NET scenario. When you attempt to access a web application that requires authentication, it needs to be set up to redirect you to the STS website, rather than handling it by itself. Once you log into the central STS, it will issue you a token that you then provide to applications to gain access. If you use WIF properly, this is all handled behind the scenes and is just a matter of configuration.
Each of your three web applications should be configured with a trust relationship to your IP. You said that you have a web application wired up to ADFS already, if that's via the proper trust relationship, then you should simply have to replicate that set up to your other 2 applications.
Related
I've been assigned to find a way of implementing SSO in our products. We have several Winform applications and one asp.net 4.0 web app (not MVC).
All the products are built using .Net 4.0, the web app is ASP.NET 4.0.
Some of the Winforms are commmunicating with our API via web services (asmx) and some uses our API directly. The web app is using the same API as well. We offer a set of web services (asmx) that uses the same API to external clients.
Currently we have our own authentication implementation (user, password, roles) in our systems and we would like to replace that with SSO. Or can these two authentication regimes co-exist somehow? The Winforms are used in intranets and the web app is used both in intranets and we also hosts the web apps for clients (accesible from the Internet).
The users are created in our system, but at the same time we import users from Active Directory using our own tool. Active Directory is really the primary user source.
I have read about Windows Identity Foundation and I wonder if I can use that to implement SSO. But what I don't understand is how to use WIF in the winform applications when they use the API directly.
What I would like to achieve is to remove all user administration from our system and use Active Directory as the user source. I guess that means using ADFS 2.0 to create claims, etc.
I can use .Net Framework 4.5 in this implementation (I know that WIF is now a first class citizen in .Net Framework 4.5).
Do you have any advices how to do this? Is WIF the best alternative to achieve SSO across winforms applications and web apps?
There is a way to get the WIF authentication cookie from within the WinForms application.
To do it, you just host the WebBrowser control and point it to the login page of your web application. Assuming the web application is federated with the ADFS2, the web browser control will automatically follow the flow - it will redirect to ADFS and stop there to show the prompt for user credentials (ADFS2 in Forms Authentication mode) or just authenticate using NTLM/Kerberos (ADFS2 in Windows authentication mode). Then the web browser will redirect back to your application.
This is where you hook your code. You just add a handler to the web browser's navigation event and you check when it comes back to your application AFTER ADFS2.0 authenticates the user. You can then call the InternetGetCookie method in the WinForms app to get all the authentication cookies issued by your application and you can close the window which hosts the web browser.
At this point, you have all authentication cookies issued by WIF (the SessionAuthenticationModule) for your application. You can now call your application web services and inject cookies into http calls. The web server will correctly recognize users as authenticated which means that all you have to do is to add proper authorization to your web services (the PrincipalPermission on your web methods should do).
An alternative approach would be to expose WCF services from your web application and guard them with WS-Federation active authentication. The downside of this approach is (in my opinion) that if your identity provider (ADFS) is further federated with yet another identity provider which DOES NOT necessarily implement WS-Trust/WS-Federation then the active authentication will probably fail (because the other identity provider does not implement it) while the passive scenario will still work (a bunch of redirects will sooner ot later end with a page which requires user to provide the credentials but the flow of authentication protocols between consecutive identity providers does not matter).
I am trying to share authentication and authorization between different web applications (asp.net application and a MVC4 Application).
I read that you should set the machine key and those values to be the same between the sites. I have done this and the authentication is working properly.
But now in the MVC Application i want to use the Authorize attribute to make sure users can only see what the are supposed to see. This is not working.
I also checked.
When I call User.IsInRole("Admin") from the ASP.Net application(this is where the login is done) the value returned is true, but then when navigating to the MVC application the same call returns false.
It seems that the roles is not being shared across the application, is it possible to get is working or should i Create a custom Authorize Attribute ?
thanks in davance
The more applications you have, the more problematic it is to share the forms cookie. And ultimately, if two applications are on different domains (something.foo.com and somethingelse.bar.com) this won't work as you can't force your browser to submit a cookie to two different domains.
This only works if you have manual control over your forms cookie and issue it for .yourdomain.com top level domain and you have your applications in subdomains (app1.yourdomain.com, app2.yourdomain.com). And this could be a serious restriction.
What you could possibly do is to externalize your authentication, i.e. create a separate web application with the sole goal to authenticate and authorize your users. You pick one of Single Sign-on protocols (WS-Federation, OAuth2, OpenID) and federate your application environment around this authentication provider.
It possibly sounds difficult, especially if this is new to you but if you invest your time, there are only benefits.
I have an ASP.NET web application that is entirely protected by Forms Authentication.
Is there a configuration under which web requests coming from another application on the same machine, either web or console, can bypass the form authentication and access the page as if it were authenticated?
#merlin2011,you have two chose.
1.use cookie with same machineKey in the different application.(simplest)
the Forms Authentication in ASP.NET use cookie to Encryption and decryption your identity and indicates whether you are logged.the application use different key to encrypt you identity in the different application by default.
see more:
Forms Authentication Across Applications
notes:this solution only for the between application in the same web domain.
(for example,www.example.com,a.example.com,if the www.example1.com will not work)
2.the application in the different web domain(Complex)
in this situation,you need the Single Sign-on solution .this will required you need to write code to authenticate a user whether is logged.
this article will can help you Cross Site Authentication and Data Transfer
good luckly!
We have an ASP.NET web application that we offer as a Service (it's hosted and it's accessible on the Web). We use Forms Authentication and our users have to enter a username/password to connect to our application. Some of our customers ask that we support single sign-on by authenticating users with their own Active Directory.
Our application has a different URL for each customer
www.ourapp.com/client1/
www.ourapp.com/client2/
www.ourapp.com/client3/
and each URL has its own web.config file (where asp.net settings can be specified and can vary for each customer).
What do I have to change in my ASP.NET application to support that?
What do I have to change on my Windows server configuration?
What will the customer have to do on his side to enable that?
Regards,
Check How To: Use Forms Authentication with Active Directory in ASP.NET 2.0 In short, you configure an ActiveDirectoryMembershipProvider to verify each username/password with the customer's AD. The customer must create an AD account for you that is allowed to perform the verification - which may be a problem with some customers. What's more, your code will handle the actual username/password used by users in their internal network, which can be an even bigger problem with customers.
A more secure solution is to use federation (using ADFS) or Claims Authentication using Windows Identity Foundation. In this case you "only" have to set trust relations between your domain and theirs.
I have a fairly complex business application written in ASP.NET that is deployed on a hosted server. The site uses Forms Authentication, and there are about a dozen different roles defined. Employees and customers are both users of the application.
Now I have the requirement to develop a Windows Mobile client for the application that allows a very specialized set of tasks to be performed from a device, as opposed to a browser on a laptop. The client wants to increase productivity with this measure. Only employees will use this application.
I feel that it would make sense to re-use the security infrastructure that is already in place. The client does not need offline capability.
My thought is to deploy a set of web services to a folder of the existing site that only the new role "web service" has access to, and to use Forms Authentication (from a Windows Mobile 5/.Net 3.5 client).
I did see this question and I am aware of the limitations that Forms Authentication poses. Since security is not my primary motivator (I use SSL and can restrict access by IP address), but rather using existing user accounts and roles, my decision tree is somewhat different as well.
Can I do this, is it a good idea, and are there any code examples/references that you can point me to?
I ended up with a combination of things. First, forms authentication does not really work in this scenario, because of the redirects that you get when a users is not logged in or the credentials are incorrect.
Because I want to use the user accounts from the web app, I worked around this by just calling Membership.ValidateUser prior to processing each service call on the server.
A user is prompted for an id and password when logging on to the client. I store both values encrypted in the proxy class and pass them transparently with each call using a host header, so that the application does not have to bother with this once the user is logged in, i.e. the credentials were validated once by calling the Login() service method (which only calls Membership.ValidateUser).
I use the CryptoApi on both the server and the client side.
I understand that host headers are somewhat outdated for security applications, but since I use strong encryption AND SSL, it is perfectly adequate.