Mine is a web product (delivered to a browser), being built on ASP.Net (Framework 4.0).
Most customers seek Single Sign On, such that their users should directly logon to the application on its invocation with the Windows or Active Directory login, they're using. Some other customers want the application to accept form based login credentials. So basically my web application should be able to adjust (configured) based on the customer's requirement. Their may be claims based authentication is some stray cases as well. I'd like to know the best way to achieve this in ASP.Net.
.NET open auth is your friend.
http://www.dotnetopenauth.net/
Then, there's active directory/LDAP:
http://www.codeproject.com/KB/system/everythingInAD.aspx#35
And your own provider + WinForms should be clear.
Related
I am working on a .NET 6 ASP.NET website and looking at implementing authentication using the identity framework. I understand this is technically working as a middleware and is independent of the subsequent IIS deployment authentication setting (only anonymous needs enabling).
On the IIS authentication setting I can various authentication options, one of which is called Forms Authentication.
I want to ask whether there is any relation between .NET Web Forms (or Windows Forms) project and the IIS Forms authentication? Or is it just a co-incidence that they both have the Forms keyword? I am confused because - like Web Forms project, even older ASP.NET MVC project required the Form Authentication enabled upon deployment to IIS. Where as newer .NET MVC project don't require this IIS deployment setting if they are using the Identity framework.
The latest authentication mechanism is called Identity framework. What was the older authentication mechanism technically called? Forms auth framework?
want to ask whether there is any relation between .NET Web Forms (or Windows Forms) project and the IIS Forms authentication?
Don't bring windows forms into this!!
But, yes, so called FBA (forms based aunthetiicaion) is not really realited to web forms in any speical way. They just happen to both have the name "forms" in their name - nothing more, and nothing less. So, using FBA in web forms applciations was a long time common choice.
Is there a relationship bettween FBA and IIS? yes, because if you adopt FBA, then your web site security is managed using that security provider. This useally means you have the "role" provider and FBA provider.
so, then each folder of the web site can then be secuired using web.config. You can either secuire those pages to require a valid logon (based on FBA), and you can also pick and choose what roles (so, some parts of the site say can only be used with say a role of "Sales" group.
However, while the web forms site can adopt FBA, the valuable informtion is that IIS will respect that that authneticaion provider - and thus IIS "knows" and "respects" that secuirty provider choice. That means say if you hit a web page that requires logon, then IIS will automatic intercept that page - send you to the logon page, and after you logon, you can continue on to that secured web page.
However, you don't have to use FBA with IIS, there are of course other secuirty and logon providers you can use. However, you do want to use a supported and started one, since then you can use the built-in asp.net logon controls etc, and they will just work.
What was the older authentication mechanism technically called?
FBA -- Forms based authentication. As I stated, the fact of "forms" in that name FBA has no specials meaning in regards to web forms, or using web form applications.
You are thus as noted are free to adopt newer security providers - web forms are of course not limited to using FBA as the security provider.
even older ASP.NET MVC project required the Form Authentication enabled upon deployment to IIS.
Hum, did they? I don't think that is the case. If you don't want or need web site logons or security then I do not believe that FBA was any kind of requirement to be enabled at all to deploy a web site that does not have nor use security.
I am aware of ASP.NET Authentication using Identity. So, if my application already has Authentication enabled, why would I want to enable IIS authentication on top of that?
Also, if I have both enabled, will that require a user to type in his or her credentials twice (once for the application login and then for the IIS login)?
Both are different things altogether.
ASP.NET Authentication using Identity in your web application is used for authentication & authorization of End-User in your application.
IIS authentication is for security and access management for hosted application.
If we explore a little further why this is needed. End-user just need to rights for viewing data & doing operations using User Interface Screen.
IIS user(used for IIS autehntication) might need right for creating schema, modifying schema as in Continuous Integration (CI) when you deploy code, new schema is created or existing schema can be modified.
Also in multi-tiered application, we can choose to run service(web services, web API, WCF
etc) under end-user authentication if needed OR user with more rights is required.
All decisions depends on your architecture, needs & security requirements. No choice is good for all architecture needs. We need to choose what suits our requirement best in given scenario and we design in such way application is further extensible/scalable for higher loads and easier for maintaining code too in long support.
I have an older ASP.NET (.NET 1.0) web application that is using Windows authentication. We want to remove the Windows authentication since the AD server for this particular web application needs to be decommission. We want to keep some type of authentication for this older web-application. I am thinking this leaves us with Forms and Passport authentication modes (but not sure of support in a .NET 1.0). I am trying to avoid a major rewrite since the web-application is not being used much anymore (only being used by one user). Any idea of a quick and simple solution to remove Windows authentication to something else for authentication?
If the domain controller is to be decommissioned I take it the entire office will reverted back to a domain-less workgroup environment. I also take it all workstations will be configured to leave the domain prior to destroying the domain controller once and for all.
Since it's only down to one user for a web application that has little value in enhancement, you may be able to get away by creating the very same user account with the same password on the web server. That way when s/he accesses the web app on that server, the Windows authentication mechanism will attempt to negotiate as SERVER\username in the local SAM store instead of relying on the previous DOMAIN\username account.
I have an asp.net application which signs users in manually. The custom authentication procedure checks several data sources and finally sets a forms authentication ticket for the user, if he is successfully authenticated.
I want to share this ticket with sharepoint 2010. I will not be signing in through sharepoint, so there is no need for authentication procedure to caried out on the sharepoint side.
I have tried using claims-based authentication on the sharepoint side, but don't really know how to set it up, since I do the authentication manually on the asp.net application.
I endded up going with STS. Works very well. There is an MS devkit that has some templates for VS2010 that get you going very quickly.
I was tasked with creating an SSO solution from an existing asp.net app to a new sharepoint 2010 app.
The existing asp.net app uses forms authentication, but not against a single data source. It checks a database, active directory and a few mainframe tables to authenticate, and finally creates a forms authentication ticket.
I was looking to share the token between sp2010 and the asp.net app, but I am now realizing this is not possible, due to the fact the sp2010 does not use simple FBA tokens any more.
So now I am looking to go the STS and claims-based route. After looking in to it a little, I understand that using ADFS would be much better than building a custom STS for the asp.net side. My issue is that since I have the custom ticket creation authentication method on the asp.net side, I don't have a single data source to "feed" the adfs. I am new to sharepoint and adfs and I really don't know how to begin this type of integration.
Can anyone help me get my head around this?
Thank you!
ADFS attribute stores might solve your problem, although for this to make sense you would ideally integrate Windows Identity Foundation (WIF) into your application, which might be an intrusive change.
http://technet.microsoft.com/en-us/library/adfs2-help-attribute-stores(v=ws.10).aspx
In short, ADFS is not limited to AD for collecting user data. You can configure it to query other user attribute stores, such as your database. You can then author rules within ADFS to tell it what queries to make, and ADFS will use these queries to populate user claims into the token that ADFS issues to your application.