when to use
windows authentication, form authentication, passport authentication, none?
I don't find on internet any relevant matter on it, although all say how to use these authentication.
But no one says which one is superior and when to use one.
Please elaborate a little on it.
Also i want to know benefit of one over another, and what is that authentication i did by now by creating table with user id and password and match the user id and password with the data table. If that can be done easily what is the need of these authentication.
It depends on the project and what you want to achieve. If you were developing an Intranet for a company obviously only to be accessed from internal computers then windows authentication would be the choice.
If you want people to register and wish to access as much information as possible then use forms authentication to get the data you require and store it alongside membership.
If you want people to come and go from your site with ease with as little steps as possible for registration, then use Passport.
Hope this helps :)
Windows authentication is generally for companies where people do something locally and server checks if the computer that is trying to do something is valid.Example: Company that accepts some requests and people working there do something with them.
Forms authentication is for whole web where you want people to access the content regardless from PC/other device? they are using.Example: Website like this.
Windows Authentication is generally used for Active Directory-enabled networks, such as Intranet sites etc. where the user's Windows credentials double as a login to the web app.
Forms Authentication allows you to use the .NET Membership/Role/Login features and control a more in-depth user database.
I've never come across a good reason to use Passport Authentication, but it's a proprietry MS single-signon style authentication method.
Related
For multiple applications, I want to build a centralized account solution. The core consists of some ASP.NET Core web applications. But I also want to include third-party applications like WordPress, GitLab, or a XAMPP/HipChat server. My goal: The user creates ONE account, which can be used in all of those applications. So an LDAP server seems the best way for this since many applications have support for this protocol. This also gives flexibility for other applications, which may be added later.
The problem here is, that the users should be able to authenticate using common social sites - Especially Facebook. It's state of the art and would increase the conversation rate, cause it's easier for the users.
Is it possible to integrate social login provider like Facebook to LDAP servers like ApacheDS?
As I see the topic, Facebook generates some kind of authentication token, which can be used from the application to verify the identity of the user. In my custom web apps, this is no problem. But for e.g. a XAMPP server, this seems not to work: LDAP requires username/password. But I don't have this, since there is only a Facebook token available. The LDAP server could store this in an attribute. However, this would require to check this token instead of a password on an LDAP bind.
On the other side, when I drop the LDAP server and use some framework like ASP.NET Core identity instead, it's not a big deal. The problem here: I'm not able to use this login for third-party applications. This would require the users to have an additional account for e.g. XAMPP, WordPress, and so on, which results in big chaos and is thereby not suitable for me.
By dropping social support, it works. This seems also not to be a good idea since those logins are state of the art and I'm targeting younger users, which expect an SSO solution with Facebook or similar providers.
Facebook (and other social login sites) use a protocol named OAuth to authenticate. Probably the easiest solution would be to implement an OAuth server yourself that uses your LDAP as backend and then add that beneath the Facebook login as the second way of login.
That will not add users logging in via Facebook to your LDAP but as you usually only get an OAuth token back for login (not necessarily a username) which needs to be verified against Facebook (or whoever provided that token) it doesn't work to use it as "password replacement".
I often have a need to secure a single page (i.e. Reports) on a public facing app so that only authorized users may access the page. In the past, this mean setting up a custom login form or using the ASP.NET membership provider or something else far too complex to serve the purpose. Is there an easier (safe) way to secure a single page in this fashion?
Some things I've considered:
Client certificates (initial setup is a pain)
A single master password (works in a pinch, but feels dirty)
Restrict access by host address (cumbersome when the need arises to allow external users access to the page). Also, need to support access via proxy (X-Forwarded-For) which can be faked by technical users)
Are there other options? Recommendations?
You can do it in your web.config file something like what is suggested here. As far as authentication is concerned the easiest way is to use windows authentication.
A login system is your best option. If you don't want to go through the trouble of setting up and managing a login system yourself, consider using OpenAuth.
You can achieve functionality pretty easily using DotNetOpenAuth. Users can then log in with their Google, Yahoo, StackOverflow, etc. accounts, and you get a token that you can store to limit access with.
I'm using VS2010,C#,SQL Server to develop my ASP.NET web app, although this is not my first ASP.NET experience, but this time my project is more attack-prone and I should consider better security polices. I have a login screen as my first page, users enter their user name and password and a page specific to them is showed, in my last project, I used query strings (a userid) along with sessions for security purposes, but this time I've used just query strings, it means that at the moment one can enter myaddress.com?userid=1 and visit a page in my site!!!
I know this is not good, but what are my approaches, of courses I'm not working with banking or financial systems but I'm going to have an standard security policy, I should use sessions? cookies? can you suggest me an easy-to-develop and meanwhile secure way of implementing protection policies? any sample code or tips?
thanks
ASP.NET actually comes with all of the facilities you need to provide a secure site out of the box so you don't have to worry about all of these things yourself.
Use the built-in ASP.NET Membership features and you'll be fine.
Its not an original question. There is already a batch of articles describing this problem and solution for it. They all are dated back to times of .Net Framework 1.1 and IIS 6.0 and are not really helping with all the membership and role providers stuff we have nowadays. But lets get closer to the problem.
The problem is short.
You have an intranet site using Windows authentication and it works just fine. All you want is to give access to this site to users from their homes and to users who don`t have Windows based workstation.
Duplicate the whole site would be cumbersome because all the application except Login part would work well just if appropriate information would be saved in cookie on Login step.
You are welcome with any suggestions.
You don't say if internal users are authenticated or not, so, as it's an intranet I'm going to assume they are, via integrated authentication.
The simplest way would be to leave it as is, and turn on digest authentication if you are in a domain environment in addition to integrated authentication - this would prompt users not on the intranet with a username/password popup and they can login with their domain credentials.
If you don't have a domain - then how is it an intranet site? How are users authenticated? If you're in a workgroup scenario, where users have login details on their own box, and login details on the intranet server (in which case moving to AD would be better all round - no need to keep the passwords in sync, or deactivate user accounts in multiple places when people leave) then mixing Integrated authentication with Basic Authentication would do the same thing - however if you're going to use Basic Authentication then you will need to add an SSL certificate to the site to stop usernames and passswords being sniffed - Basic Authentication sends them in plain text.
Well, what you could consider is if you can use Active Directory, there is a provider to use the AD store for security, that would work for both.
HTH.
I must be stupid, because all the articles I've seen on OpenID in ASP.NET have simply confused me on the issue. I'm pretty sure I understand the concepts involved here, I'm just a little fuzzy on how things look on the back end side of things.
So a new user comes to my website and wants to create an account. Here comes the flood of questions:
Is the first step here to have him pick which openID provider he will use to sign in?
Do I prompt him for a user name on my system?
Do I need to tie him to the same openID provider each time he returns, or can he select a new provider each time?
What does the database look like here? Do I have his username in a table and that is linked to an openID provider?
What if the user doesn't have an OpenID account? Should I allow him to create a traditional account on my end, then expose myself as an OpenID provider?
What am I missing here? I'm usually pretty bright, but this area has been like kryptonite to Superman for my developer smarts. Thanks in advance!
Adam
This page is a step-by-step tutorial on implementing OpenId on a web site. I believe it will answer all your questions about the mechanics of adding it.
A Recipe for OpenID-Enabling Your Site
If the user doesn't have an OpenId I would just allow them to register 'normally', storing their credentials for local use. There is no need to add the extra complexity of becoming an OpenID provider unless you have a business case for that.
Dude, you're not alone. OpenID confuses everyone except the people who designed it, and even then, I'm not so sure it doesn't confuse them either since there are multiple OpenID providers and slight incompatibilities between them, depending on whose libraries you use.
Imagine the user is a sql "table" himself (that table contains his "credentials"), and you have a table of profile data specific to your website that you own. The OpenID url is a "foreign key" that you use to "join" these two tables. You must prove to yourself that he really owns that OpenID url before accepting it (or associating it with your private profile data). You're essentially "offshoring" the authentication portion of your site.
So ultimately, you use an openid client library that does the work for you on your website. They register as normal filling in "full name, "age," etc (whatever you want) but they provide an openid url instead of username/password. The library looks after verifying they really own it. You have to trust this library to do that. You then store all of your profile data with that openid. Done.
While you could offer your own openid provider, it's not worth it at this point. There are plenty out there already. What you could do though, is offer a traditional username/password INSTEAD of openid. The idea of openid is that your register ONCE with a provider, and then just prove you own that URL to any site that wants to use it to identify you (instead of username/password).
Make sense?
-Oisin