2 Projects,Login Page - asp.net

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.

Related

Web-App automatically choose Login method: WIF-ADFS or manual

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).

Using WIF against different ADFS services

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.

Shared Authentication between applications

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.

Implementing Single Sigon for ASP.NET and Classic ASP websites

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.

Is it possible to validate an ASP.NET Forms Authentication ticket in ISA/UAG (or similar) and do redirects based on the result?

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.

Resources