I have a little problem and I will be happy if someone tells me what to do.
I want people to change their Facebook password. This project is in VisualStudio, using C# in data base. How to make this possible? The new password should be affected by tge username and the password.
Have you taken a look at their API documentation: https://developers.facebook.com/docs ?
Generally, any site that lets other programs interact with the password in any way should be avoided. The proliferation of federated identity (delegating authentication to a third party) is one major way to avoid security issues across many web sites by third parties better equipped to handle the challenges of authentication. It also helps users and improves security by making it easy to authenticate and not reuse the same password across multiple sites - a major security problem
At best, your application can authenticate with Facebook and authorize the user to access your site / application using their login API: https://developers.facebook.com/docs/facebook-login/
Related
I am creating a project not very large scale and came to create a system of registration and login. In which cases/projects you might want to use ASP.NET Identity and when you just want to create your own login system, whose creation is much easier?
As a result of Your practice?
Maybe I have to use Form Authenticator?
Do you want social login (google / facebook / twitter / linkedin / etc)?
Do you want two-factor authentication?
Do you require users to confirm an email address as part of registration?
YOU DO WANT TO 1-WAY ENCRYPT THE PASSWORD ...but how?
ASP.NET Identity2 makes doing a lot of these things easier, because they already wrote the code for a lot of this stuff -- password hashing, creating confirmation tokens (for registration / password reset / linking emails to an account), social logins, etc.
Also, #Tim Schmelter makes a very good point in his comment. Security is not easy to get right. When you roll your own registration and login, you are not only making more work for yourself, but you are probably going to leave holes in the registration and login system.
ASP.NET Identity is not an "all or nothing" tool. You can use pieces of it as needed. There is no reason why you can't borrow the password hashing and token generation/validation portions of it, and then use the (non-claims-based) FormsAuthentication to write the cookie. However if you want claims-based authentication and social logins, I would recommend staying away from FormsAuthentication.
I have two ASP.NET websites, call them Older.com (using ancient ASP.NET WebPages) and Newer.com (which is a combination of WebPages and MVC), with separate login systems. I would like to allow the user of Older.com to be able to link their accounts to an existing Newer.com account, or create an account with Newer.com, and I think I want to do it using OAuth.
As I understand it, OAuth is generally used to allow users to login to a site using an existing account with the likes of Facebook, Google, Microsoft, etc.. However, I might not want to use Google/FB/MSoft accounts to create an OAuth token, but instead use an Older.com password to generate token that also grants them Newer.com access.
Basically, would it make sense to do this using OAuth? Do I have to use a link to an established provider Goog/FB/MSoft to use OAuth? And, are there security issues I should be concerned about when using OAuth?
Any advice, help, experience, or references are appreciated!
edit:
The reason for this is that resources that used to be hosted on Older.com are being moved to Newer.com, because Older.com needs to be rebuilt and the Newer.com is designed around storing and linking related resources. You could think of Newer.com as a place where you can keep an article, but you can also keep all the things related to that article (images, primary sources, derived works), whereas Older.com would just store a copy of the articles with no associated information.
wtyneb,
So there are a couple of ways to approach the problem you've encountered. There are many popular solutions to this problem, but two of them are: OAuth and OpenID. OAuth essentially allows access tokens to be issued to third-party clients by an authorization server. On the other hand, OpenID eliminates the need for webmasters to provide their own ad hoc systems and allowing users to consolidate their digital identities. In other words, users can log into multiple unrelated websites without having to register with their information over and over again.
The main difference between OAuth and OpenID is that OpenID is about authentication (ie. proving who you are), OAuth is about authorisation (ie. to grant access to functionality/data/etc.. without having to deal with the original authentication).
OAuth could be used in external partner sites to allow access to protected data without them having to re-authenticate a user.
In your case, if your users to Newer.com aren't using any information from Older.com, then it makes more of a sense to use an OpenID approach. Implementing OAuth would be over-engineering the solution in this case.
You can provide the credentials by either integrating OpenID into both your Older.com and Newer.com websites, or simply build out the same type of infrastructure into your back end. You can do that by simply exposing a REST API (which you might already be having to authenticate) in your Older.com website. What this does is simply verify the login credentials you have in Older.com when people log into your Newer.com, Newest.com, or any other website you might create in the future.
Please let me know if you have any questions!
I have an Azure account and currently a Mobile Service setup with a SQL Database so that my Windows Store app can communicate with the database.
I have developed sites using ASP.NET WebPages authentication. And I need something similar for my Windows Store app.
I have successfully gone through the documentation and tutorials on the Windows Azure website and implemented ACS (Windows Live ID, Google, Yahoo!, and Facebook) - but the thing is - I don't want Google, Yahoo!, Facebook or even Windows Live ID or Microsoft Account) logins - I want my OWN login but it seems that they don't give you this option (correct me if I am wrong).
I need to allow users to signup from within my application (that means, providing their name, DOB, email, phone, address, etc) and shove it all in my database.
Now, after implementing Microsoft Account login with my Azure service, I found out that you can't even get the most basic information about any user who has logged in to your application - not even an email address.
I have spent hours searching online for something that could possibly help but I am running out of keywords - and have not hit a single related result yet.
Does anyone know if this is possible? How would we go about integrating login and signup with a Windows Store app that set/gets this data into/from a Windows Azure service?
Any code, samples, links, tutorials, documentation, etc would be highly appreciated.
You have gone down the road of hooking up external identity authentication, which in my opinion for an external facing web application is a better approach. Benefits are:
Your application is only responsible for Authorization not Authentication. There is a whole lot of work involved in Authentication and a large number of best practices. Best let those who know best take the burden of this. This doesn't mean you shouldn't try and understand it though.
If your site gets hacked you don't have to tell them that their username / email and password combo has been compromised and they will probably have to change there passwords on other sits.
You are also making sure that your users don't have to remember / manage yet another username / email address password combo
If you really want to do the Authentication then that is fine but you will need to do it yourself. Have a look at examples on Asp.Net Membership. This is not the only way and nor is it the best way but there are lots of examples.
Now if you decide you want to use external authentication I can give you some pointers to help with your current implementation.
First thing to note that the Id you get back from Live, Google, Facebook can only be assumed to be unique for that provider. Therefore if you want to keep a profile in your system for that identity and you want to use more than one provider you will need to implement it in such a way that you can keep the id unique in your system and help you associate it with a provider.
Website Authentication with Social Identity Providers and ACS Part 2 – Integrating ACS with the Universal Profile Provider
As you have found out not all of the Authentication providers return the same "claims". A claim is something that user claims to have, such as an email address, name, date of birth, etc. All the ones you can use by default via the ACS return Uid and some return a name and email address. What you have to do is fill in the gaps. When someone registers you will need to pull the relevant claims and then ask them to fill in the missing ones. You may also want to map the different claims in the ACS to a common name that you can use in your app as one provider might use slightly different names.
Federated Identity with Windows Azure Access Control Service
Just because you do not handle Authentication you still need to be responsible for keeping your application secure. Half of the work has been done for you so your code should be a lot lighter but you will still need to make use of roles.
Windows Azure Role Based authentication (ACS)
The really nice thing about this approach is you can implement your application the same why SO have done with there identity model. You can allow users to associate multiple identities against their profile meaning they can login how they want to.
If you choose not to use the built in providers for ACS you will need to implement your own Identity Provider using SAML, OpenId, etc...
You can look into the Windows Identity Foundation (WIF) for implementing WS-Trust or WS-Federation.
There is also ADFS which has the same set of support but uses Active Directory with WIF and Azure has its own version of AD that can be used.
There is also thinktecture identityserver which can jumpstart your venture into IdP land, but I have not used it myself yet.
If you want to go the OpenId route there is DotNetOpenAuth.
If you're looking to add custom identity to your Mobile Services app, check out Josh's post on custom auth: http://www.thejoyofcode.com/Exploring_custom_identity_in_Mobile_Services_Day_12_.aspx
I'm trying to integrate facebook authentication with an asp.net site.
So if a user decides to register at the site they can do so by using their facebook credentials.
I'm currently at the point where I have the facebook access token and the user details and not sure how I should go from here.
The site uses asp.net membership authorization.
This is what I believe should happen in case a new user decides to register: (But not sure if this the the way to go)
0) User visits the site and decides to register using their facebook credentials.
1) The user providers their credentials and I receive an access token and their user information.
2) I store this information in my database and create an asp.net membership user with the data I received. (At this point I'd have to generate a password).
3) Log the user into the site so he can navigate freely.
I would appreciate some advice if I'm on the correct path and how I should go about generating the password. (I'm thinking in maybe combining the email and facebook userId, retrieve a hash and store.)
Thanks
UPDATE 1
I found this SO question where they suggest to use:
http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.setauthcookie(v=VS.90).aspx
I think you approach is sound; what you effectively do is to replace the username/password authentication with the received facebook id, and let that id pass as a valid identifier in you application.
You say that you will need to generate a password in you application which I am note entirely sure about. It is true that you will need to create your user with a password as far as the membership provider in ASP.NET is concerned, but you could choose to fill in a random string if you only want the users to login using facebook connections.
Deciding which facebook attribute to bind to is also worth a bit of concideration. The natural choice is of course the facebook identifier since that is unqiue to the user, but if you choose to allow other authentication mechanisms later on - google open id for one - you might also benefit from storing the email from facebook etc.
Probably it will also be a good idea to auto generate a user name in you application that is not defined by facebook. If you choose the facebook identifier as login name you have a hard dependency on facebook making the introduction of new identity providers hard. If you choose a random identifier and an associative table establishing the connection between the facebook id and your id, you will also gain some flexibility later on. Choosing the somewhat more limiting email address might be a better choice if you want to have meaningful output from ASP.NET Login-controls like LoginStatus etc.
I haven't read the response below/above so this may have been covered but be warned that I ran into a serious problem with cookies not being set from within an iframe in IE. It was a bloody nightmare. I'm not sure if this has been fixed, if its fixable, but just be conscious of my experience and test thoroughly in all browsers.
Also checkout the .net open auth project. I haven't used it personally but it supposedly supports OAuth as well as OpenId & ICards, which could be helpful later on for additional integration points.
We are evaluating Jira and would like to login into it using Integrated Windows Authentication or NTLM (i.e. automatic logon without providing username and password, by using the domain user).
We have Jira 4.1.2 installed on a Tomcat 6.0.29, with Tomcat fronted by IIS 7.
When a user accesses the application, he first goes thorough IIS. Credentials are transmitted at this point and IIS forwards to Tomcat which greets us with the Jira login page. Jira users are setup the same as those from the domain, so the user must retype the user name and password for his domain. This is annoying.
Further more, not all users have passwords as some of them login using security cards + PIN, so there is no password for them to insert.
What we want is that, based on the credentials of the user, to automatically login into the Jira application, and not be greeted by the Login page.
From what we've studied, this seems to revolve arount combining Jira with Crowd, which we don't want to install just for this purpose alone.
Also found something related to writing a custom authenticator but not really sure what to make of it. Performing different developments (dot.NET and/or Java) won't be a problem if it isn't very hacky or some huge workaround.
So, is there a way to login into Jira using Integrated Windows Authentication / NTLM?
Thanks in advance!
Unfortunately in our experience we had to use Crowd, we couldn't find an easy way around it. You could try using an LDAP based approach (if your AD supports LDAP calls and if you have a simple structure etc), but it sounds like your setup is more complicated than that.
It seems Jira 4 does not yet support NTLM authentication: http://forums.atlassian.com/thread.jspa?threadID=43247
Jira 4 + LDAP + Active Directory works, but does not give you SSO.
The following add-on provides Integrated Windows Authentication (Kerberos) for any web app using Atlassian Crowd as its user management system, including Jira, Confluence, Stash and Bamboo: https://marketplace.atlassian.com/plugins/com.cleito.iwaac