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.
Related
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).
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.
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.
Technology
ASP.NET, VB.NET 2.0 (soon to be 4.0)
Overview
I'm writing a Login / Authentication Portal, so that a web application can use it to login a user, and then they can use the application using their credentials.
The login portal will be a separate application, and initially only available via an extranet as well as intranet for certain applications; but future apps will need to authenticate via the web (happy to implement as a separate instance). I basically want other individual applications to be able to authenticate users via this portal.
So that...
A user goes to an application's web url (i.e. www.application.com / http://apps/application - intranet) and clicks "login".
User's browser is redirected to the portal application, with a query
string
www.loginportal.com/login.aspx?url=www.application.com/login.aspx
(or other page).
User fills in their credentials (username, password), and clicks
"login" button.
Browser redirects back to url i.e. www.applications.com/default.aspx or login.aspx and is authenticated and logged in; and can use app.
Completed
I have the authentication itself sorted, and will implement as a class library in the local applications via a dll.
Need
So I basically need to know, how to:-
1. Post data to the portal url (could be different domain).
2. Redirect browser with post.
3. Make sure that the authentication is secure, and not easily hackable (I know how to use urlencode and htmlencode etc) - just not sure about implications of posting data across domains.
Any help greatly appreciated...
Cheers,
Duncan.
Seriously tough stuff, here. If it were me, I'd lean heavily on Windows Identity Foundation. I believe it can support this scenario (haven't actually done it; someone else at my company is developing against it).
OK, so this is the solution I ended up using:
In the original application (the one that needs the authentication; step 1 above) I redirect the user to my login portal, and include the original url as a get parameter.
The user then types in their details, username and password.
Next, the server-side code authenticates them, and redirects to a new page, where I send back to the page an html form which includes the request datetime (for security) along with a encrypted string (including the datetime of the request) of the data I want sent back to the original form.
I also add a JavaScript post method which sends the data to the original url as a form post. Because I'm using the same class library at both ends, I can encrypt and decrypt the data using the same method and the original requesting application has all the user data, including the ability to check the datetime of the request (I allow a set amount of time between the authentication and the picking up by the original app, making sure these are within say 5 minutes.
And job done.
If anyone wants the code, I can provide it, just don't have it with me at the moment, if I remember I'll post it.
Not the most elegant solution, but it works, and it's secure, so I'm happy. :).