I am developing a website using asp .net and i give the users two possibilities to log in.
The first is using WIF-ADFS and the second is through manual input.
The thing is, i want the application to check whether it is possible for a certain user to use SSO.
If yes, do SSO, if no, make the application choose the second login possibility automatically.
The question is whether it is possible to implement my application to do that.
The short answers is: probably not if you do not have a "list" of all users with all of their authentication options/methods. There for you have to present them the options (aka WAYF or HRD)....
WIF + ADFS use WS-FED, and the implementations have no graceful fall back. The ADFS server just display an error page. The older ADFS version had some limited options to fix it. The newer ADFS on S2012R2 cannot be extended/customized (except when it is possible in JavaScript on the client side).
If a user want's to log in you have at first no automatic mechanism to determine if he can do SSO (besides you can control all browsers in question and add something to their UserAgent) or not.
So all what is left is to display a form for login with local data and some buttons for login with ADFS or Google or Facebook or whatever.
Microsoft does this in Azure Authentication Services, Thinktecture supports it with the IdentityServer (I think) and MVC has a template for actions like that (and you can use ASP.NET Identity V2 with that).
Related
I have tried to search for this, but haven't found any good answer for it, so I'll put out a question here!
I have a web site that several different customers want to access using their ADFS own service. My plans was then to have the connection to the different ADFS services in a centralized storage (not config files) and retrieve the correct one based on some parameters the customer provides to the web site and use it with code.
However, I cannot find any way to let one web site use several federation services. Is this method possible at all using WIF and ADFS? If so do you have any links or examples on how to do it?
This is possible, what you need is to create different requests depending on different user choices.
My practice is to have a bunch of buttons/links somewhere in the application (at the login page perhaps). Each button is dedicated to one external STS (ADFS in your case). Clicking the button creates the wsignin1.0 request to the server and when the ADFS returns to the login page, there should be a block of code to try to consume the response (SAML token) and create identity for current session.
This was easier in the past as WIF supported the wif:FederatedPassiveSignIn web control. All you needded was a buch of these at your page, each single control poiting to its ADFS:
<wif:FederatedPassiveSignIn id="adfs1" runat="server" Issuer="https://adfs1.adfs/adfs/ls" Realm="https://yourapp/loginpage.aspx" ImageUrl="adfs1.png/>
<wif:FederatedPassiveSignIn id="adfs2" runat="server" Issuer="https://adfs2.adfs/adfs/ls" Realm="https://yourapp/loginpage.aspx" ImageUrl="adfs2.png" />
However, for some unknown reason the control has been removed from the .NET 4.5 version of WIF, thus making this much more difficult. Few months ago I've recreated this for .NET 4.5, the code is freely available:
http://code.google.com/p/net45federatedpassivesignin/
If you don't want to use this (for example because you are on MVC and/or you don't like web controls), you can still dig into the code to see how the ID of specific control is passed to the selected ADFS so that when the response comes from the ADFS, only the source control (the one that sent the request) consumes it (this involves using the wctx optional parameter of a wsignin1.0 request).
Edit: another option you might consider is to have a single ADFS playing the role of a relying STS. In such environment, your application talks to a single adfs and this adfs is federated with a bunch of other adfses. This is even easier to set up as it only requires proper configuration. A user trying to authenticate is redirected to the relying adfs and the adfs shows the HomeRealmDiscovery page where the user selects the target adfs from a list and proceedes to authenticate there.
We have two old websites in Classic ASP and few websites in ASP.NET 2.0. Our new development is in ASP.NET as well and gradually we might be moving our Classic ASP sites to .NET as well. All these websites use same back-end database.
For now we are planning to move our user authentication to a single server and start using Single-Sign-On(SSO). I am not able to decide what would be the best or right way. Our asp.net websites uses FormsAutentication with CustomMembership and RolesProvider i.e. we use our custom tables instead of default aspnet_membership tables.
Ways I can think:
1: Use Webservice: I can move the authentication code to a webservice and all of our sites can use it. But I am not sure how the Single-Sign-on fits in when we have ClassicASP sites involved.
2: I heard of DotNetOpenAuth: Our external users are created by our internal staff. They can only login using the username/password we provide. So they cannot login using Google,Yahoo or any other username/passwords. So I am not sure if DotNetOpenAuth fits in our case. I saw SSO sample in DotNetOpenAuth download but have no clue how to begin.
If anyone can point me in right direction please. I have gone through various articles and docs but not getting a clue where to begin.
Well, it could be that one of passive single sign-on protocols could be your choice. You can choose between the WS-Federation, SAML protocol or Shibboleth but the first one, WS-Federation is easily supported on .NET with the Windows Indentity Foundation subsystem.
The way WS-Federation works is that it you externalize the authentication/authorization to a separate web application (so called Security Token Service). Each of federated client applications (so called Relying Parties) rely on the information provided by the service.
The basic control flows is like this:
the client points his/her browser to a RP application
the browser redirects (302) to the STS
if STS was visited and the user is already logged into the STS go to 5.
STS shows the login page and validates the user
STS returns to the browser a page containing a signed XML token with all the auth information as well as a tiny javascript to redirect to the RP application
the RP application picks up the token and creates its own authentication based on the provided information
WIF gives you tools to build both STSes and RPs easily and integration of legacy application is also simple - you can either make an effort to handle the protocol at the legacy application level or provide a "brige", a .NET application using WIF which relies on STS and passes the auth information to the legacy application.
What is also great is that with WIF you still stick with old, good notions like Forms Authentication and Membership Providers - it could be a preferred choice of STS implementation.
The WS-Federation protocol itself not only provides the single sign-on but also lets you easily handle single sign off (which is not supported by some other protocols like openid).
Read more on the topic in this book:
http://www.amazon.com/Programming-Windows-Identity-Foundation-Dev/dp/0735627185
Checkout this guide on "Claims-based Identity and Access Control".
The chapter 3 especially: "Claims-based Single Sign-on for the Web and Windows Azure" (Azure is not a requirement).
It well explains the modern Microsoft's way of implementing a single sign-on strategy.
Plus, this TechNet article helped us a lot to get started with WIF and ADFS 2.0.
Can 2 projects in one solution share the same login page and web.config
under one solution? I have 2 UIWebProjects, 2class libraries for the Business layer and Data Access Layer.
What you are trying to achieve is named Single Sign On - Single Sign Off scenario.
There are many ways to incorporate SSO in asp.net application , however i would recommend to use WIF (windows identity foundation) as it is part of Microsoft stack for SSO which will also allow you to use other means for SSO like SAML2 or AD etc
you will need to implement one identity provider( IdP , STS in WIF terms) web site and two service provider web sites (or you can use one website as both IdP and SP however i would separate it.
here is an article to begin with, also google WIF and lookup WIF tag on stackoverflow
What you're looking for is called single sign on (or cross site authentication). Here are some resources:
ASP.Net Cross-Site Authentication
http://www.codeproject.com/KB/aspnet/CrossDomainSSOModel.aspx
I dont think so, never done it.
But you can call one login page from both the application and depending upon the call, redirect url to the respective application page.
I'm writing an internal web application right now (with ASP.Net Web Forms), and it presents an odd problem. I have to be able to impersonate the currently logged in windows user, and execute a command based on their Windows Authentication to log in.. AND ... if they don't have Windows Authentication set up in the application I have to use to log them in, I have to be able to accept a user name and password. I also have to write the application in .Net 4.0, and secure it as much as possible. I got this to work by NOT utilizing Windows Authentication or Forms Authentication in the web.config, and instead setting session variables to guard against user accessing pages in the web app other that the log in. I did this by creating an oddly name session variable with a value based on their user name (windows auth or not), and then a secret session variable. The secret variable is in the web.config as a 256bit encrypted string, in which I decrypt, and set as the session secret. In order for the page to load, the first session variable can't be blank, and the second variable has to equal the decrypted key value... if the variables don't pass inspection, it redirects them to the login page. I set this up on every page, generic handler, and webservice method in the web app. I make the session timeout after a few minutes of no activity, and on log out, I set all session variables to nothing, and expire all cookies. (I also disable all cache).
My question is... Does this offer comparable security to that of Forms authentication? I have always used Forms authentication, but can't use it here. If I did, the users would have to reconfigure settings in IIS and in he web.config to toggle login procedures (From my knowledge, you can't use both Forms authentication, and windows authentication to manage the security of your pages and other web resources). With the method described above, I can accomplish the best of both worlds, but am curious about the security of my methods. Is there anything else I can implement here to assure the utmost security other that using forms authentication? Is it possible to accomplish the same level of security of Forms authentication without using it?
Thank you for any insight in advance!
Does this offer comparable security to that of Forms authentication?
No
The first rule when it comes to security is don't reinvent the wheel unless you absolutely have to. Any home baked solution you come up with has the potential to be as secure as a provided one like Windows or Forms Authentication. The problem is that home-grown solutions rarely reach that potential. They may test okay, but subtle bugs can remain. You don't want to find out a year later that you were hacked six months ago. Existing solutions have already been tested and used in millions of applications, whereas yours will be used in one application and tested by a handful of people at most.
A quick search suggests that it is possible to implement both Windows and Forms Authentication in the same application, so I'd pursue it further.
Mixing Forms and Windows Security in ASP.NET
We have an ASP.NET MVC application that uses Forms Authentication to create and validate the authentication ticket (cookie). The log on flow is very special, not just username/password, but it ends with a call to FormsAuthentication.SetAuthCookie(userId, false) to create the cookie. So a standard cookie is created, it is just how it is created that is special.
We will also have to integrate with a couple of other web sites that are not neccessarily .NET based or not possible to customize via some kind of Single Sign-On that do not require any modification on the other sites. All sites are behind the same UAG/ISA Server.
Is it possible to setup some kind of filter in UAG/ISA Server that can validate the Forms Authentication cookie created by the ASP.NET MVC application? If it is not OK it should redirect to the log on page in that application? If it is OK it should just let the request through. For example, would it be possible to use a ISAPI filter with UAG that does this? We can use the same machineKeys on the UAG server and the ASP.NET app server (I guess that is required to start with)
I don't know much about UAG and I'm also interested in alternatives to UAG. In fact, what we really need is just something that works as a perimeter protection for all those sites and that can utilize the already existing log in flow/cookie.